Web前端内存泄漏治理

怎么样的Web前端项目需要治理内存泄漏

其实身边很多做Web前端的同事/朋友都不太关心内存泄漏这个话题，或者是他们了解这个话题以及背后对应的技术原因，但是他们没有对应的应用场景。大部份Web前端项目，无论是B端还是C端，无论是移动还是PC，对于用户来说基本上都是“用完即走”，使用时常几分钟到几十分钟不等，很少会有连续使用一个小时以上的情况。

对于当前的硬件配置，只有那些用户需要连续使用几个小时以上的Web前端项目治理内存泄漏问题才有对应的场景和收益。

Web前端内存泄漏治理难吗？

难！

我团队就有一个项目，用户如果没遇到特别的情况一般会连续使用超过8个小时，但由于内存泄漏导致“卡顿”或者“页面崩溃”，有部份用户被迫使用4-5个小时就会刷新页面。为了解决内存泄漏问题，我让团队的同学分两期对问题进行彻底解决。第一轮大概集中了4个人花了3天时间将每一轮操作后内存泄漏减少了10MB左右，但是问题没有彻底解决，有很多零碎的泄漏问题加起来依然会让每轮操作有3MB左右的泄漏；所以我们又组织了另外一轮彻底根治，大概集中了2个人花了大概两周的时间才把问题彻底“根治”，但所谓的根治也只是把水面上的代码导致的泄漏解决了，但是在水面下浏览器的bug/优化策略导致的泄漏依然会导致几K或者几百K的内存泄漏问题。

为什么难？

• 语言层面：弱类型语言虽然给开发体验带来了便利，但是对于内存引用的管理确实一场灾难，很多时候很难通过静态分析发现内存泄漏问题
• 工具层面：虽然在浏览器层面有提供内存快照工具，但能力十分有限，只能提供诸如引用持有关系的，并不会给出泄漏点和泄漏原因等更多的信息
• 应用层面：应用开发过程引入的第三方包，质量参差不齐，技术选型阶段也很少能够通过阅读源码等方式判断是否有内存泄漏风险

体系化内存治理的一些思考

对于一个相对有一定规模的前端团队，个人实践下来是可以比较体系化去做内存泄漏的治理。

1. 存量问题的解决

这个过程一般比较痛苦，面对一个大型应用我们大概花了14人日（两人两周）的时间彻底解决，也算是团队内内存泄漏治理的经验沉淀。

2. 事前发现

团队内部对第三方包/库沉淀一个安全的清单，当团队成员需要引入第三方包时需要判断是否是安全可允许的，若不在安全清单中则需要通过内存压测工具证明新包引入不会带来内存泄漏问题，等新包完整通过测试上线后添加进团队的安全清单。

3. 事中发现

当然2中提到的使用压测工具证明的操作可能会存在漏网之鱼，人是不可靠的，只有流程是可靠的。所以需要在上线的流水线上常驻一个性能劣化检测卡点，一旦发现新版本引入裂化问题会阻塞版本上线。

4. 事后发现

一般3中提到的卡点，为了避免影响上线的效率检测过程比较短，不会跑完整的用例，所以还需要每天/每小时通过巡检的方式跑全量的检测用例。