web

没用的东西，你连个内存泄漏都排查不出来！！

背景

ui妹子的无理要求，我通通满足了。但是不出意外的话，意外就出来了。
此功能在上线之后，我们的业务在客户app内使用刷脸的时候会因为内存过高导致app将webview杀死。
然后我们leader爆了，让我排查问题。可是可是，我哪里会排查内存泄漏呀。
我：我不会。你自己不会上吗？你tm天天端个茶，抽个烟，翘个二郎腿，色眯眯的看着ui妹妹。
领导：污蔑，你纯粹就是污蔑。我tm现在就可以让你滚蛋，你信吗？
我：我怕你个鸟哦，我还不知道你啥水平，你tm能写出来个防抖节流，我就给你磕头。
领导：hi～ui妹妹，今天过的好吗，来，哥哥这里有茶喝。（此时ui妹妹路过）。你赶快给我干活，以后ui妹妹留给你。
艹！你早这么说不就好了。

开始学习

Chrome devTools查看内存情况

打开Chrome的无痕模式，这样做的目的是为了屏蔽掉Chrome插件对我们之后测试内存占用情况的影响
打开开发者工具，找到Performance这一栏，可以看到其内部带着一些功能按钮，例如：开始录制按钮；刷新页面按钮；清空记录按钮；记录并可视化js内存、节点、事件监听器按钮；触发垃圾回收机制按钮等

简单录制一下百度页面，看看我们能获得什么，如下动图所示：

从上图中我们可以看到，在页面从零到加载完成这个过程中JS Heap（js堆内存）、documents（文档）、Nodes（DOM节点）、Listeners（监听器）、GPU memory（GPU内存）的最低值、最高值以及随时间的走势曲线，这也是我们主要关注的点

看看开发者工具中的Memory一栏，其主要是用于记录页面堆内存的具体情况以及js堆内存随加载时间线动态的分配情况

堆快照就像照相机一样，能记录你当前页面的堆内存情况，每快照一次就会产生一条快照记录

如上图所示，刚开始执行了一次快照，记录了当时堆内存空间占用为33.7MB，然后我们点击了页面中某些按钮，又执行一次快照，记录了当时堆内存空间占用为32.5MB。并且点击对应的快照记录，能看到当时所有内存中的变量情况（结构、占总占用内存的百分比...）

在开始记录后，我们可以看到图中右上角有起伏的蓝色与灰色的柱形图，其中蓝色表示当前时间线下占用着的内存；灰色表示之前占用的内存空间已被清除释放

在得知有内存泄漏的情况存在时，我们可以改用Memory来更明确得确认问题和定位问题

首先可以用Allocation instrumentation on timeline来确认问题，如下图所示：

内存泄漏的场景

闭包使用不当引起内存泄漏
全局变量
分离的DOM节点
控制台的打印
遗忘的定时器

1. 闭包使用不当引起内存泄漏

使用Performance和Memory来查看一下闭包导致的内存泄漏问题

<button onclick="myClick()">执行fn1函数button>
<script>
function fn1 () {
let a = new Array(10000)  // 这里设置了一个很大的数组对象

let b = 3

function fn2() {
let c = [1, 2, 3]

        }

fn2()

return a

    }

let res = []  

function myClick() {

        res.push(fn1())

    }
script>

在退出fn1函数执行上下文后，该上下文中的变量a本应被当作垃圾数据给回收掉，但因fn1函数最终将变量a返回并赋值给全局变量res，其产生了对变量a的引用，所以变量a被标记为活动变量并一直占用着相应的内存，假设变量res后续用不到，这就算是一种闭包使用不当的例子

设置了一个按钮，每次执行就会将fn1函数的返回值添加到全局数组变量res中，是为了能在performacne的曲线图中看出效果，如图所示：

在每次录制开始时手动触发一次垃圾回收机制，这是为了确认一个初始的堆内存基准线，便于后面的对比，然后我们点击了几次按钮，即往全局数组变量res中添加了几个比较大的数组对象，最后再触发一次垃圾回收，发现录制结果的JS Heap曲线刚开始成阶梯式上升的，最后的曲线的高度比基准线要高，说明可能是存在内存泄漏的问题
在得知有内存泄漏的情况存在时，我们可以改用Memory来更明确得确认问题和定位问题
首先可以用Allocation instrumentation on timeline来确认问题，如下图所示：

在我们每次点击按钮后，动态内存分配情况图上都会出现一个蓝色的柱形，并且在我们触发垃圾回收后，蓝色柱形都没变成灰色柱形，即之前分配的内存并未被清除
所以此时我们就可以更明确得确认内存泄漏的问题是存在的了，接下来就精准定位问题，可以利用Heap snapshot来定位问题，如图所示：

第一次先点击快照记录初始的内存情况，然后我们多次点击按钮后再次点击快照，记录此时的内存情况，发现从原来的1.1M内存空间变成了1.4M内存空间，然后我们选中第二条快照记录，可以看到右上角有个All objects的字段，其表示展示的是当前选中的快照记录所有对象的分配情况，而我们想要知道的是第二条快照与第一条快照的区别在哪，所以选择Object allocated between Snapshot1 and Snapshot2即展示第一条快照和第二条快照存在差异的内存对象分配情况，此时可以看到Array的百分比很高，初步可以判断是该变量存在问题，点击查看详情后就能查看到该变量对应的具体数据了

以上就是一个判断闭包带来内存泄漏问题并简单定位的方法了

2. 全局变量

全局的变量一般是不会被垃圾回收掉的当然这并不是说变量都不能存在全局，只是有时候会因为疏忽而导致某些变量流失到全局，例如未声明变量，却直接对某变量进行赋值，就会导致该变量在全局创建，如下所示：

function fn1() {
// 此处变量name未被声明

    name = new Array(99999999)

}

fn1()

此时这种情况就会在全局自动创建一个变量name，并将一个很大的数组赋值给name，又因为是全局变量，所以该内存空间就一直不会被释放
解决办法的话，自己平时要多加注意，不要在变量未声明前赋值，或者也可以开启严格模式，这样就会在不知情犯错时，收到报错警告，例如

function fn1() {
'use strict';

    name = new Array(99999999)

}

fn1()

3. 分离的DOM节点

假设你手动移除了某个dom节点，本应释放该dom节点所占用的内存，但却因为疏忽导致某处代码仍对该被移除节点有引用，最终导致该节点所占内存无法被释放，例如这种情况

<div id="root">
<div class="child">我是子元素div>
<button>移除button>
div>
<script>
let btn = document.querySelector('button')
let child = document.querySelector('.child')
let root = document.querySelector('#root')


  btn.addEventListener('click', function() {

      root.removeChild(child)

  })
script>

该代码所做的操作就是点击按钮后移除.child的节点，虽然点击后，该节点确实从dom被移除了，但全局变量child仍对该节点有引用，所以导致该节点的内存一直无法被释放，可以尝试用Memory的快照功能来检测一下，如图所示

同样的先记录一下初始状态的快照，然后点击移除按钮后，再点击一次快照，此时内存大小我们看不出什么变化，因为移除的节点占用的内存实在太小了可以忽略不计，但我们可以点击第二条快照记录，在筛选框里输入detached，于是就会展示所有脱离了却又未被清除的节点对象

解决办法如下图所示：

<div id="root">
<div class="child">我是子元素div>
<button>移除button>
div>
<script>
let btn = document.querySelector('button')


    btn.addEventListener('click', function() {  
let child = document.querySelector('.child')
let root = document.querySelector('#root')


        root.removeChild(child)

    })

script>

改动很简单，就是将对.child节点的引用移动到了click事件的回调函数中，那么当移除节点并退出回调函数的执行上文后就会自动清除对该节点的引用，那么自然就不会存在内存泄漏的情况了，我们来验证一下，如下图所示：

结果很明显，这样处理过后就不存在内存泄漏的情况了

4. 控制台的打印

<button>按钮button>
<script>
document.querySelector('button').addEventListener('click', function() {
let obj = new Array(1000000)

console.log(obj);

    })
script>

我们在按钮的点击回调事件中创建了一个很大的数组对象并打印，用performance来验证一下

开始录制，先触发一次垃圾回收清除初始的内存，然后点击三次按钮，即执行了三次点击事件，最后再触发一次垃圾回收。查看录制结果发现JS Heap曲线成阶梯上升，并且最终保持的高度比初始基准线高很多，这说明每次执行点击事件创建的很大的数组对象obj都因为console.log被浏览器保存了下来并且无法被回收

接下来注释掉console.log，再来看一下结果：

<button>按钮button>
<script>
document.querySelector('button').addEventListener('click', function() {
let obj = new Array(1000000)

// console.log(obj);

    })
script>

可以看到没有打印以后，每次创建的obj都立马被销毁了，并且最终触发垃圾回收机制后跟初始的基准线同样高，说明已经不存在内存泄漏的现象了

其实同理 console.log也可以用Memory来进一步验证

未注释 console.log

注释掉了console.log

最后简单总结一下：在开发环境下，可以使用控制台打印便于调试，但是在生产环境下，尽可能得不要在控制台打印数据。所以我们经常会在代码中看到类似如下的操作：

// 如果在开发环境下，打印变量obj
if(isDev) {
console.log(obj)

}

这样就避免了生产环境下无用的变量打印占用一定的内存空间，同样的除了console.log之外，console.error、console.info、console.dir等等都不要在生产环境下使用

5. 遗忘的定时器

定时器也是平时很多人会忽略的一个问题，比如定义了定时器后就再也不去考虑清除定时器了，这样其实也会造成一定的内存泄漏。来看一个代码示例：

<button>开启定时器button>
<script>

function fn1() {
let largeObj = new Array(100000)

setInterval(() => {
let myObj = largeObj

        }, 1000)

    }

document.querySelector('button').addEventListener('click', function() {
fn1()

    })
script>

这段代码是在点击按钮后执行fn1函数，fn1函数内创建了一个很大的数组对象largeObj，同时创建了一个setInterval定时器，定时器的回调函数只是简单的引用了一下变量largeObj，我们来看看其整体的内存分配情况吧：

按道理来说点击按钮执行fn1函数后会退出该函数的执行上下文，紧跟着函数体内的局部变量应该被清除，但图中performance的录制结果显示似乎是存在内存泄漏问题的，即最终曲线高度比基准线高度要高，那么再用Memory来确认一次：

在我们点击按钮后，从动态内存分配的图上看到出现一个蓝色柱形，说明浏览器为变量largeObj分配了一段内存，但是之后这段内存并没有被释放掉，说明的确存在内存泄漏的问题，原因其实就是因为setInterval的回调函数内对变量largeObj有一个引用关系，而定时器一直未被清除，所以变量largeObj的内存也自然不会被释放
那么我们如何来解决这个问题呢，假设我们只需要让定时器执行三次就可以了，那么我们可以改动一下代码：

<button>开启定时器button>
<script>
function fn1() {
let largeObj = new Array(100000)
let index = 0

let timer = setInterval(() => {
if(index === 3) clearInterval(timer);
let myObj = largeObj

            index ++

        }, 1000)

    }

document.querySelector('button').addEventListener('click', function() {
fn1()

    })
script>