几乎所有讲 Flutter 入门开发的文章和书籍，都会给你灌输 Flutter 三棵树的概念。然而在实际的业务开发中，我们绝大部分时间都只是在和 Widget 树打交道，使用 Widget 来构建用户界面，很少需要直接接触到另外两棵树。而随着对 Flutter 架构的逐渐深入，你必定会对这三棵树的工作机制产生一系列疑问，例如： 1. **Flutter框架为什么要将渲染机制剥离成三个树？这背后的设计理念是什么？** 2. **Widget树、Element树和Render树三者之间是如何建立关联与转换的？** 3. **Widget树的每一次变更都会导致Element树和Render树重建吗？** 4. **Widget树被销毁重建后，它是如何与原先的Element树重新建立关联的？** 5. **拥有多个子项的Widget是如何对比前后差异，实现UI的高效更新的？** 6. **我们应该如何正确构建Widget树，以确保Flutter应用保持快速、高效的渲染？** ... 理清这些问题不仅能帮助我们更好地理解 Flutter 的渲染机制，也直接关系到往后我们如何开发出高性能的 Flutter 应用。在这个系列文章中，我们将深入Flutter的核心，结合官方文档、源码分析以及动画演示，逐一地解答这些问题。准备好了吗？ ## Widget树：代码表示的 VS 最终生成的让我们从 Flutter 开发者最为熟悉的 build() 方法开始探讨。在这个方法中，我们通过多个 Widget 对象的嵌套组合，形成了一种层次结构关系，用以描述当前应用状态下 UI 的整体布局和外观。 @override Widget build(BuildContext context) { return Container( color: Colors.blue, child: Row( children: [ Image.network('https://www.example.com/1.png'), const Text('A'), ], ), ); } 在每个渲染帧的回调中，Flutter 框架都有可能会根据变化的状态，调用 build() 方法来重建部分 UI。需要注意的是，在这个过程中，**build() 方法可能会动态地引入新的 Widget，导致最终生成的 Widget 树结构比代码中所表示的层级更深**。如上述例子中，当 Container 的 color 属性不为空时，build() 方法就会为其自动引入一个 ColoredBox ，用以处理颜色渲染。 class Container extends StatelessWidget { @override Widget build(BuildContext context) { /// ... Widget? current = child; if (color != null) { current = ColoredBox(color: color!, child: current); } /// ... } } 类似地，Image 也会在构建过程中引入 RawImage， Text 则会引入 RichText。 ![](https://p6-xtjj-sign.byteimg.com/tos-cn-i-73owjymdk6/9bbf379ccabc4cfbb53ab2426606b9c4~tplv-73owjymdk6-jj-mark-v1:0:0:0:0:5o6Y6YeR5oqA5pyv56S-5Yy6IEAg5pif6ZmF56CB5LuU:q75.awebp?rk3s=f64ab15b&x-expires=1760503289&x-signature=MSRA740bE3SHXc8RbtIKmQkW96M%3D) 这种处理机制源于 Flutter 对 Widget 类的"浅而广"的设计原则，也即追求每个 Widget 尽可能小巧、功能单一，并通过最大限度地增加可能的组合数量，来为 Widget 提供更为丰富、强大的功能。 **组合性是 Flutter 最为出众的特性之一。一个 Widget 可以通过组合其他 Widget 的方式进行构建，而这些 Widget 自身也是由更基础的 Widget 组合而成。** 这就解释了为什么像边距（Padding）和对齐（Align）这样的基础功能被设计为单独的组件，而不是像传统 UI 框架那样作为每个组件的公共属性，在内部重新实现。要了解 Flutter 在实际构建过程中都引入了哪些新的 Widget，我们可以使用 Flutter Inspect 工具中的 Widget Tree Detail 面板中进行查看： ![](https://p6-xtjj-sign.byteimg.com/tos-cn-i-73owjymdk6/90bd6e158c13417c845388e4a4c0b344~tplv-73owjymdk6-jj-mark-v1:0:0:0:0:5o6Y6YeR5oqA5pyv56S-5Yy6IEAg5pif6ZmF56CB5LuU:q75.awebp?rk3s=f64ab15b&x-expires=1760503289&x-signature=EPr0Xt2zzIUmKPAa21X%2FrqbHWWc%3D) 这种"隐式" Widget 的引入，虽然简化了开发者的工作，但也潜在地改变了 Widget 树的层次结构，而这种结构上的变化，可能会对 Flutter 的渲染性能产生显著影响，我们将在后续章节中讨论这一点。 ## **Widget 本质：不可变的 UI 声明** 尽管 Flutter 对 Widget 的定义是：**Widgets 是构建 Flutter 应用界面的基础块。** 然而， Widget 并非真正的视图对象，也不会直接绘制任何内容。**每个 Widget 实际上都只是一部分不可变的 UI 声明。** 什么意思呢？我们都知道 **Flutter 采用的是声明式 UI，开发者只需要提供应用状态与 UI 之间的映射关系，而 Flutter 框架则负责在运行时将状态的更改更新到 UI 上**。而在这个过程中，我们所熟知的 build() 方法就是将状态转化为 UI 的关键。Widget 通过重写该方法来声明 UI 的配置，而 Flutter 框架则会根据配置优雅地创建和更新用户界面。 ![](https://p6-xtjj-sign.byteimg.com/tos-cn-i-73owjymdk6/5b0a489c8bc247318ed4ff6db05dad24~tplv-73owjymdk6-jj-mark-v1:0:0:0:0:5o6Y6YeR5oqA5pyv56S-5Yy6IEAg5pif6ZmF56CB5LuU:q75.awebp?rk3s=f64ab15b&x-expires=1760503289&x-signature=Klb0NsogLoqaZ35tlZT3r3eU9e0%3D) 这样的设计可以让开发者把重点放在对 UI 的声明上，而无需关注底层真正的视图对象的实现过程。实际上，与真正的视图对象相比，Widget 很轻量，并且有着更为短暂的生命周期—— **Widget及其与上下节点的关系都是不可变的，一旦需要变化，其生命周期就会终止。** 这一点从 Widget 类的定义上就可以看得出来： @immutable abstract class Widget extends DiagnosticableTree {} @immutable 注解指示 Widget 及其所有子类型都必须是不可变的，其本身也不包含可变状态，所有字段都必须是 final 的。这种不可变性就导致了，**对 Widget 树做的任何操作**（例如简单地将 `Text('A')` 替换成 `Text('B')`），**都只能通过返回一个全新的 Widget 对象集合来实现。** ## 将 Widget 树与 Element 树分离的必要性尽管 Widget 树每次更新时都会被销毁重建，但这并不意味着底层呈现的内容必须完全重构。因为当 Widget 构建完成后，它们会被保留在持有 UI 逻辑结构的 Element 树中。 abstract class Element extends DiagnosticableTree implements BuildContext { @override Widget get widget => _widget!; Widget? _widget; @mustCallSuper void update(covariant Widget newWidget) { _widget = newWidget; } } Element 树在每一帧之间都是持久化的，因此在性能优化上起着至关重要的作用，Flutter 利用这一特性，实现了一种巧妙的机制：表面上看 Widget 树被完全抛弃，实际上却缓存了其底层表示。 **Flutter 应用会根据事件交互，** **通知 Flutter 框架将层级中的旧 Widget 替换为新 Widget** **，然后只重建 Element 树中需要更新的部分，从而高效地更新用户界面。** ![](https://p6-xtjj-sign.byteimg.com/tos-cn-i-73owjymdk6/5b8a066c70c14081a5a134d345cd31da~tplv-73owjymdk6-jj-mark-v1:0:0:0:0:5o6Y6YeR5oqA5pyv56S-5Yy6IEAg5pif6ZmF56CB5LuU:q75.awebp?rk3s=f64ab15b&x-expires=1760503289&x-signature=FKEzuxPwfMP0Zxkhb6yZ83Yh1OI%3D) 重用 Element 能够极大程度地提升性能，不仅可以保留用户界面的状态信息，还能重用之前计算的布局信息，避免遍历整棵子树。这一点对性能提升尤为重要，因为布局计算通常比对象渲染更加耗时。特别对于 GridView 和 ListView 等复杂的 Widget，布局过程的性能开销尤其大，因此我们应尽可能避免重复的布局计算。 ## 从 Widget 树到 Element 树的转换过程 **Flutter 的核心就是一套高效的遍历树的变动的机制，它会将一棵对象树转换为更底层的对象树，并在树与树之间传递更改。** Widget 树和 Element 树是同构的，Widget 是 Element 的配置，而Element 是 Widget 的实例化，因此在 Widget 树中每一个指定位置上的 Widget，在 Element 树中都有一个对应的 Element，然而，它们在类型上并非一一对应的，Element 主要有两种基本类型： * **ComponentElement（组合 Element）** ：作为其他 Element 的宿主。 * **RenderObjectElement（渲染对象 Element）** ：实际参与布局或绘制的 Element。 ![](https://p6-xtjj-sign.byteimg.com/tos-cn-i-73owjymdk6/21cd45acb4914b9aacd910f154d37634~tplv-73owjymdk6-jj-mark-v1:0:0:0:0:5o6Y6YeR5oqA5pyv56S-5Yy6IEAg5pif6ZmF56CB5LuU:q75.awebp?rk3s=f64ab15b&x-expires=1760503289&x-signature=GkjHJ%2FK7inOP%2FJ7%2BFn44eJ8K87A%3D) 要了解不同 Widget 所对应的 Element 类型，我们可以通过其对抽象方法 createElement() 的重写来获知。 abstract class Widget extends DiagnosticableTree { @protected @factory Element createElement(); } 例如，通过对 Container 源码的追踪，可以获知其对应的 Element 类型是 ComponentElement： class Container extends StatelessWidget {} abstract class StatelessWidget extends Widget { @override StatelessElement createElement() => StatelessElement(this); } class StatelessElement extends ComponentElement {} createElement() 方法同时也是 Widget 树与 Element 树建立起关联的关键方法，该方法在 Element 的 inflateWidget() 方法中被调用： @protected Element inflateWidget(Widget newWidget, Object? newSlot) { try { /// ... /// 1.为给定的 Widget 创建一个 Element final Element newChild = newWidget.createElement(); /// 2.将其作为此 Element 的子 Element 添加到给定的插槽中 newChild.mount(this, newSlot); return newChild; } finally { /// ... } } 我们暂时不需要往上探寻 inflateWidget() 方法是由谁调用的，只需顺着源码的线索往下分析，答案自然而然会浮现出来。可以看到，新的 Element 对象被创建出来后，紧接着的下一步操作就是调用其自身的 mount() 方法。 mount 有“挂载”的意思，这一步是将自身挂载到父 Element 中由 Slot 参数指定的位置上，并确定了在 Element 树结构中的深度。 Slot 意为 “槽位”，某些父 Element（例如 MultiChildRenderObjectElement ）可能有多个子 Element，这个时候就需要 Slot 参数来定义其在子项列表中的挂载位置。 void mount(Element? parent, Object? newSlot) { /// ... /// 1.确立了自己的父 Element 节点 _parent = parent; _slot = newSlot; _lifecycleState = _ElementLifecycle.active; /// 2.确定了在 Element 树结构中的深度，在父 Element 的下一层 _depth = _parent != null ? _parent!.depth + 1 : 1; /// ... } ![](https://p6-xtjj-sign.byteimg.com/tos-cn-i-73owjymdk6/a5525f6aa47a49b3abdc7fd7148ac25c~tplv-73owjymdk6-jj-mark-v1:0:0:0:0:5o6Y6YeR5oqA5pyv56S-5Yy6IEAg5pif6ZmF56CB5LuU:q75.awebp?rk3s=f64ab15b&x-expires=1760503289&x-signature=ei%2Bhf%2FKE07c616X8SIt%2FwX%2FEcYk%3D) 接下来，在 ComponentElement 类自身对 mount() 方法的实现中，其依次调用多个方法，最终执行了 performRebuild() 。 @override void mount(Element? parent, Object? newSlot) { super.mount(parent, newSlot); _firstBuild(); } void _firstBuild() { rebuild(); } void rebuild({bool force = false}) { /// ... try { performRebuild(); } finally { /// ... } } performRebuild() 方法先是调用了 Container 的 build() 方法，返回了 Container 的 Widget 子树，并将其赋值给局部变量 built。随后，调用 updateChild 方法更新指定的子项： abstract class ComponentElement extends Element { @override void performRebuild() { Widget? built; try { /// 1. 获取新的对用户界面部分的描述（即UI配置） built = build(); } catch (e, stack) { built = ErrorWidget.builder( ... ); } finally { super.performRebuild(); } /// ... try { /// 2.使用新的UI配置更新指定的子项 _child = updateChild(_child, built, slot); } catch (e, stack) { built = ErrorWidget.builder( /// ... ); _child = updateChild(null, built, slot); } } } **updateChild 方法是 Widget 系统的核心。每次我们根据更新的配置添加、更新或删除子项时，都会调用它。** 根据 'newWidget' 参数和 'child' 参数是否为空，会有不同的处理。newWidget 已经在上一步的 build() 方法中构建出来了，而 child 也即 Element 子项由于待创建，因此暂时为空，所以我们走到了以下这一步的判断中： abstract class Element extends DiagnosticableTree implements BuildContext { @protected @pragma('vm:prefer-inline') Element? updateChild(Element? child, Widget? newWidget, Object? newSlot) { if (newWidget == null) { /// ... return null; } final Element newChild; if (child != null) { /// ... } else { newChild = inflateWidget(newWidget, newSlot); } } } 如上所示，我们又看到了 inflateWidget 方法，说明又开始了下一级的递归构建，接下来将通过调用 newWidget 的 createElement 方法创建子 Element，就这样逐级进行，最终完成了 Widget 树对 Element 树的转换。 ![](https://p6-xtjj-sign.byteimg.com/tos-cn-i-73owjymdk6/e5f7ffbe36ea40138a53464921ee33a2~tplv-73owjymdk6-jj-mark-v1:0:0:0:0:5o6Y6YeR5oqA5pyv56S-5Yy6IEAg5pif6ZmF56CB5LuU:q75.awebp?rk3s=f64ab15b&x-expires=1760503289&x-signature=SIcIGg9100v1RxjAKuPiwhvdt1E%3D) 整个转换过程的流程图如下： ![](https://p6-xtjj-sign.byteimg.com/tos-cn-i-73owjymdk6/09c737ead6a94b978c1c8ca688db5733~tplv-73owjymdk6-jj-mark-v1:0:0:0:0:5o6Y6YeR5oqA5pyv56S-5Yy6IEAg5pif6ZmF56CB5LuU:q75.awebp?rk3s=f64ab15b&x-expires=1760503289&x-signature=GvUl9M3RlBETd%2FQJyfP7JDraShc%3D) ## 将 Element 树与 Render 树分离的必要性同样是在构建阶段，Flutter 会为 Element 树中的每个 RenderObjectElement 类型的节点，创建或更新一个从 RenderObject 类继承的对象。 **RenderObject 类是渲染树中每个节点的** **基类，该基类为布局和绘制定义了一个抽象模型**，负责渲染文字的 RenderParagraph 和负责渲染图片的 RenderImage 则是更为上层的实现。 ![](https://p6-xtjj-sign.byteimg.com/tos-cn-i-73owjymdk6/7402ba7a2cc0403eb8d5cb32ebf6e2f3~tplv-73owjymdk6-jj-mark-v1:0:0:0:0:5o6Y6YeR5oqA5pyv56S-5Yy6IEAg5pif6ZmF56CB5LuU:q75.awebp?rk3s=f64ab15b&x-expires=1760503289&x-signature=eQaMf3VKSVJhZ7gQ5TRvkcjyeHQ%3D) 虽然我们都知道“在 Flutter 中，一切皆 Widget”，但我们在屏幕上所看到的实际是 RenderObject，除了布局和绘制外，RenderObject 还要处理额外的命中测试、可访问性等事务。 RenderObject 树是 Element 树的子集，因为只有 RenderObjectElement 声明了 createRenderObject 方法，所以 RenderObject 树的层级相较于 Element 树要浅得多。这也正是要将 Element 树与 Render 树进行分离的原因之一，**从性能方面考虑，当布局发生变化时，Flutter 只需遍历与布局相关的 RenderObject 树，而不需要遍历整个 Element 树**。由于前面我们提到的 Widget 组合性的存在，Element 树通常包含许多与实际布局无关的节点，遍历它们只会浪费时间。除了性能方面的考量，分离出 RenderObject 树后还可以充分利用其「类型安全」的特性，在运行时确保子节点拥有合适的类型。RenderObject 拥有多种实现类型，其中最常见的两种分别是： * RenderBox：为大多数的 Widget 所使用，其采用了基于二维笛卡尔坐标系的布局方式，其工作流程如下： 1. 1. 父节点向子节点传递约束条件（包括最小/最大宽高） 2. 子节点根据这些约束条件确定自身尺寸并返回 3. 最后由父节点确定子节点在坐标系中的精确位置 ![](https://p6-xtjj-sign.byteimg.com/tos-cn-i-73owjymdk6/ea523adaf6004b3bb9a9ac8ea277ff4f~tplv-73owjymdk6-jj-mark-v1:0:0:0:0:5o6Y6YeR5oqA5pyv56S-5Yy6IEAg5pif6ZmF56CB5LuU:q75.awebp?rk3s=f64ab15b&x-expires=1760503289&x-signature=OVaQEFsllHwDGMB3Nzccbn73S%2Bk%3D) * RenderSliver，主要用于可滚动的 Widget。它采用了基于滚动视窗的布局方式： * * 每个子节点都会接收到关于可视区域的信息（主要是剩余可见空间） * 每个子节点按顺序排列，直到所有子节点都被布局或可视区域空间耗尽 ![](https://p6-xtjj-sign.byteimg.com/tos-cn-i-73owjymdk6/182f75213a354128947ac09a4b004c6d~tplv-73owjymdk6-jj-mark-v1:0:0:0:0:5o6Y6YeR5oqA5pyv56S-5Yy6IEAg5pif6ZmF56CB5LuU:q75.awebp?rk3s=f64ab15b&x-expires=1760503289&x-signature=6hHVYuSoyxtZVX3FfjGNxl6aZKc%3D) Widget 并不关心它所处的布局类型，它可以被用在不同的布局中。举例来说： * 当 Text Widget 被用在 Row 中时，它会创建 RenderParagraph 类型的渲染对象，负责处理文本段落的渲染。 * 而当 Text Widget 被用在 ListView 中时，它会被包装在一个 RenderSliver 中，由后者真正负责滚动列表内容的渲染。 RenderObject 树的类型安全机制就体现在 Flutter 渲染过程中的安全校验和中间层转换。这确保了不同类型的 RenderObject 能够相互兼容，并最终构成一个完整的渲染树。这种机制有效防止了渲染过程中的类型错误，从而提升了渲染的稳定性和可靠性。如果将 Element 树与 Render 树合并成一棵树的话，需要遍历 Element 树才能确定每个 RenderObject 的类型。而将 RenderObject 树分离出来后，每个 RenderObject 的类型信息是预先确定的，不需要遍历就能直接获取，因此可以提高效率。 ## 从 Element 树到 RenderObject 树的转换过程前面我们提到过，RenderObjectElement 类型的 Element 才是实际参与布局或绘制的 Element，而负责创建此 Element 类型的 Widget 则是 RenderObjectWidget，RenderObjectWidget 提供了createRenderObject() 方法用于创建 RenderObject，创建的 RenderObject 将用于应用程序的实际渲染。这几个相关类之间的关系如下： ![](https://p6-xtjj-sign.byteimg.com/tos-cn-i-73owjymdk6/a3352f78b6034e3f8749c534a363efca~tplv-73owjymdk6-jj-mark-v1:0:0:0:0:5o6Y6YeR5oqA5pyv56S-5Yy6IEAg5pif6ZmF56CB5LuU:q75.awebp?rk3s=f64ab15b&x-expires=1760503289&x-signature=7EBaDP2lGmLm5k5ocJmSMGVsmdw%3D) createRenderObject() 方法同样是在 mount 方法内被调用： abstract class RenderObjectElement extends Element { @override void mount(Element? parent, Object? newSlot) { super.mount(parent, newSlot); /// ... /// 1. 使用 RenderObjectWidget 描述的 UI 配置创建 RenderObject 类的实例 _renderObject = (widget as RenderObjectWidget).createRenderObject(this); /// ... /// 2. 将 RenderObject 添加到渲染树中由 “newSlot” 指定的位置。 attachRenderObject(newSlot); super.performRebuild(); // clears the "dirty" flag } } 在创建了 RenderObject 类的实例后，下一步就是调用 attachRenderObject 方法，将 RenderObject 添加到渲染树中由“newSlot”指定的位置。 @override void attachRenderObject(Object? newSlot) { _slot = newSlot; /// 1.向上查找 Element 树，找到其祖先 RenderObjectElement _ancestorRenderObjectElement = _findAncestorRenderObjectElement(); /// ... /// 2.将创建好的子 RenderObject 插入到指定的祖先RenderObject中 _ancestorRenderObjectElement?.insertRenderObjectChild(renderObject, newSlot); /// ... } attachRenderObject 方法同样分为两步，第一步，向上查找 Element 树，找到其在树中距离最近的祖先RenderObjectElement： RenderObjectElement? _findAncestorRenderObjectElement() { Element? ancestor = _parent; /// 父 Element 不为空，但不是RenderObjectElement，继续向上查找 while (ancestor != null && ancestor is! RenderObjectElement) { ancestor = ancestor?._parent; } return ancestor as RenderObjectElement?; } 第二步，将创建好的子 RenderObject 插入到指定的祖先 RenderObject 中。 class SingleChildRenderObjectElement extends RenderObjectElement { @override void insertRenderObjectChild(RenderObject child, Object? slot) { final RenderObjectWithChildMixin renderObject = this.renderObject as RenderObjectWithChildMixin; /// 父对象仅拥有一个子项时，直接赋值给child renderObject.child = child; } } class MultiChildRenderObjectElement extends RenderObjectElement { @override void insertRenderObjectChild(RenderObject child, IndexedSlot slot) { final ContainerRenderObjectMixin> renderObject = this.renderObject; /// 父对象拥有多个子项时，插入到指定槽位的RenderObject之后 renderObject.insert(child, after: slot.value?.renderObject); } } 以渲染文字的 RenderParagraph 为例，其向上查找Element树，插入到指定的祖先RenderObject中的动画如下： ![](https://p6-xtjj-sign.byteimg.com/tos-cn-i-73owjymdk6/4a6137b838364b47b9c65d4182a0fc53~tplv-73owjymdk6-jj-mark-v1:0:0:0:0:5o6Y6YeR5oqA5pyv56S-5Yy6IEAg5pif6ZmF56CB5LuU:q75.awebp?rk3s=f64ab15b&x-expires=1760503289&x-signature=%2B1l%2FL5EWC1SeZ%2Bk1YHhBV%2FV6oI8%3D) 以上，就是今天这篇文章的所有内容，主要讲的是 Flutter 布局初始化的工作流程，下一篇我们将讲到 Flutter 是如何更新现有布局的，敬请期待。 ## 问题解答现在，让我们回顾一下文章开头提出的两个关键问题： 1. **Flutter框架为什么要将渲染机制剥离成三个树？这背后的设计理念是什么？** Flutter采用三棵树的设计，主要基于以下设计理念： * * **关注点分离：** * * * Widget 树——声明 UI 配置 * Element 树——管理 UI 结构 * RenderObject 树——实际 UI 渲染这种分离使得 Flutter 渲染机制的各个部分都能高效地完成其特定任务。 * * **性能优化：** * * * Element 树缓存了底层表示：只重建树中需要更新的部分，高效更新界面。 * RenderObject 树节点与布局相关：布局变化时，避免遍历与布局无关的节点。 * * **类型安全：** * * * RenderObject 树的安全校验和中间层转换：防止了渲染过程中的类型错误，提升了渲染的稳定性和可靠性。 2. **Widget树、Element树和Render树三者之间是如何建立关联与转换的？** 这三棵树的关联和转换过程如下： * * Widget 到 Element： * * * 创建 Element：调用 createElement() 方法为给定的 Widget 创建一个 Element 对象。 * 挂载 Element：通过 mount() 方法挂载到 Element树中，确立了其父节点，同时确定了其在 Element 树中的位置和深度。 * * Element 到 RenderObject： * * * 创建 RenderObject：对于RenderObjectElement，调用 createRenderObject() 方法来创建对应的RenderObject对象。 * 附加RenderObject：通过 attachRenderObject() 方法，向上查找 Element 树，找到RenderObjectElement 类型的父节点，然后将其插入到 RenderObject 树中。这个过程是递归进行的，从根 Widget 开始，逐级构建整个树结构，并将一棵对象树转换为更底层的另一棵对象树。