当我们谈论内存时,通常说的是物理内存(Physical memory),同一个应用程序运行在不同机器或者操作系统上时,会因不同操作系统和机器的硬件条件的不同,分配的到物理内存大小会有所不同,但大致而言,一款应用程序所使用到的虚拟内存(Virtual Memory)而言便会大致一样,本文讨论的都指的是虚拟内存。
我们可以直观的理解,代码中操作的所有对象都是能用虚拟内存衡量,而不太关心对象是否存在于物理内存与否,只要能减少对象的应用,尽量少的持有对象,不管白猫黑猫,能减少对象的,都是“好猫”。
▐ 讨论flutter内存时,我们在谈论什么
flutter从使用的语言上,可以分成3大部分:
-
Framework层 由Dart编写,开发者接触到顶层,用于应用层开发
-
Engine 层,由C/C++编写,主要进行图形渲染
-
Embedder层,由植入层语言编写,如iOS使用Objective-C/swift,Android使用java
当我们从进程角度谈论flutter应用的内存时,指的是这个三者所有的内存的总和。
为简化,这里可以简单的以使用者能直接接触的代码为边界,将其分成DartVM和native内存, DartVM指Dart虚拟机占用内存,而native内存包含Engine和平台相关的代码运行的内存。
既然说Flutter的使用者能接触到的最直接的对象都是使用Dart语言生成的对象,那么对于Engine层的对象的创建与销毁,使用者似乎鞭长莫及了?这就不得不说Dart虚拟机绑定层的设计了。
▐ Dart绑定层如何工作
===
出于性能或者跨平台或其他原因,脚本语言或者基于虚拟机的语言都会提供c/c++或函数对象绑定到具体语言对象的接口,以便在语言中接着操控c/c++对象或函数,这层API称为绑定层。例如: 最易嵌入应用程序中的Lua binding ,Javascript V8 引擎的binding 等等。
Dart虚拟机在初始化时,会将C++声明的某个类或者函数和某个函数和Dart中的某个类或者绑定起来,依次注入Dart运行时的全局遍历中,当Dart代码执行某一个函数时,便是指向具体的C++对象或者函数。
下面是几个常见的绑定的几个c++类和对应的Dart类
flutter::EngineLayer --> ui.EngineLayer
flutter::FrameInfo --> ui.FrameInfo
flutter::CanvasImage --> ui.Image
flutter::SceneBuilder --> ui.SceneBuilder
flutter::Scene --> ui.Scene
以 ui.SceneBuilder一个例子了解下Dart是如何绑定c++对象实例,并且控制这个c++实例的析构工作。
Dart层渲染过程是配置的layer渲染树,并且提交到c++层进行渲染的过程。ui.SceneBuilder便是这颗渲染树的容器
-
Dart代码调用构造函数 ui.SceneBuilder()时,调用c++方法 SceneBuilder_constructor
-
调用 flutter::SceneBuilder的构造方法并生成c++实例sceneBuilder
-
因 flutter::SceneBuilder 继承自内存计数对象 RefCountedDartWrappable,对象生成后会内存计数加1
-
将生成c++实例sceneBuilder使用Dart的API生成一个 WeakPersitentHandle,注入到Dart上下中。在这里之后,Dart便可使用这个 builder对象,便可操作这个c++的 flutter::SceneBuilder实例。
-
程序运行许久后,当Dart虚拟机判断Dart 对象builder没有被任何其他对象引用时(例如简单的情况是被置空builder=null,也称为无可达性),对象就会被垃圾回收器(Garbage Collection)回收释放,内存计数将会减一
-
当内存计数为0时,会触发c++的析构函数,最终c++实例指向的内存块被回收
可以看到,Dart是通过将C/C++实例封装成WeakPersitentHandle且注入到Dart上下文的方式,从而利用Dart虚拟机的GC(Garbage Collection)来控制C/C++实例的创建和释放工作。
更直白而言,只要C/C++实例对应的Dart对象能正常被GC回收,C/C++所指向的内存空间便会正常释放。
▐ WeakPersistentHandle是什么
因为Dart对象在VM中会因为GC整理碎片化中经常移动,所以使用对象时不会直接指向对象,而是使用句柄(handle)的方式间接指向对象,再者c/c++对象或者实例是介乎于Dart虚拟机之外,生命周期不受作用域约束,且一直长时间存在于整个Dart虚拟机中,所以称为常驻(Persistent),所以WeakPersistentHandle专门指向生命周期与常在的句柄,在Dart中专门用来封装C/C++实例。
在flutter官方提供的Observatory工具中,可以查看所有的WeakPersistentHandle对象。
其中Peer这栏也就是封装c/c++对象的指针。
▐ Dart对象的可达性
Dart对象释放会被垃圾回收器(Garbage Collection)进行释放,是通过判定对象是否还有可达性(availability)来达到的。可达性是指通过某些根节点出发,通过对象与对象间的引用链去访问对象,如可通过引用链去访问对象,则说明对象有可达性,否则无可达性。
黄色有可达性,蓝色无可达性。
难以察觉的内存泄漏
看到这里我们会发现一个问题,其实我们很难从Dart侧感知C/C++对象的消亡,因为Dart对象无统一的如同C++类一样的析构函数,一旦对象因为循环引用等的原因被长期其他对象长期引用,GC将无法将其释放,最终导致内存泄漏。
将问题放大一点,我们知道flutter是一个渲染引擎,我们通过编写Dart语言构建出一颗Widget树,进而经过绘制等过程简化成Element树,RenderObject树,Layer树,并将这颗Layer树提交至C++层,进而使用Skia进行渲染。
如果某个Wigdet树或Element树的某个节点长期无法得到释放,将可能造成他的子节点也牵连着无法释放,将泄漏的内存空间迅速扩大。
例如,存在两个A,B界面,A界面通过Navigator.push的方式添加B界面,B界面通过Navigator.pop回退到A。如果B界面因为某些写法的缘故导致B的渲染树虽然被从主渲染树解开后依然无法被释放,这会导致整个原来B的子树都无法释放。
===
通过检测渲染树节点来检测内存泄漏
====================
基于上面的这一个情况,我们其实可以通过对比当前帧使用到的渲染节点个数,对比当前内存中渲染节点的个数来判断前一个界面释放存在内存泄漏的情况。
Dart代码中都是通过往 ui.SceneBuilder添加EngineLayer的方式去构建渲染树,那么我们只要检测c++中内存中EngineLayer的个数,对比当前帧使用的EngineLayer个数,如果内存中的EngineLayer个数长时间大于使用的个数,那么我们可以判断存在有内存泄漏。
依然以上次A页面pushB界面,B界面pop回退A界面为例子。正常无内存泄漏的情况下,正在使用的layer个数(蓝色),内存中的layer个数(橙色)两条曲线的虽然有波动,但是最终都会比较贴合。
但是在B页面存在内存泄漏的时候,退到A界面后,B树完全无法释放,内存中的layer个数(橙色)无法最终贴合蓝色曲线(正在使用的layer个数)也就是说,对于渲染而言,如果代码导致Widget树或Element树长时间无法被GC回收,很可能会导致严重的内存泄漏情况。
▐ 什么导致了内存泄漏?
目前发现异步执行的代码的场景(Feature, async/await,methodChan)长期持有传入的BuildContext,导致 element 被移除后,依然长期存在,最终导致以及关联的 widget, state 发生泄漏。
再继续看B页面泄漏的例子
正确与错误的写法的区别在于,错误的仅是在调用Navigator.pop之前,使用异步方法Future引用了BuildContext,便会导致B界面内存泄漏。
▐ 怎么发现泄漏点?
推荐学习资料
- 脑图
《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》,点击传送门,即可获取!
▐ 怎么发现泄漏点?
推荐学习资料
- 脑图
[外链图片转存中…(img-NWdGvTEC-1715395529898)]
[外链图片转存中…(img-gjzxKnE7-1715395529899)]
[外链图片转存中…(img-kZnlCqXt-1715395529900)]
《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》,点击传送门,即可获取!