整合营销服务商
电脑端+手机端+微信端=数据同步管理
免费咨询热线：
电脑端+手机端+微信端=数据同步管理
免费咨询热线：
者：皮皮
JavaScript 是单线程运行的，所以在在执行效率上并不是很高，随着用户体验的日益重视，前端性能对用户体验的影响备受关注，但由于性能问题相对复杂，接下来我们来了解下JavaScript如何提高性能;
由于 JavaScript 的阻塞特性，在每一个<script>出现的时候，无论是内嵌还是外链的方式，它都会让页面等待脚本的加载解析和执行，并且<script>标签可以放在页面的<head>或者<body>中，因此，如果我们页面中的 css 和 js 的引用顺序或者位置不一样，即使是同样的代码，加载体验都是不一样的。示例如下：
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width,initial-scale=1.0">
<title>js 引用的位置性能优化</title>
<script type="text/javascript" src="index-1.js"></script>
<script type="text/javascript" src="index-2.js"></script>
<link rel="stylesheet" href="style.css">
</head>
<body>
<div id="app"></div>
</body>
</html>1.2.3.4.5.6.7.8.9.10.11.12.13.14.其后面的内容将会被挂起等待，直到index-1.js 加载、执行完毕，才会执行第二个脚本文件 index-2.js，这个时候页面又将被挂起等待脚本的加载和执行完成，一次类推，这样用户打开该界面的时候，界面内容会明显被延迟，我们就会看到一个空白的页面闪过，这种体验是明显不好的，因此 我们应该尽量的让内容和样式先展示出来，将 js 文件放在 最后，以此来优化用户体验。如下所示:
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width,initial-scale=1.0">
<title>js 引用的位置性能优化</title>
<link rel="stylesheet" href="style.css">
</head>
<body>
<div id="app"></div>
<script type="text/javascript" src="index-1.js"></script>
<script type="text/javascript" src="index-2.js"></script>
</body>
</html>1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.这段代码展示了在 HTML 文档中放置<script>标签的推荐位置。尽管脚本下载会阻塞另一个脚本，但是页面的大部分内容都已经下载完 成并显示给了用户，因此页面下载不会显得太慢。这是雅虎特别性能小组提出的优化 JavaScript 的首要规则：将脚本放在底部。
由于每个<script>标签初始下载时都会阻塞页面渲染，所以减少页面包含的<script>标签数量有助于改善这一情况。这不仅针对外链脚本，内嵌脚本的数量同样也要限制。浏览器在解析 HTML 页面的过程中每遇到一个<script>标签，都会因执行脚本而导致一定的延时，因此最小化延迟时间将会明显改善页面的总体性能。
这个问题在处理外链 JavaScript 文件时略有不同。考虑到 HTTP 请求会带来额外的性能开销，因此下载单个 100Kb 的文件将比下载 5 个 20Kb 的文件更快。也就是说，减少页面中外链脚本的数量将会改善性能。
通常一个大型网站或应用需要依赖数个 JavaScript 文件。您可以把多个文件合并成一个，这样只需要引用一个<script>标签，就可以减少性能消耗。文件合并的工作可通过离线的打包工具或者一些实时的在线服务来实现。
需要特别提醒的是，把一段内嵌脚本放在引用外链样式表的之后会导致页面阻塞去等待样式表的下载。这样做是为了确保内嵌脚本在执行时能获得最精确的样式信息。因此，建议不要把内嵌脚本紧跟在标签后面。
有一点我们需要知道：页面加载的过程中，最耗时间的不是 js 本身的加载和执行，相比之下，每一次去后端获取资源，客户端与后台建立链接才是最耗时的，也就是大名鼎鼎的Http 三次握手，当然，http 请求不是我们这一次讨论的主题，因此，减少 HTTP 请求，是我们着重优化的一项，事实上，在页面中 js 脚本文件加载很很多情况下，它的优化效果是很显著的。
在 JavaScript 性能优化上，减少脚本文件大小并限制 HTTP 请求的次数仅仅是让界面响应 迅速的第一步，现在的 web 应用功能丰富，js 脚本越来越多，光靠精简源码大小和减少 次数不总是可行的，即使是一次 HTTP 请求，但文件过于庞大，界面也会被锁死很长一段 时间，这明显不好的，因此，无阻塞加载技术应运而生。简单来说， 就是 页面在加载完成后才加载 s js 代码，也就是在 w window 对象的 d load 事件触 发后才去下载脚本。要实现这种方式，常用以下几种方式：
HTML4 为<script>标签定义了一个扩展属性：defer。Defer 属性指明本元素所含的脚本不会修改 DOM，因此代码能安全地延迟执行。defer 属性只被 IE 4 和 Firefox 3.5 更高版本的浏览器所支持，所以它不是一个理想的跨浏览器解决方案。在其他浏览器中，defer 属性会被直接忽略，因此<script>标签会以默认的方式处理，也就是说会造成阻塞。然而，如果您的目标浏览器支持的话，这仍然是个有用的解决方案。
<script type="text/javascript" src="index-1.js" defer></script>1.带有 defer 属性的<script>标签可以放置在文档的任何位置。对应的 JavaScript 文件将在页面解析到<script>标签时开始下载，但不会执行，直到 DOM 加载完成，即 onload事件触发前才会被执行。当一个带有 defer 属性的 JavaScript 文件下载时，它不会阻塞浏览的其他进程，因此这类文件可以与其他资源文件一起并行下载。·任何带有 defer 属性的<script>元素在 DOM 完成加载之前都不会被执行，无论内嵌或者是外链脚本都是如此。
HTML5 规范中也引入了 async 属性，用于异步加载脚本，其大致作用和 defer 是一样的，都是采用的并行下载，下载过程中不会有阻塞，但 不同点在于他们的执行时机，c async 需要加载完成后就会自动执行代码 ，但是 r defer 需要等待页面加载完成后才会执行。
把代码以动态的方式添加的好处是：无论这段脚本是在何时启动下载，它的下载和执行过程都不会阻塞页面的其他进程，我们甚至可以直接添加带头部 head 标签中，都不会影响其他部分。因此，作为开发的你肯定见到过诸如此类的代码块：
var script=document.createElement('script');
script.type='text/javascript';
script.src='file.js';
document.getElementsByTagName('head')[0].appendChild(script);1.2.3.4.这种方式便是动态创建脚本的方式，也就是我们现在所说的动态脚本创建。通过这种方式下载文件后，代码就会自动执行。但是在现代浏览器中，这段脚本会等待所有动态节点加载完成后再执行。这种情况下，为了确保当前代码中包含的别的代码的接口或者方法能够被成功调用，就必须在别的代码加载前完成这段代码的准备。解决的具体操作思路是：现代浏览器会在 script 标签内容下载完成后接收一个load 事件，我们就可以在 load 事件后再去执行我们想要执行的代码加载和运行，在 IE 中，它会接收 loaded 和 complete事件，理论上是 loaded 完成后才会有 completed，但实践告诉我们他两似乎并没有个先后，甚至有时候只会拿到其中的一个事件，我们可以单独的封装一个专门的函数来体现这个功能的实践性,因此一个统一的写法是：
function LoadScript(url, callback) {
var script=document.createElement('script');
script.type='text/javascript';
// IE 浏览器下
if (script.readyState) {
script.onreadystatechange=function () {
if (script.readyState=='loaded' || script.readyState== 'complete') {
// 确保执行两次
script.onreadystatechange=null;
// todo 执行要执行的代码
callback()
}
}
} else {
script.onload=function () {
callback();
}
}
script.src='file.js';
document.getElementsByTagName('head')[0].appendChild(script);
}1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.19.20.21.22.LoadScript 函数接收两个参数，分别是要加载的脚本路径和加载成功后需要执行的回调函数，LoadScript 函数本身具有特征检测功能，根据检测结果（IE 和其他浏览器），来决定脚本处理过程中监听哪一个事件。实际上这里的 LoadScript()函数，就是我们所说的 LazyLoad.js（懒加载）的原型。
通过 XMLHttpRequest 对象来获取脚本并注入到页面也是实现无阻塞加载的另一种方式，这个我觉得不难理解，这其实和动态添加脚本的方式是一样的思想，来看具体代码：
var xhr=new XMLHttpRequest();
xhr.open('get', 'file-1.js', true);
xhr.onreadystatechange=function () {
if (xhr.readyState===4) {
if (xhr.status >=200 && xhr.status < 300 || xhr.status===304) {
// 如果从后台或者缓存中拿到数据，则添加到 script 中并加载执行。
var script=document.createElement('script');
script.type='text/javascript';
script.text=xhr.responseText;
// 将创建的 script 添加到文档页面
document.body.appendChild(script);
}
}
}1.2.3.4.5.6.7.8.9.10.11.12.13.14.通过这种方式拿到的数据有两个优点：其一，我们可以控制脚本是否要立即执行，因为我们知道新创建的 script 标签只要添加到文档界面中它就会立即执行，因此，在添加到文档界面之前，也就是在 appendChild()之前，我们可以根据自己实际的业务逻辑去实现需求，到想要让它执行的时候，再 appendChild()即可。其二：它的兼容性很好，所有主流浏览器都支持，它不需要想动态添加脚本的方式那样，我们自己去写特性检测代码；但由于是使用了 XHR 对象，所以不足之处是获取这种资源有“域”的限制。资源 必须在同一个域下才可以，不可以跨域操作。
减少 JavaScript 对性能的影响有以下几种方法：
使用<script>标签的 defer 属性（仅适用于 IE 和 Firefox 3.5 以上版 本）；
使用动态创建的<script>元素来下载并执行代码；
使用 XHR 对象下载 JavaScript 代码并注入页面中。
通过以上策略，可以在很大程度上提高那些需要使用大量 JavaScript 的 Web 网站和应用的实际性能。
来源： Python共享之家
者：lzg9527
原文链接：https://segmentfault.com/a/1190000038180453
webpack ensure 有人称它为异步加载，也有人称为代码切割，他其实就是将 js 模块给独立导出一个.js 文件，然后使用这个模块的时候，再创建一个 script 对象，加入到 document.head 对象中，浏览器会自动帮我们发起请求，去请求这个 js 文件，然后写个回调函数，让请求到的 js 文件做一些业务操作。
需求： main.js 依赖两个 js 文件： A.js 是点击 aBtn 按钮后，才执行的逻辑， B.js 是点击 bBtn 按钮后，才执行的逻辑。
webpack.config.js ，我们先来写一下 webpack 打包的配置的代码
const path=require('path') // 路径处理模块
const HtmlWebpackPlugin=require('html-webpack-plugin')
const { CleanWebpackPlugin }=require('clean-webpack-plugin') // 引入CleanWebpackPlugin插件
module.exports={
entry: {
index: path.join(__dirname, '/src/main.js'),
},
output: {
path: path.join(__dirname, '/dist'),
filename: 'index.js',
},
plugins: [
new HtmlWebpackPlugin({
template: path.join(__dirname, '/index.html'),
}),
new CleanWebpackPlugin(), // 所要清理的文件夹名称
],
}
index.html 代码如下
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<title>webpack</title>
</head>
<body>
<div id="app">
<button id="aBtn">按钮A</button>
<button id="bBtn">按钮B</button>
</div>
</body>
</html>
入口文件 main.js 如下
import A from './A'
import B from './B'
document.getElementById('aBtn').onclick=function () {
alert(A)
}
document.getElementById('bBtn').onclick=function () {
alert(B)
}
A.js 和 B.js 的代码分别如下
// A.js
const A='hello A'
module.exports=A
// B.js
const B='hello B'
module.exports=B
此时，我们对项目进行 npm run build ， 打包出来的只有两个文件
由此可见，此时 webpack 把 main.js 依赖的两个文件都同时打包到同一个 js 文件，并在 index.html 中引入。但是 A.js 和 B.js 都是点击相应按钮才会执行的逻辑，如果用户并没有点击相应按钮，而且这两个文件又是比较大的话，这样是不是就导致首页默认加载的 js 文件太大，从而导致首页渲染较慢呢？那么有能否实现当用户点击按钮的时候再加载相应的依赖文件呢？
webpack.ensure 就解决了这个问题。
下面我们将 main.js 改成异步加载的方式
document.getElementById('aBtn').onclick=function () {
//异步加载A
require.ensure([], function () {
let A=require('./A.js')
alert(A)
})
}
document.getElementById('bBtn').onclick=function () {
//异步加载b
require.ensure([], function () {
let B=require('./B.js')
alert(B)
})
}
此时，我们再进行一下打包，发现多了 1.index.js 和 2.index.js 两个文件。而我们打开页面时只引入了 index.js 一个文件，当点击按钮 A 的时候才引入 1.index.js 文件，点击按钮 B 的时候才引入 2.index.js 文件。这样就满足了我们按需加载的需求。
require.ensure 这个函数是一个代码分离的分割线，表示回调里面的 require 是我们想要进行分割出去的，即 require('./A.js') ，把 A.js 分割出去，形成一个 webpack 打包的单独 js 文件。它的语法如下
require.ensure(dependencies: String[], callback: function(require), chunkName: String)
我们打开 1.index.js 文件，发现它的代码如下
(window.webpackJsonp=window.webpackJsonp || []).push([
[1],
[
,
function (o, n) {
o.exports='hello A'
},
],
])
由上面的代码可以看出：
webpack4 官方文档提供了模块按需切割加载，配合 es6 的按需加载 import() 方法，可以做到减少首页包体积，加快首页的请求速度，只有其他模块，只有当需要的时候才会加载对应 js。
import() 的语法十分简单。该函数只接受一个参数，就是引用包的地址，并且使用了 promise 式的回调，获取加载的包。在代码中所有被 import() 的模块，都将打成一个单独的包，放在 chunk 存储的目录下。在浏览器运行到这一行代码时，就会自动请求这个资源，实现异步加载。
下面我们将上述代码改成 import() 方式。
document.getElementById('aBtn').onclick=function () {
//异步加载A
import('./A').then((data)=> {
alert(data.A)
})
}
document.getElementById('bBtn').onclick=function () {
//异步加载b
import('./B').then((data)=> {
alert(data.B)
})
}
此时打包出来的文件和 webpack.ensure 方法是一样的。
为什么需要懒加载？
像 vue 这种单页面应用，如果没有路由懒加载，运用 webpack 打包后的文件将会很大，造成进入首页时，需要加载的内容过多，出现较长时间的白屏，运用路由懒加载则可以将页面进行划分，需要的时候才加载页面，可以有效的分担首页所承担的加载压力，减少首页加载用时。
vue 路由懒加载有以下三种方式
这种方法主要是使用了 resolve 的异步机制，用 require 代替了 import 实现按需加载
export default new Router({
routes: [
{
path: '/home',',
component: (resolve)=> require(['@/components/home'], resolve),
},
{
path: '/about',',
component: (resolve)=> require(['@/components/about'], resolve),
},
],
})
这种模式可以通过参数中的 webpackChunkName 将 js 分开打包。
export default new Router({
routes: [
{
path: '/home',
component: (resolve)=> require.ensure([], ()=> resolve(require('@/components/home')), 'home'),
},
{
path: '/about',
component: (resolve)=> require.ensure([], ()=> resolve(require('@/components/about')), 'about'),
},
],
})
vue-router 在官网提供了一种方法，可以理解也是为通过 Promise 的 resolve 机制。因为 Promise 函数返回的 Promise 为 resolve 组件本身，而我们又可以使用 import 来导入组件。
export default new Router({
routes: [
{
path: '/home',
component: ()=> import('@/components/home'),
},
{
path: '/about',
component: ()=> import('@/components/home'),
},
],
})
在 webpack 打包过程中，经常出现 vendor.js ， app.js 单个文件较大的情况，这偏偏又是网页最先加载的文件，这就会使得加载时间过长，从而使得白屏时间过长，影响用户体验。所以我们需要有合理的分包策略。
在 Webapck4.x 版本之前，我们都是使用 CommonsChunkPlugin 去做分离
plugins: [
new webpack.optimize.CommonsChunkPlugin({
name: 'vendor',
minChunks: function (module, count) {
return (
module.resource &&
/.js$/.test(module.resource) &&
module.resource.indexOf(path.join(__dirname, './node_modules'))===0
)
},
}),
new webpack.optimize.CommonsChunkPlugin({
name: 'common',
chunks: 'initial',
minChunks: 2,
}),
]
我们把以下文件单独抽离出来打包
webpack 4 最大的改动就是废除了 CommonsChunkPlugin 引入了 optimization.splitChunks 。如果你的 mode 是 production ，那么 webpack4 就会自动开启 Code Splitting 。
它内置的代码分割策略是这样的：
虽然在 webpack4 会自动开启 Code Splitting ，但是随着项目工程的最大，这往往不能满足我们的需求，我们需要再进行个性化的优化。
我们先找到一个优化空间较大的项目来进行操作。这是一个后台管理系统项目，大部分内容由 3-4 个前端开发，平时开发周期较短，且大部分人没有优化意识，只是写好业务代码完成需求，日子一长，造成打包出来的文件较大，大大影响性能。
我们先用 webpack-bundle-analyzer 分析打包后的模块依赖及文件大小，确定优化的方向在哪。
然后我们再看下打包出来的 js 文件
看到这两张图的时候，我内心是崩溃的，槽点如下
吐槽完之后我们就要开始做正事了。正是因为有这么多槽点，我们才更好用来验证我们优化方法的可行性。
抽离 echart 和 iview
由上面分析可知， echart 和 iview 文件太大，此时我们就用到 webpack4 的 optimization.splitChunks 进行代码分割了，把他们单独抽离打包成文件。(为了更好地呈现优化效果，我们先把 xlsx.js 去掉)
vue.config.js 修改如下：
chainWebpack: config=> {
config.optimization.splitChunks({
chunks: 'all',
cacheGroups: {
vendors: {
name: 'chunk-vendors',
test: /[/]node_modules[/]/,
priority: 10,
chunks: 'initial'
},
iview: {
name: 'chunk-iview',
priority: 20,
test: /[/]node_modules[/]_?iview(.*)/
},
echarts: {
name: 'chunk-echarts',
priority: 20,
test: /[/]node_modules[/]_?echarts(.*)/
},
commons: {
name: 'chunk-commons',
minChunks: 2,
priority: 5,
chunks: 'initial',
reuseExistingChunk: true
}
}
})
},
此时我们再用 webpack-bundle-analyzer 分析一下
打包出来的 js 文件
从这里可以看出我们已经成功把 echart 和 iview 单独抽离出来了，同时 vendor.js 也相应地减小了体积。此外，我们还可以继续抽离其他更多的第三方模块。
CDN 方式
虽然第三方模块是单独抽离出来了，但是在首页或者相应路由加载时还是要加载这样一个几百 kb 的文件，还是不利于性能优化的。这时，我们可以用 CDN 的方式引入这样插件或者 UI 组件库。
<head>
<link rel="stylesheet" href="https://cdn.bootcdn.net/ajax/libs/iview/3.5.4/styles/iview.css" />
</head>
<body>
<div id="app"></div>
<script src="https://cdn.bootcss.com/vue/2.6.8/vue.min.js"></script>
<script src="https://cdn.bootcdn.net/ajax/libs/iview/3.5.4/iview.min.js"></script>
<script src="https://cdn.bootcdn.net/ajax/libs/xlsx/0.16.8/xlsx.mini.min.js"></script>
<script src="https://cdn.bootcdn.net/ajax/libs/xlsx/0.16.8/cpexcel.min.js"></script>
</body>
configureWebpack: (config)=> {
config.externals={
vue: 'Vue',
xlsx: 'XLSX',
iview: 'iView',
iView: 'ViewUI',
}
}
npm uninstall vue iview echarts xlsx --save
此时我们在来看一下打包后的情况
打包出来的 js 文件
well done ! 这时基本没有打包出大文件了，首页加载需要的 vendor.js 也只有几十 kb，而且我们还可以进一步优化，就是把 vue 全家桶的一些模块再通过 cdn 的方法引入，比如 vue-router ， vuex ， axios 等。这时页面特别是首页加载的性能就得到大大地优化了。
多开发者可能平时并不关心自己维护的页面是否存在内存泄漏，原因可能是刚开始简单的页面内存泄漏的速度很缓慢，在造成严重卡顿之前可能就被用户刷新了，问题也就被隐藏了，但是随着页面越来越复杂，尤其当你的页面是 SAP 方式交互时，内存泄漏的隐患便越来越严重，直到突然有一天用户反馈说：“操作一会儿页面就卡住不动了，也不知道为什么，以前不这样的呀”。
这篇文章通过一些简单的例子介绍内存泄漏的调查方法、总结内存泄漏出现的原因和常见情况，并针对每种情况总结如何避免内存泄漏。希望能对大家有所帮助。
先看一个简单的例子，下面是这个例子对应的代码：
代码 1
代码 1 的逻辑很简单：点击“add date”按钮时会向 dateAry 数组中 push 3000 个 new Date 对象，点击“clear”按钮时将 dateAry 清空。很明显，“add date”操作会造成内存占用不断增长，如果将这个逻辑用在实际应用中便会造成内存泄漏（不考虑故意将代码逻辑设计成这样的情况），下面我们看一下如何调查这种内存增长出现的原因以及如何找出内存泄漏点。
1 heap snapshot
为了避免浏览器插件的干扰，我们在 chrome 中新建一个无痕窗口打开上述代码。然后在 chrome 的 devtools 中的 Memory 工具中找到 “Heap Snapshot”工具，点击左上角的录制按钮录制一个 Snapshot，然后点击“add date”按钮，在手动触发 GC（Garbage Collect）之后，再次录制一个 Snapshot，反复执行上述操作若干次，像图 1 中操作的那样，得到一系列的 Snapshot。
图 1 录制 Snapshot
图 2 是我们刚刚得到的 Snapshot 组，其中的第一个是页面初始加载的时候录制的，不难发现，从第二个开始，每个 Snapshot 相比于上一个其大小都增加了约 200KB，我们点击选择 Snapshot 2，在 class filter 输入框中处输入 date，可以得到 Snapshot 2 中所有被 Date 构造器构造出来的 JS 对象，也就是 Date 对象，这里看到的构造器跟浏览器内部的实现有关，不必跟 JS 的对象对应。
选中一个 Date 对象，在下面的面板中可以看到所选对象的持有链以及相关持有对象的内存的保留大小（Retained Size），从图中可以看出选中的 Date 对象是 Array 的第 1 个元素（index 从 0 开始），而这个 Array 的持有者是 system/Context 上下文中的 dateAry，system/Context 上下文就是代码中 script 标签的上下文，我们可以看到在这个 dataAry 的保留大小是 197KB，我们再切到 Snapshot 3，用相同的方式查看内存持有和大小，可以发现 Snapshot 3 中的 dataAry 的保留大小变成了 386KB，相比于 Snapshot 2 增涨了约 200KB！逐一比较后面的 Snapshot 4、5 后也能得到相同的对比结果，即下一个 Snapshot 中的 dateAry 比上一个的保留大小大约 200KB。
图 2 录制的 Snapshot 组
参考【代码 1】我们可以知道，“add date”按钮在被点击时，会向 dateAry 数组中 push 3000 个新的 Date 对象，而在图 2 中的 Date 构造器的右侧可以看到这 3000 个 Date 对象（Date x 3000），它对应的正式我们的循环创建的那 3000 个 Date 对象。综合上面的操作我们可以知道，chorome devtools 中的 Memroy 的 Heap Snapshot 工具可以录制某一个时刻的所有内存对象，也就是一个“快照”，快照中按“构造器”分组，展示了所有被记录下来的 JS 对象。
如果这个页面是一个实际服务于用户的网站的某个页面话（用户可能非常频繁的点击“add date”按钮，作者可能想记录用户点击的次数？也许吧，虽然我也不知道他什么要这么做）随着用户使用时间的增长，“add date”按钮的反应就会越来越慢，整体页面也随之越来越卡，原因除了系统的内存资源被占用之外，还有 GC 的频率和时长增长，如图 3 所示，因为 GC 执行的过程中 JS 的执行是被暂停的，所以页面就会呈现出越来越卡的样子。
图 3 Performance 录制的 GC 占比
图 4 chrome 的任务管理器
最终：
图 5 内存占用过高导致浏览器崩溃
那么，在这个“实际”的场景下，如何找出那“作祟”的 3000 个 Date 对象呢？我们首先想到的应该是就是：之前不是录制了好多个 Snapshot 吗？可不可以把它们做对比找到“差异”呢，从差异中找到增长的地方不就行了？思路非常正确，在此之前我们再分析一下这几个 Snapshot：每次点击“add date”按钮、手动触发 GC、得到的 Snapshot 的大小相比上一次都有所增加，如果这种内存的增长现象不符合“预期”的话（显然在这个“实际”的例子中是不符合预期的），那么这里就有很大的嫌疑存在内存泄漏。
这个时候我们选中 Snapshot 2，在图 2 所示的 " Summary" 处选择“Comparison”，在右侧的 "All objects" 处选择 Snapshot 1，这样一来，Constructor 里展示便是 Snapshot 1 和 Snapshot 2 的对比，通过观察不难发现，图中的 +144KB 最值得怀疑，于是我们选中它的构造器 Date，展开选中任意子项看详情，发现其是被 Array 构造器构造出来的 dateAry 持有的（即 dateAry 中的一员）,并且 dateAry 被三个地方持有，其中系统内部的 array 我们不用理会，图 6 中写有 "context in ()" 地方给了我们持有 dateAry 的 context 所在的位置，点击便可以跳到代码所在的位置了，整个操作如图 6 所示：
图 6 定位代码位置
这里有一个值得注意的地方，图 6 中的 “context in () @449305” 中的 "()"，这里之所以展示为了 "()" 是因为代码中用了“匿名函数”（代码 2 中第 2 行的箭头函数）：
// 【写入 date】
pushDate.addEventListener("click", ()=> {
dateCount.innerHTML=`${++dateNum}`;
for (let j=0; j < 3000; ++j) {
dateAry.push(new Date());
}
});代码 2 匿名函数
但是如果我们给函数起一个名字，如下面的代码所示，也就是如果我们使用具名函数（代码3 第 2 行函数 add）或者将函数赋值给一个变量并使用这个变量（第 10 和 18 行的行为）的时候，devtools 中都可以看到相应的函数的名字，这也就可以帮助我们更好的定位代码，如图 7 所示。
// 【写入 date】
pushDate.addEventListener("click", function add() {
dateCount.innerHTML=`${++dateNum}`;
for (let j=0; j < 3000; ++j) {
dateAry.push(new Date());
}
});
const clear=document.querySelector(".clear");
const doClear=function () {
dateAry=[];
dateCount.innerHTML="0";
};
// 【回收内存】
clear.addEventListener("click", doClear);代码 3 具名函数
图 7 具名函数方便定位
这样我们便找到了代码可疑的地方，只需要将代码的作者抓过来对着他一顿“分析”这个内存泄漏的问题基本就水落石出了。
其实，Snapshot 除了“Comparison”之外还有一个更便捷的用于对比的入口，在这里直接可以看到在录制 Snapshot 1 和 Snapshot 2 两个时间点之间被分配出来的内存，用这种方式也可以定位到那个可疑的 Date x 3000：
图 8 Snapshot 比较器
上文件介绍的是用 Heap Snapshot 寻找内存泄漏点的方法，这个方法的优点：可以录制多个 Snapshot，然后方便的两两比较，并且能看到 Snapshot 中的全量内存，这一点是下文要讲的“Allocation instrumentation on timeline”方法不具备的，并且这种方法可以更加方便地查找后面会讲的因 Detached Dom 导致的内存泄漏。
2 Allocation instrumentation on timeline
但是，不知道你有没有觉得，这种高频率地录制 Snapshot、对比、再对比的方式有点儿麻烦？我需要不断的去点击“add date”，然后鼠标又要跑过去点击手动 GC、录制 Snapshot、等待录制完毕，再去操作，再去录制。有没有简单一些的方式来查找内存泄漏？这个时候我们回到 Memory 最初始的界面，你突然发现 “Heap snapshot”下面还有一个 radio：“Allocation instrumentation on timeline”，并且这个 radio 下面的介绍文案的最后写着：“Use this profile type to isolate memory leaks”，原来这是一个专门用于调查内存泄漏的工具！于是，我们选中这个 radio，点击开始录制按钮，然后将注意力放在页面上，然后你发现当点击“add date”按钮时，右面录制的 timeline 便会多出一个心跳：
图 9 Allocation instrumentation on timeline
如图 9 所示，每当我们点击“add date”按钮时，右面都有一个对应的心跳，当我们点击“clear”按钮时，刚才出现的所有心跳便全都“缩回”去了，于是我们得出结论：每一个“心跳”都是一次内存分配，其高度代表内存分配的量，在之后的时间推移过程中，如果刚才心跳对应的被分配的内存被 GC 回收了，“心跳”便会跟着变化为回收之后的高度。于是，我们便摆脱了在 Snapshot 中来回操作、录制的窘境，只需要将注意力集中在页面的操作上，并观察哪个操作在右边的时间线变化中是可疑的。
经过一系列操作，我们发现“add date”这个按钮的点击行为很可疑，因为它分配的内存不会自动被回收，也就是只要点击一次，内存就会增长一点，我们停止录制，得到了一个 timeline 的 Snapshot，这个时候如果我们点击某个心跳的话：
图 10 点击某个心跳
熟悉的 Date x 3000 又出现了（图 11），点击一个 Date 对象看持有链，接下来便跟上文 Snapshot 的持有链分析一样了：
图 11 通过 timeline 找到泄漏点
这个方法的优点上文已经说明，可以非常直观、方便的观察内存随可疑操作的分配与回收过程，可以方便的观察每次分配的内存。它的缺点：录制时间较长时 devtools 收集录制结果的时间会很长，甚至有时候会卡死浏览器；下文会讲到 detached DOM，这个工具不能比较出 detached DOM，而 heap snapshot 可以。
3 performance
devtools 中的 Performance 面版中也有一个 Memory 功能，下面看一下它如何使用。我们把 Memory 勾选上，并录制一个 performance 结果：
图 12 Performance 的录制过程
在图 12 中可以看到，在录制的过程中我们连续点击“add date”按钮 10 次，然后点击一次“clear”按钮，然后再次点击“add date” 10 次，得到的最终结果如图 13 所示：
图 13 Performance 的录制结果
在图 13 中我们可以得到下面的信息：
图 14 通过 Performance 定位问题代码
这种方法的优点：可以直观得看到内存的总体走势，并且同时得到所有操作过程中的函数调用栈和时间等信息。缺点：没有具体的内存分配的细节，录制的过程不能实时看到内存分配的过程。
1 全局
JS 采用标记清扫法去回收无法访问的内存对象，被挂载在全局对象（在浏览器中即指的是 window 对象，在垃圾回收的角度上称其为根节点，也叫 GC root）上的属性所占用内存是不会被回收的，因为其是始终可以访问的，这也符合“全局”的命名含义。
解决方案就是避免用全局对象存储大量的数据。
2 闭包（closure）
我们把【代码 1】稍加改动便可以得到一个闭包导致内存泄漏的版本：
代码 3 闭包导致内存泄漏
将上述代码加载到 chrome 中，并用 timeline 的方式录制一个 Snapshot，得到的结果如图 15 所示：
图 15 闭包的录制结果
我们选中 index=2 的心跳，可以看到 Constructor 里面出现了一个 "(closure)"，我们展开这个 closure，可以看到里面的 "inner()"，inner() 后面的 "()" 表示 inner 是一个函数，这时候你可能会问：“图中的 Constructor 的 Retained Size 大小都差不多，为什么你要选 (closure)？”，正是因为没有明显占比较高的 Retained Size 我们才随便选一个调查，后面你会发现不管你选了哪一个最后的调查链路都是殊途同归的。
我们在下面的 Retainers 中看下 inner() 的持有细节：从下面的 Retainers 中可以看出 inner() 这个 closure 是某个 Array 的第 2 项（index 从 0 开始），而这个数组的持有者是 system/Context（即全局） 中的 ary，通过观察可以看到 ary 的持有大小（Retained Size）是 961KB 大约等于 192KB 的 5 倍，5 即是我们点击“add date”按钮的次数，而下面的 5 个 "previous in system/Context" 每个大小都是 192KB，而它们最终都是被某个 inner() 闭包持有，至此我们便可以得出结论：全局中有一个 ary 数组，它的主要内存是被 inner() 填充的，通过蓝色的 index.html:xx 处的代码入口定位到代码所在地看一下一切就都了然了，原来是 inner() 闭包内部持有了一个大对象，并且所有的 inner() 闭包及其持有的大对象都被 ary 对象持有，而 ary 对象是全局的不会被回收，导致了内存泄漏（如果这种行为不符合预期的话）。返回去，如果这个时候你选择上面提到的 system/Context 构造器，你会看到（见图 16，熟悉吧）：
图 16 system/Context
也就是你选择的 system/Context 其实是 inner() 闭包的上下文对象（context），而此上下文持有了 192KB 内存，通过蓝色的 index.html:xx 又可以定位到问题代码了。如果你像图 17 一样选择了 Date 构造器进行查看的话也可以最终定位到问题，此处将分析过程留给读者自己进行：
图 17 选中 Date 构造器
3 Detached DOM
我们先看一下下面的代码，并用 chrome 载入它：
代码 4 Detached Dom
然后我们采用 Heap Snapshot 的方式将点击“del”按钮前后的两个 snapshot 录制下来，得到的结果如图 6 所示。我们选用和 snapshot 1 对比的方式并在 snapshot 2 的过滤器中输入 "detached"。我们观察得到的筛选结果的 "Delta" 列，其中不为 0 的列如下：
要解释上述表格需要先介绍一个知识点：DOM 对象被回收需要同时满足两个条件，1、DOM 在 DOM 树中被删掉；2、DOM 没有被 JS 对象引用。其中第二点还是比较容易被忽视的。正如上面的例子所示，Detached HTMLButtonElement +1 代表有一个 button DOM 被从组件树中删掉了，但是仍有 JS 引用之（我们不考虑有意为之的情况）。
相似的，Detached EventListener 也是因为 DOM 被删掉了，但是事件没有解绑，于是 Detached 了，解决方案也很简单：及时解绑事件即可。
于是解决的方法就很简单了：参见代码 5，回掉函数 del 在执行完毕时临时变量会被回收，于是两个条件就都同时满足了，DOM 对象就会被回收掉，事件解绑了，Detached EventListener 也就没有了。值得注意的是 table 元素，如果一个 td 元素发生了 detached，则由于其自身引用了自己所在的 table，于是整个 table 就也不会被回收了。
代码 5 Detached DOM 的解决方法
图 18 Detached DOM 的 Snapshot
Performance monitor 工具
DOM/event listener 泄漏在编写轮播图、弹窗、toast 提示这种工具的时候还是很容易出现的，chrome 的 devtools 中有一个 Performance monitor 工具可以用来帮助我们调查内存中是否有 DOM/event listener 泄漏。首先看一下代码 6：
代码 6 不断增加 DOM NODE
按照我们图 19 的方式打开 Performance monitor 面版：
图 19 打开 Performance monitor 工具
DOM Nodes 右侧的数量是当前内存中的所有 DOM 节点的数量，包括当前 document 中存在的和 detached 的以及计算过程中临时创建的，每当我们点击一次“add date”按钮，并手动触发 GC 之后 DOM Nodes 的数量就 + 2，这是因为我们向 document 中增加了一个 button 节点和一个 button 的文字节点，就像图 20 中所示。如果你写的 toast 组件在临时插入到 document 并过一会儿执行了 remove 之后处于了 detached 状态的话，Performance monitor 面版中的 DOM Nodes 数量就会不断增加，结合 snapshot 工具你便可以定位到问题所在了。值得一提的是，有的第三方的库的 toast 便存在这个问题，不知道你被坑过没有。
图 20 不断增加的 DOM Nodes
4 console
这一点可能有人不会留意到，控制台打印的内容是需要始终保持引用的存在的，这一点也是值得注意的，因为打印过多过大对象的话也是会造成内存泄漏的，如图 21 所示（配合代码 7）。解决方法便是不要肆意打印对象到控制台中，只打印必要的信息出来。
代码 7 console 导致内存泄漏
图 21 console 导致的内存泄漏
本文用了几个简单的小例子介绍了内存泄漏出现的时机、寻找泄漏点的方法并将各种方法的优缺点进行了对比，总结了避免出现内存泄漏的注意点。希望能对读者有所帮助。文中如果有本人理解错误或书写错误的地方欢迎留言指正。
参考
https://commandlinefanatic.com/cgi-bin/showarticle.cgi?article=art038
https://developer.chrome.com/docs/devtools/memory-problems/
https://www.bitdegree.org/learn/chrome-memory-tab
作者 | 木及
原文链接：http://click.aliyun.com/m/1000287965/
本文为阿里云原创内容，未经允许不得转载。
*请认真填写需求信息，我们会在24小时内与您取得联系。
