Flutter 自动化内存泄漏检测

内存泄漏原理

对于一个对象实例，正常情况下，生命周期结束后，应当被垃圾回收器回收，释放内存。

在问题场景下，一个生命周期已经结束的实例，仍有其它实例对其持有引用（应当被释放而没释放），这时垃圾回收器回收时，它看到该实例还有引用，没有进行释放。从垃圾回收器的机械视角，它认为一个实例还有引用指向它，那这个实例就还有用，不应该释放。如果没有引用（只有 GC Root 一个引用），那就是没用了，可以回收了。

当一个对象实例生命周期结束后，被原本不该引用的关系引用，导致垃圾回收器没有将其释放，这种情况就被称为内存泄漏。

内存泄漏检测原理

一个实例持有另一个实例，称为引用，引用关系主要可分为两种：强引用，弱引用。

强引用会增加被持有实例的引用计数，参与垃圾回收器统计。弱引用不会增加引用技术，持有的实例随时可能被回收。

内存泄漏检测技术，就是利用了弱引用的特性。

对于需要监控的实例，通过弱引用对其进行引用，当该实例生命周期结束后（由业务决定），进行一次 Full GC，通过弱引用再去访问该实例，如果还在，说明泄漏了，如果为空，说明没有发生泄漏问题。

内存泄漏检测的难点在于时机的把控，弱引用建立时机、判断生命周期结束的时机。

如果时机选择不对，比如一个对象刚创建实例，就去检测，发现弱引用实例还在，爆出虚假内存泄漏，属于误报。检测的难点之一就是做到不误报。

基础知识

class Expando<T> {
  external T operator [](Object object);
  external void operator []=(Object object, T value);
}

检测原理

内存泄漏分析分为以下流程：

内存泄漏检测的一个关键是确定检测的时机，这个时机是跟着被检测对象的生命周期走的。

什么是被检测对象的生命周期？是从业务角度预先得知的该对象什么时候有用，什么时候没用。并且因开发领域的不同，生命周期的概念是不同的。比如：

• 前端角度：以页面维度进行资源监控，页面打开时是生命周期的开始，页面结束后是生命周期的结束，按理说，页面退出之后，与之伴随创建的资源都应当被释放，恢复到页面打开前的水平
• 后端角度：以接口维度进行资源监控，请求响应时是生命周期的开始，请求结束后是生命周期的结束，按理说，请求结束之后，与之伴随创建的资源都应当被释放，恢复到请求发生前的水平

Flutter 属于前端场景，对于前端场景而言，通常以页面维度进行监控。在 Flutter 中，没有一个确切的页面实体，通常以 Navigator 过场中，传入 Route 的 Widget 作为一个页面。

检测内存泄漏

首先要触发 Full GC：参考 DevTools 实现，Dev Tools 是调用了 vm_service 的 getAllocationProfile(isolateId, gc: true)

判断是否有实例泄漏，即判断 Expando 的 _data 属性是否为空，如果不为空，说明泄漏了。

获取泄漏路径：vm_service 提供了一个 API 叫 getRetainingPath(isolateId, objectId, limit)，API 给出的路径有些冗长，需要进行简化缩短

监控实例实际

在 generateRoute 路由创建时对页面 Widget 进行监控。参考文献2。

State 监控，有侵入式，添加基类，方式。参考文献2。

进行检查监控

基于 NavigatorObserver 的 didPop，延时 400ms 进行检测。参考文献2。