如何排查网页在哪里发生了内存泄漏?

大家好,我是前端西瓜哥。

今天我们来学习用 devtool 的 Performance 和 Memory 工具来找出网页哪里发生了内存泄漏。

Performace 面板

首先我们打开浏览器的 devtool,选择 Performance(性能)面板,然后将 Memory 选项勾选上。不勾选的话,就不会记录内存使用情况,内存泄漏分析就无从说起了。

然后进行性能数据收集:

  1. 点击左上角的 “录制” 按钮(一个灰色的圆形),或者点它旁边的 “刷新” 按钮,会重新加载页面并开始记录,这样就不用手动刷新然后手忙脚乱地点录制按钮了;

  2. 在页面上执行可能发生内存泄漏的操作,比如打开一个弹窗,然后再关闭;

  3. 差不多了就再点击 “录制” 按钮,结束录制,然后出现下面图片的结果。

图片

查看内存指标

看看内存的使用情况。有这么几步:

  1. 选中要分析的范围;

  2. 选中 Main(主线程)。只有选中的话,内存图表才能显示主线程对应的信息;

  3. 查看内存图表的指标。

图片

内存图表是一些折线图,记录了内存指标随时间发生的变化。这些内存指标有:JS 堆内存、Document 数、节点数、绑定监听器数量、GPU 内存。

点击它们可显示或隐藏对应的折线图。

对于  JS Heap(11.9MB - 25.6MB) ,它表示的是在当前时间范围内,JS 堆内存最小值为 11.9 MB,最大为 25.6 MB。

将光标悬停在折线图上,可以看到对应的值:

图片

查看内存下限的变化

内存会增长是正常的现象。比如我们调用函数,会创建一些临时变量,导致内存升高。函数执行完,这些变量就没用了,但不会马上回收,而是会在适当的时机进行内存回收,将内存再降下去。

临时分配的短命内存我们并不关心,我们更关注的是一些常驻的内存,对应的要看的是 内存下限的变化

图片

如果内存下限不断上升,说明常驻内存变大了。大多数情况下是正常的,比如:

  1. 调用函数,将函数返回的结果进行缓存;

  2. 创建新的组件。

也可能是内存泄漏了。

当怀疑是内存泄漏时,我们就可以使用 Memory 面板记录快照,做进一步的排查。

Memory 面板

打开 Memory 面板,点击左上角的 “录制按钮”,生成当前时刻的堆内存快照。然后通过快照了解 JS 对象的内存分布

图片

Summary View

快照结果默认会展示为 概要视图(Summary View)

图片

这个表格的表格项是基于构造函数进行归类的。可以看到有不少原生的构造函数,还有一堆闭包。

每个项有以下几个属性:

  • Constructor:构造函数。对于没有构造函数的字面量,用类似 (string)(array) 的表示;

  • Distance:到根节点的最短路径;

  • Shallow Size:自己占用的内存大小,不包括它引入的其他对象内存,单位为字节;

  • Retained Size:对象自己以及它引用的对象的内存,单位也是字节;

  • Object Count:对象数量,就是 Constructor 名旁边那个数字;

上面是默认的 Summary View 视图。

除了它,我们还有其他的视图,可以像下面这样进行视图类型的切换。

图片

Comparison View

比较视图(Comparison View)则是用来比较两个快照的变化

图片

这里我选中了快照 3,然后将对比快照设置为 快照 1。

这个表格表示从快照 1 变成快照 3 发生的变化。没有发生变化的项不会进行展示。

字段有:

  • Constructor:构造函数;

  • #New:新增的对象数量;

  • #Deleted:删除的对象数量;

  • #Delta:总体上的对象变化数量;

  • Alloc.Size:分配的总内存;

  • Freed Size:释放了多少内存;

  • Size Delta:总体上的内存变化;

Containment View

该视图可以让我们从根节点为起点,往下去查看各种对象占用的内存,以及被创建的代码位置等信息。

图片

字段:

  • Object:普通对象或者 DOM 节点:

  • Distance:到根节点的距离;

  • Shallow Size:对象大小,不计算引用的对象;

  • Retained Size:对象大小,但其引用的对象大小也计算在内;

Statistics View

圆环统计表。

各种内存类型的占总内存的百分比情况。

图片

使用 Memory 面板注意事项

尽量减少干扰项的影响力。

  1. 分辨正常的内存变化会的干扰;

  2. 注意开发环境的打包器热加载逻辑等的影响;

  3. 生成环境的代码是混淆过的,一些构造器名字很奇怪,如果可以的话,本地打包一份没经过混淆过的代码做 debug。或者也可以 hover 看看对象结构猜测对应构造器,但效率不高。

  4. 不要有浏览器插件,它们也占用和影响内存,可以用无痕浏览器。

常见内存泄漏原因和排查

忘记及时取消监听器绑定

新手老鸟都容易犯的错误,就是 忘记及时取消监听器绑定。它会导致:

  1. 监听器函数中的对象迟迟不能释放,比如非常大的组件实例;

  2. 绑定大量无用的监听器函数。

怎么排查?

如果监听器是绑定到 DOM 中,我们可以不断执行可以看 Listener 数量的变化。

我写了个弹窗组件,它会在挂载时给 document.body 注册一个函数,然后这个函数会用到这个组件下的变量。但销毁时不取消注册。

打开 Performance 面板,录制,然后不停打开和关闭弹窗,然后结束录制。我们就能看这个 Listeners 的数量的变化,不断地变高那就是忘了。

图片

也可以看看 Memoery 面板中 Comparison View 的快照对比中,EventListener 数量的变化:

图片

具体是哪个,可以看 EventListener 下的最后几个对象。

图片

点击这个蓝色的链接,就能跳到对应的代码位置:

图片

此外,还可以用 Chrome 控制台提供的 getEventListeners(element) 方法,它会返回一个元素事件绑定的函数有哪些。这个方法不是标准方法,是 Chrome 自带的工具方法,只能在控制台上用。我们可以写个方法,从根节点往下找,找出绑定函数数量最多的节点,这个节点多得离谱那就大概率是忘了解绑。

如果不是 DOM 上的监听器,比如发布订阅库的事件集合,那就要看构造器对应对象数量的变化了。

闭包

闭包就是拿到函数 A 内的另一个函数 B,函数 B 会捕获到函数 A 作用域中的变量。

这个就导致了对一些对象的隐式引用,比如一个 DOM 元素。我们需要在不需要使用时将其设置为 null。

我们可以看看有没有什么 Detached 的元素。Detached 表示不在当前文档树上,如果持续增多,可能发生了内存泄漏。

图片

说真的闭包是一个正常的特性,没理由和内存泄漏有关才是。

函数 B 被持有不销毁,自然它捕获的函数 A 中的变量就不能销毁,和对象里有一些属性,这些属性不能销毁没啥区别。函数 B 销毁了,对应的变量自然也就回收了。

有空我再研究下写篇专题。

console

“你到底都打印了些什么啊?”

还有个比较常见的就是,在开发的时候用 console 打印一些对象,合并到主分支又忘记去掉。这些对象是不会被回收的,因为开发者可能会去控制台看看这些对象的内容。这在打印大量大对象时会出性能问题。

排查方法很简单,去看 DevTool 的控制台输出了什么内容,看看有没有大对象

一些有助于 debug 的 console 是有必要的,但不要滥用。

集合类型的缓存爆炸

我们经常用对象、数组、Map、Set 等集合类型,去做数据的缓存。

当缓存大量对象时,会占用大量的内存,但其中有不少内容是不需要用的。对于前端来说,内存不像后端那样纯金寸土,动不动就是大批量数据要处理,缓存使用起来挺随意的。

对于缓存问题,还要要有点意识,我们可以:

  1. 使用 LRU 算法,将最久没使用的缓存移除,控制缓存数量;

  2. 设置缓存过期时间;

  3. 对于临时缓存,考虑使用  WeakMap 和 WeakSet,它们会在 GC 时强制回收;

这些就没啥好分析的,就看看内存下限变化,某些对象是否变大变多了。

结尾

今天带大家简单入门了 devtool 提供的内存分析工具,但光说不练假把式,还是要多多实战。

我是前端西瓜哥,欢迎关注我,学习更多前端知识。

本文首发于我的公众号:前端西瓜哥

如何排查网页在哪里发生了内存泄漏?

https://blog.fstars.wang/posts/how-to-check-memory-leak-in-webpage/

作者

前端西瓜哥

发布于

2022-12-12

更新于

2023-10-14

许可协议