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

image

该方法源码太多，就不贴了，大概逻辑是先调用传进来的 callback 去循环创建子节点，并在创建的过程中将需要更新的数据标记为 dirty，然后循环 _dirtyElements 数组，如果 Element 有 child 则会递归判断子元素，并进行子元素的 build ，创建新的 Element 或者修改 Element 或者创建 RenderObject。如果是首次渲染，则 _dirtyElements 是空的列表，因此首次渲染在该方法中是没有任何执行流程的。该方法的核心还是在第二次渲染或者 setState 后，有标记 dirty 的 Element 时才会起作用。

updateChild

image

这个方法在 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 流程

首次加载一个页面时，所有节点都不存在，此时的流程大部分情况下就是创建新的节点，方法调用流程如下图：

首次 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 的循环体系。整个流程图如下：

setState 流程

上面流程图中为了简化流程图省略了 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。

Flutter 渲染原理分析及优化