[实战] Flutter 上的内存泄漏监控

时间  2020-06-18
标签 实战 flutter 内存 泄漏 监控 繁體版
原文   原文链接

1、前言

Flutter 所使用的 Dart 语言具备垃圾回收机制，有垃圾回收就避免不了会内存泄漏。
在 Android 平台上有个内存泄漏检测工具 LeakCanary，
它能够方便地在 debug 环境下检测当前页面是否泄漏。
本文将会带你实现一个 Flutter 可用的 LeakCanary，
并讲述我是怎么用该工具检测出了 1.9.1 Framework 上的两个泄漏。git

2、Dart 中的弱引用

在具备垃圾回收的语言中，弱引用是检测对象是否泄漏的一个好方式。
咱们只需弱引用观测对象，等待下次 Full GC，
若是 GC 以后对象为 null，说明被回收了，
若是不为 null 就多是泄漏了。github

Dart 语言中也有着弱引用，它叫 Expando<T> ，
看下它的 API：api

<!-- skip -->数组

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

你可能会好奇上述代码弱引用体如今哪里呢？
实际上是在 expando[key]=value 这个赋值语句上。
Expando 会以弱引用的方式持有 key，这里就是弱引用的地方。缓存

那么问题来了，这个 Expando 弱引用持有的是 key，
可是自己又没有提供 getKey() 这样的 API，
咱们就无从下手去得知 key 这个对象是否被回收了。app

为了解决这个问题，咱们来看下 Expando 的具体实现，
具体的代码在 expando_path.dart：async

<!-- skip -->ide

@path
class Expando<T> {
  // ...
  T operator [](Objet object "") {
    var mask = _size - 1;
    var idx = object._identityHashCode & mask;
    // sdk 是把 key 放到了一个 _data 数组内，这个 wp 是个 _WeakProperty
    var wp = _data[idx];

    // ... 省略部分代码
    return wp.value;
    // ... 省略部分代码
  }
}
注意: 此 patch 代码不适用于 Web 平台

咱们能够发现这个 key 对象是放到了 _data 数组内，
用了一个 _WeakProperty 来包裹，那么这个 _WeakProperty 就是关键类了，
看下它实现，代码在 weak_property.dart：函数

<!-- skip -->工具

@pragma("vm:entry-point")
class _WeakProperty {

  get key => _getKey();
  // ... 省略部分代码
  _getKey() native "WeakProperty_getKey";
  // ... 省略部分代码
}

这个类有咱们想要的 key，能够用于判断对象是否还在。

怎么获取这种私有属性和变量呢？
Flutter 中的 Dart 是不支持反射的（为了优化打包体积，关闭了反射），
有没有其余办法来获取到这种私有属性呢？

答案确定是 “有”，为了解决上述问题，
我来向你们介绍一个 Dart 自带的服务——
Dart VM Service。

3、Dart vm_service

Dart VM Service （后面简称 vm_service）
是 Dart 虚拟机内部提供的一套 Web 服务，数据传输协议是 JSON-RPC 2.0。
不过咱们并不须要要本身去实现数据请求解析，
官方已经写好了一个可用的 Dart SDK 给咱们用：vm_service。

ObjRef, Obj 和 id 的做用

先介绍 vm_service 中的核心内容：ObjRef、Obj、id

vm_service 返回的数据主要分为两大类，
ObjRef（引用类型） 和 Obj（对象实例类型）。
其中 Obj 完整的包含了 ObjRef 的数据，
并在其基础上增长了额外信息
（ObjRef 只包含了一些基本信息，例如：id，name 等）。

基本全部的 API 返回的数据都是 ObjRef，
当 ObjRef 里面的信息知足不了你的时候，
再调用 getObject(,,,)来获取 Obj。

关于 id： Obj 和 ObjRef 都含有 id，
这个 id 是对象实例在 vm_service 里面的一个标识符，
vm_service 几乎全部的 API 都须要经过 id 来操做，
好比：getInstance(isolateId, classId, ...)、
getIsolate(isolateId)、
getObject(isolateId, objectId, ...)。

如何使用 vm_service 服务

vm_service 在启动的时候会在本地开启一个 WebSocket 服务，
服务 URI 能够在对应的平台中得到：

  • Android 在 FlutterJNI.getObservatoryUri() 中；
  • iOS 在 FlutterEngine.observatoryUrl 中。

有了 URI 以后咱们就可使用 vm_service 的服务了，
官方有一个帮咱们写好的 SDK: vm_service ，
直接使用内部的 vmServiceConnectUri 就能够得到一个可用的 VmService 对象。

vmServiceConnectUri 的参数须要是一个 ws:// 协议的 URI，默认获取的是 http 协议，须要借助 convertToWebSocketUrl方法转化下

4、泄漏检测实现

有了 vm_service 以后，咱们就能够用它来弥补 Expando 的不足了。
按照以前的分析，咱们要获 Expando 的私有字段 _data，
这里可使用 getObject(isolateId, objectId)") API，
它的返回值是 Instance，
内部的 fields 字段保存了当前对象的全部属性。
这样咱们就能够遍历属性获取到 _data，来达到反射的效果。

如今的问题是 API 参数中的 isoateId 和 objectId 是什么呢？
根据我前面介绍的 id 相关内容，它是对象在 vm_serive 中的标识符。
也就是咱们只有经过 vm_service 才能够获取到这两个参数。

IsolateId 的获取

Isolate（隔离区）是 Dart 里面的一个很是重要的概念，
基本上一个 isolate 至关于一个线程，
可是和咱们日常接触的线程不一样的是：不一样 isolate 之间的内存不共享。

由于有了上述特性，咱们在查找对象的时候也要带上 isolateId。
经过 vm_service 的 getVM() API 能够获取到虚拟机对象数据，
再经过 isolates 字段能够获取到当前虚拟机全部的 isolate。

那么怎么筛选出咱们想要的 isolate 呢？
这里简单起见只筛选主 isolate，
这部分的筛选能够查看 dev_tools
的源码: service_manager.dart#_initSelectedIsolate 函数。

ObjectId 的获取

咱们要获取的 objectId 就是 expando 在 vm_service 中的 id，
这里能够把问题扩展下：

如何获取指定对象在 vm_service 中的 id？

这个问题比较麻烦，vm_service 中没有实例对象和 id 转换的 API，
有个 getInstance(isolateId, classId, limit) 的 API，
能够获取某个 classId 的全部子类实例，
先不说如何获取到想要的 classId，
此 API 的性能和 limit 都让人担心。

没有好办法了吗？其实咱们能够
借助 Library 的 顶级函数（直接写在当前文件，不在类中，例如 main 函数）
来实现该功能。

简单说明下 Library 是什么东西，Dart 中的分包管理是根据 Library 来的，同一个 Library 内的类名不能重复，通常状况下一个 .dart 文件就是一个 Library，固然也有例外，好比：part of 和 export。

vm_service 有个 invoke(isolateId, targetId, selector, argumentIds)") API，
能够用来执行某个常规函数
（getter、setter、构造函数、私有函数属于很是规函数），
其中若是 targetId 是 Library 的 id，那么 invoke
执行的就是 Library 的顶级函数。

有了 invoke Library 顶级函数的路径，
就能够用它实现对象转 id 了，代码以下：

<!-- skip -->

int _key = 0;
/// 顶级函数，必须常规方法，生成 key 用
String generateNewKey() {
  return "${++_key}";
}

Map<String, dynamic> _objCache = Map();
/// 顶级函数，根据 key 返回指定对象
dynamic keyToObj(String key) {
  return _objCache[key];
}

/// 对象转 id
String obj2Id(VMService service, dynamic obj) async {

  // 找到 isolateId。这里的方法就是前面讲的 isolateId 获取方法
  String isolateId = findMainIsolateId();
  // 找到当前 Library。这里能够遍历 isolate 的 libraries 字段
  // 根据 uri 筛选出当前 Library 便可，具体不展开了
  String libraryId = findLibraryId();

  // 用 vm service 执行 generateNewKey 函数
  InstanceRef keyRef = await service.invoke(
    isolateId,
    libraryId,
    "generateNewKey",
    // 无参数，因此是空数组
    []
  );
  // 获取 keyRef 的 String 值
  // 这是惟一一个能把 ObjRef 类型转为数值的 api
  String key = keyRef.valueAsString;

  _objCache[key] = obj;
  try {
    // 调用 keyToObj 顶级函数，传入 key，获取 obj
    InstanceRef valueRef = await service.invoke(
      isolateId,
      libraryId,
      "keyToObj",
      // 这里注意，vm_service 须要的是 id，不是值
      [keyRef.id]
    )
    // 这里的 id 就是 obj 对应的 id
    return valueRef.id;
  } finally {
    _objCache.remove(key);
  }
  return null;
}

对象泄漏判断

如今咱们已经能够获取到 expando 实例在
vm_service 中的 id 了，接下来就简单了。

先经过 vm_service 获取到 Instance，
遍历里面的 fields 属性，找到 _data 字段
（注意 _data 是 ObjRef 类型），
用一样的办法把 _data 字段转成 Instance 类型
（_data 是个数组，Obj 里面有数组的 child 信息）。

遍历 _data 字段，若是都是 null，
代表咱们观测的 key 对象已经被释放了。
若是 item 不为 null，
再次把 item 转为 Instance 对象，
取它的 propertyKey
（由于 item 是 _WeakProperty 类型，
Instance 里面特意为 _WeakProperty 开了这个字段）。

强制 GC

文章开头说到，若是要判断对象是否泄漏，
须要在 Full GC 以后判断弱引用是否还在。
有没有办法手动触发 GC 呢？

答案是有的，vm_service 虽然没有强制 GC 的 API，
可是 Dev Tools 的内存图标右上角有个 GC 的按钮，
咱们仿照着它来操做就行！
Dev Tools 是调用了 vm_service 的
getAllocationProfile(isolateId, gc: true)") API
来实现手动 GC 的。

至于这个 API 触发的是否是 FULL GC，
并无说明，我测试触发的都是 FULL GC，
若是要肯定在 FULL GC 以后检测泄漏，
能够监听 gc 事件流，
vm_service 提供了该功能。

至此为止，咱们已经能够实现泄漏的监控，
并且能够获取到泄漏目标在 vm_serive 中的 id 了，
下面就开始获取分析泄漏路径。

5、获取泄漏路径

关于泄漏路径的获取，
vm_service 提供了一个 API 叫 getRetainingPath(isolateId, objectId, limit)")。
直接使用此 API 就能够获取到泄漏对象到 GC Roots 的引用链信息，
是否是感受很简单？不过光这样可不行，
由于它有如下几个坑点：

Expando 持有问题

若是在执行 getRetainingPath 的时候，
泄漏对象被 expando 持有的话会产生如下两个问题

  • 由于该 API 返回的引用链只有一条，
    返回的引用链会通过 expando，致使没法获取真正的泄漏节点信息；
  • 在 ARM 设备上会出现 native crash，
    具体错误出如今 utf8 字符解码上。

此问题很好解决，注意下在前面泄漏检测完以后，
释放掉 expando 就行。

id 过时问题

Instance 类型的 id 和 Class、Library、Isolate
这种 id 不同，是会过时的。
vm_service 中对于此类临时 id 的缓存容量默认大小是 8192，
是一个循环队列。

由于此问题的存在，咱们在检测到泄漏的时候，
不能只保存泄漏对象的 id，须要保存原对象，
并且不能强引用持有对象。
因此这里咱们仍是须要使用 expando
来保存咱们检测到的泄漏对象，
等到须要分析泄漏路径的时候，
再把对象专为 id。

6、1.9.1 Framework 上的内存泄漏

完成了泄漏检测和路径获取以后，
获得了一个简陋的 leakcanary 工具。
当我在 1.9.1 版本的 Framework 下测试此工具的时候发现，
我观测一个页面它就泄漏一个页面！！！

经过 dev_tools dump 出来的对象来看，的确泄漏了！

也就是 1.9.1 Framework 里面存在着泄漏，
并且此泄漏会泄漏整个页面。

接下来开始排查泄漏缘由，这里就碰到一个问题：
泄漏路径太长：getRetainingPath 返回的链路长度有 300+，
排查了一下午也没有找到问题根源。

结论：直接根据 vm_service 返回的数据是很难分析问题来源的，
须要对泄漏路径的信息二次处理下。

如何缩短引用链

首先看下泄漏路径为何会这么长，
经过观测返回的链路后发现，
绝大部分的节点都是 Flutter UI 组件节点
（例如：widget、element、state、renderObject）。

也就是说引用链通过了 Flutter 的 widget tree，
熟悉 Flutter 的开发者应该都知道，
Flutter 的 widget tree 的层次是很是深的。
既然引用链长的缘由是由于包含了 widget tree，
并且 widget tree 基本都是成块出现的，
那咱们只要把引用链中的节点根据类型来分类、聚合，
就能够大幅缩短泄漏路径了。

分类

根据 Flutter 的组件类型，将节点分为如下几种类型：

  • element：对应 Element 节点；
  • widget：对应 Widget 节点；
  • renderObject：对应 RenderObject节点；
  • state：对应 State<T extends StatefulWdget> 节点；
  • collection：对应集合类型节点，例如：List、Map、Set；
  • other：对应其余节点。

聚合

节点的分类作好了以后，就能够把相同类型的节点聚合一下。
这里提下个人聚合方式：

把 collection 类型的节点当作了链接节点，
相邻的相同节点合并到一个集合内，
若是两个相同类型的集合中间是经过 collection 节点相连的，
就继续把这两个集合合并成一个集合，递归进行。

经过 分类-聚合 的处理后，原先 300+ 的链路长度，能够缩短为 100+。

继续排查 1.9.1 Framework 的泄漏问题，
路径虽然缩短了，能够找到问题大体出如今 FocusManager 节点上！
可是具体问题仍是难以定位，主要有如下两点：

  • 引用链节点缺乏代码位置：由于 RetainingObject 数据中只有 parentField、parentIndex 和 parentKey 三个字段来表示当前对象引用下一个对象的信息，经过该信息找代码位置效率低下；
  • 没法知道当前 Flutter 组件节点的信息：好比 Text 的文本信息，element 所在的 widget 是啥，state 的生命周期状态，当前组件属于哪一个页面，等等。

介于上述两个痛点，还须要对泄漏节点的信息作扩展处理：

  • 代码位置：节点的引用代码位置其实只须要解析 parentField 就行，经过 vm_serive 解析 class，取内部的 field，找到对应的 script 等信息。此方法能够获取到源码；
  • 组件节点信息：Flutter 的 UI 组件都是继承自 Diagnosticable，也就是只要是 Diagnosticable 类型的节点均可获取到很是详细的信息（dev_tools 调试时候，组件树信息就是经过 Diagnosticable.debugFillProperties 方法获取的）。除了这个还须要扩展当前组件所在 route 的信息，这个很重要，判断组件所在页面用。

排查 1.9.1 Framework 泄漏根源

经过上述的种种优化后，我获得了下面这个工具，
在两个 _InkResponseState 节点中发现了问题：

泄漏路径中有两个 _InkResponseState 节点所属的 route 信息不一样，
代表这两个节点在两个不一样的页面中。
顶部 _InkResponseState 的描述信息显示 lifecycle not mounted，
说明组件已经销毁了，可是仍是被 FocusManager 引用着！
问题出如今这，来看下这部分代码

代码中能够明显的看到 addListener 时候
对 StatefulWidget 的生命周期理解错误。
didChangeDependencies 是会屡次调用的，
dispose 只会调用一次，
因此这里就会出现 listener 移除不干净的状况。

修复了上述泄漏以后，发现还有一处泄漏。
排查后发现泄漏源在 TransitionRoute 中：

当打开一个新页面的时候，
该页面的 Route（也就是代码中的 nextRoute）
会被前一个页面的 animation 所持有，
若是页面跳转都是 TransitionRoute，
那么全部的 Route 都会泄漏！

好消息是以上泄漏都在 1.12 版本以后修复了。

修复完上述两个泄漏以后，
再次测试，Route 和 Widget 均可以回收了，
至此 1.9.1 Framework 排查完毕。

本文做者： 戚耿鑫

现就任于快手应用研发平台组 Flutter 团队，负责 APM 方向开发研究。从 2018 年开始接触 Flutter，在 Flutter 混合栈、工程化落地、UI 组件等方面有大量经验。

联系方式：qigengxin@kuaishou.com

「Flutter 中文社区教程」由社区的开发者投稿，内容同步发布到 flutter.cn 网站以及 「Flutter 社区」的各个社交平台。本项目内部测试中，筹备完成后会开放投稿。

在 flutter.cn 阅读本文：https://flutter.cn/community/...

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程