1. Flutter 三棵树
Flutter 的自渲染离不开 Flutter 三棵树:
- Widget:描述 UI 渲染的配置信息
- Element:存放上下文,持有 Widget 和 RenderObject
- RenderObject:实际渲染树中的对象
我们在debug断点某个Widget的时候可以得到如下的配置信息:
上图的 StatelessElement 就是 FirstRoute 这个Widget 对应的 Element,我们知道 Element 是持有 Widget 和 RenderObject,此处的 _widget 就是此 Element 持有的 Widget。有同学可能会问,怎么没有看到此 Element 持有的 RenderObject?因为 Widget 和 Element 是一一对应的,但是与 RenderObject 不是一一对应的。也即是说不是所有的 Element 都有对应的 RenderObject,只有 RenderObjectWidget 相关的 Widget 对应的 Element 才有与之对应的 RenderObject。上图中的Widget 是 继承自 StatelessWidget 的 FirstRoute,StatelessWidget 直接继承自 Widget,而不是 RenderObjectWidget ,所以不会转化为 RenderObject。将 FirstRoute 的 _child 展开如下图:
FirstRoute 的 child 是 Center,Center 间接继承 SingleChildRenderObjectWidget,SingleChildRenderObjectWidget 继承 RenderObjectWidget,所以 Center 最终会转化成 RenderObjectWidget 渲染到屏幕上。
再将 FirstRoute 的 _parent 展开如下图:
按照我们写的dart代码理解,FirstRoute 的 parent 应该是 MaterialApp,但观察上图我们发现其实是 Semantics,这其实也好理解,MaterialApp 里面封装了很多层 Widget 去做语义分析、手势处理、主题、动画等操作,经过一系列的准备工作之后才会到 MaterialApp。处于好奇,我想看看到底封装了多少层才到 MaterialApp,于是我就一层一层点开 _parent(说实话,点到一半我想放弃了,但我坚信我一定能把 MaterialApp 揪出来),如下图:
终于,皇天不负有心人!点开最后一个 StatefulElement 终于找到了 MaterialApp,如下图:
上面有讲到Widget 和 Element 树是一一对应的,但是与 RenderObject 不是一一对应的。我们具体来看一下他们之间的对应关系:
Widget | Element | RenderObject |
---|---|---|
StatelessWidget | StatelessElement | \ |
StatefulWidget | StatefulElement | \ |
ProxyWidget | ProxyElement | \ |
InheritedWidget | InheritedElement | \ |
SingleChildRenderObjectWidget | SingleChildRenderObjectElement | RenderObject |
MultiChildRenderObjectWidget | MultiChildRenderObjectElement | RenderObject |
RenderObjectWidget | RenderObjectElement | RenderObject |
2. 三棵树转化流程
Flutter 运行中的一部分核心逻辑就是在处理这三棵树的转化,所有的界面交互和事件处理,最终都反应在这对三棵树的操作结果上。Flutter项目的启动代码一般是
void main() => runApp(MyApp());
runApp代码如下:
void runApp(Widget app) {
WidgetsFlutterBinding.ensureInitialized()
..scheduleAttachRootWidget(app)
..scheduleWarmUpFrame();
}
三行代码代表了Flutter APP 启动的三个主流程:
- binding初始化(ensureInitialized)
- 创建根 widget,绑定根节点(scheduleAttachRootWidget)
- 绘制热身帧(scheduleWarmUpFrame)
这里我们主要看下涉及到三棵树之间的转化的主要函数的作用。
scheduleAttachRootWidget
创建根 widget ,并且从根 widget 向子节点递归创建元素Element,对子节点为 RenderObjectWidget 的小部件创建 RenderObject 树节点,从而创建出 View 的渲染树,源码中使用 Timer.run 事件任务的方式来运行,目的是避免影响到微任务的执行。
attachRootWidget
将传入的Widget绑定到一个根节点并构建三棵树。
先是通过传入的 rootWidget 及 RenderView 实例化了一个RenderObjectToWidgetAdapter对象,而RenderObjectToWidgetAdapter是继承自RenderObjectWidget,即创建了Widget树的根节点。
attachToRenderTree
attachToRenderTree 中通过 createElement() 创建了一个RenderObjectToWidgetElement 实例作为 element tree 的根节点,并绑定BuildOwner,通过 BuildOwner 构建需要构建的 element。这里会调用 BuildOwner 的 buildScope 方法,方法里面会调用传入的callback,也就是调用 element.mount(null, null);
,而 mount 方法会循环创建子节点,并在创建的过程中将需要更新的数据标记为 dirty。 mount 方法里面会调用 updateChild 方法。
buildScope
该方法源码太多,就不贴了,大概逻辑是先调用传进来的 callback 去循环创建子节点,并在创建的过程中将需要更新的数据标记为 dirty,然后循环 _dirtyElements 数组,如果 Element 有 child 则会递归判断子元素,并进行子元素的 build ,创建新的 Element 或者修改 Element 或者创建 RenderObject。如果是首次渲染,则 _dirtyElements 是空的列表,因此首次渲染在该方法中是没有任何执行流程的。该方法的核心还是在第二次渲染或者 setState 后,有标记 dirty 的 Element 时才会起作用。
updateChild
这个方法在 Flutter 的 Widget 系统中是非常重要的存在,每次在 Widget 树中新增、修改、删除一个子 Widget 都会调用这个方法去更新配置信息。所有子节点的处理都是经过该方法,在该方法中 Flutter 会处理 Element(newWidget.createElement()
Widget -> Element) 与 RenderObject(newChild.mount(this, newSlot)
Element -> RenderObject) 的转化逻辑,通过 Element 树的中间状态来减少对 RenderObject 树的影响,从而提升性能。该方法的三个输入参数:Element child、Widget newWidget、dynamic newSlot :
- child :当前节点的 Element 信息
- newWidget:Widget 树的新节点
- newSlot:新节点新位置
了解参数后,大概分析下方法的实现:
- 判断是否有新的 Widget 节点,如果没有,则将当前节点的 Element 直接销毁;
如果有,并且 Element 中也存在该节点,继续看下面逻辑
- 首先判断当前节点Element是否为空,为空则直接创建一个新的Element。不为空则继续判断当前节点 Element 中的旧 Widget 与新 Widget 是否一致,如果一致只是位置不同,则更新位置即可
updateSlotForChild(child, newSlot);
。其他情况下判断是否可更新当前节点Element 的 Widget,如果可以则更新child.update(newWidget);
,如果不可以则销毁当前的 Element 节点deactivateChild(child);
,并重新创建一个newChild = inflateWidget(newWidget, newSlot)
;。
在 child.update 函数逻辑里面,会根据当前节点的类型,调用不同的 update,具体如下四种:
- StatelessElement#update
- StatefulElement#update
- MultiChildRenderObjectElement#update
- SingleChildRenderObjectElement#update
上面四种类型的 update 方法都会递归调用会递归调用子节点,并循环返回到 updateChild 中。
有以下三个核心的函数会重新进入 updateChild 流程中,分别是 performRebuild、inflateWidget 和 markNeedsBuild,接下来我们看下这三个函数具体的作用:
- performRebuild
- inflateWidget
- markNeedsBuild
performRebuild
在 StatelessElement#update 和 StatefulElement#update 中会调用 rebuild 方法,进而调用 performRebuild 方法,tatelessWidget 和 StatefulWidget 的 build 方法都是在此执行,执行完成后将作为该节点的子节点,并进入 updateChild 递归函数中。
inflateWidget
根据传入的新的 widget 和位置创建一个新的 Element 节点作为当前 Element 节点的子节点,然后继续调用新的 Element 节点的 mount 方法去循环子节点,继续调用 updateChild 重新进入子节点更新流程。这里的 mount 方法根据 Element 节点类型不同有不同的实现,当为 RenderObjectElement 的时候还会去创建 RenderObject(Element -> RenderObject)。
markNeedsBuild
在 State#setState 方法里面调用;
把 Element 标记为 dirty 并调用 BuildOwner#scheduleBuildFor 将其加入到脏列表(BuildOwner#_dirtyElements)中,等待下一次 buildScope (在下一次WidgetsBinding.drawFrame 时被调用来更新 Widget 树)。buildScope 中会遍历 _dirtyElements 然后调用每个脏的 Element#rebuild 进而调用 performRebuild 进入 updateChild 流程。
3. 首次 build 流程
首次加载一个页面时,所有节点都不存在,此时的流程大部分情况下就是创建新的节点,方法调用流程如下图:
不管是首次加载还是再次加载,runApp 到 RenderObjectToWidgetElement#mount 逻辑都是一样的,在 _rebuild 中会调用 updateChild 更新Element节点,由于Element节点是不存在的,因此这时候就调用 inflateWidget 来创建 Element,然后调用 Element#mount,Element 实现类主要分为:ComponentElement 和 RenderObjectElement。
ComponentElement
ComponentElement 主要子类:StatelessElememt、StatefulElement、InheritedElement。
当 Element 为 ComponentElement 时,会调用 ComponentElement#mount ,在 ComponentElement#mount 中会创建 Element 并挂载到当前节点上,继续调用 _firstBuild 进行子组件的 build ,build 完成后则将 build 好的组件作为子组件,进入 updateChild 的子组件更新。
RenderObjectElement
RenderObjectElement的主要子类:SingleChildRenderObjectElement、MultiChildRenderObjectElement、RenderObjectToWidgetElement。
当 Element 为 RenderObjectElement 时,则会调用 RenderObjectElement#mount,在 RenderObjectElement#mount 中调用 createRenderObject 创建 RenderObject,并将该 RenderObject 挂载到当前节点的 RenderObject 树,最后同样会调用 updateChild 或者 inflateWidget 来递归创建 Element 子节点。
4. setState 流程
上面有提到过,在调用 State#setState 后,内部会调用 markNeedsBuild 把 Element 标记为 dirty 并调用 BuildOwner#scheduleBuildFor 将其加入到脏列表(BuildOwner#_dirtyElements)中,等待下一次 buildScope 。 buildScope 会调用 rebuild 然后进入 build 操作,从而进入 updateChild 的循环体系。整个流程图如下:
上面流程图中为了简化流程图省略了 updateChild 中的部分条件,这里说明一下:
- 走绿色流程线的条件:除了图中标明的当Element节点不存在以外,还有当 Element 节点存在,Widget 类型相同,不是同一个 Widget,并且 Widget 不可更新时,依然是创建新的 Element 节点。
- 走蓝色流程线的条件:当 Element 节点存在,Widget 类型相同,不是同一个 Widget,并且 Widget 可更新时,更新Element 节点中的 Widget 为新的 Widget。
由以上流程图可知:Flutter 中 setState 调用后会引起当前节点下的子节点递归 build,虽然不一定会造成 RenderObject 树的改变,但也会存在一些性能影响。
5. 优化
1. 针对调用 setState 会导致子 Widget rebuild 操作
- 尽量使用 const Widget
- 尽量减少 StatefulWidget 下的子 Widget ,也就是说 StatefulWidget 的粒度尽可能小
2. canUpdate 返回 false 导致创建新的 Elememt 节点
在 updateChild 的流程中会判断 Element节点的 Widget 是否可更新,这段判断的逻辑就在 Widget#canUpdate 里面,方法实现如下:
这里逻辑比较简单,主要判断新旧 Widget 的运行时类型和 key 是否都相同,都相同则可以直接更新 Elememt 节点里面的 oldWidget 为 newWidget,而不是直接创建新的 Elememt 节点,从而提升性能。优化空间如下:
- 尽量减少 Widget 的 key 的变化
- 如果需要频繁地对组件进行排序、删除或者新增处理时,最好要给 Widget 增加 key ,以提升性能
使用 key 时注意点:
由于 StatefulWidget 的 state 是保存在 Element 中,因此如果希望区分两个相同类名( runtimeType )的 Widget 时,必须携带不同的 key ,否则会无法区分新旧 Widget 的变化。特别是在一个列表数据,每个列表都是一个有状态类,如果需要切换列表中项目列表时,则必须设置 key,不然会导致顺序切换失效。
3. 使用 GlobalKey 复用 Element
在 updateChild 中的 inflateWidget 中会检查新传入的 Widget 的 key 是否为 GlobalKey ,如果是则表明 Element 存在,那么这时候直接复用,如果不存在则需要重新创建,这其实就是 Widget 缓存,可以减少组件的 build 成本,inflateWidget 代码如下:
使用 GlobalKey 会缓存 Widget,那么就会带来一个问题:内存损耗。所以尽量在复用性高且 build 业务复杂的 Widget 上使用 GlobalKey。