Flutter渲染之Widget、Element 和 RenderObject

一叶飘舟

已于 2023-04-04 17:23:22 修改

阅读量1.5k

点赞数 2

文章标签： flutter android

于 2023-04-04 12:10:48 首次发布

原文链接：https://juejin.cn/post/6845166891539906574

版权

用Flutter写界面写了一段时间了，感觉很爽，尤其是热加载功能，节省了大把时间，声明式的编程方式也是以后的趋势。现在基本熟练以后一些简单的效果能很快写出来，即使没见过的也可以在网上搜一下找到答案，但是感觉没有深入底层了解，有些问题还是一知半解，这些问题比如以下几个：

createState 方法在什么时候调用？state 里面为啥可以直接获取到 widget 对象？
build 方法是在什么时候调用的？
BuildContext 是什么？
Widget 频繁更改创建是否会影响性能？复用和更新机制是什么样的？
创建 Widget 里面的 Key 到底是什么作用？

后面抽时间看了一些关于 Flutter 渲染的文章，重点了解了 Widget、Element 和 RenderObject 方面的内容，终于有了一些了解，对上面几个问题也有了清晰的答案，因此通过这篇文章记录一下。

三棵树

首先先了解三棵树，这是我们的核心，需要首先建立一个概念。

Widget 树

我们平时用 Widget 使用声明式的形式写出来的界面，可以理解为 Widget 树，这是要介绍的第一棵树。

RenderObject 树

Flutter 引擎需要把我们写的 Widget 树的信息都渲染到界面上，这样人眼才能看到，跟渲染有关的当然有一颗渲染树 RenderObject tree，这是第二颗树，渲染树节点叫做 RenderObject，这个节点里面处理布局、绘制相关的事情。这两个树的节点并不是一一对应的关系，有些 Widget是要显示的，有些 Widget ，比如那些继承自 StatelessWidget & StatefulWidget 的 Widget 只是将其他 Widget 做一个组合，这些 Widget 本身并不需要显示，因此在 RenderObject 树上并没有相对应的节点。

Element 树

Widget 树是非常不稳定的，动不动就执行 build方法，一旦调用 build 方法意味着这个 Widget 依赖的所有其他 Widget 都会重新创建，如果 Flutter 直接解析 Widget树，将其转化为 RenderObject 树来直接进行渲染，那么将会是一个非常消耗性能的过程，那对应的肯定有一个东西来消化这些变化中的不便，来做cache。因此，这里就有另外一棵树 Element 树。Element 树这一层将 Widget 树的变化（类似 React 虚拟 DOM diff）做了抽象，可以只将真正需要修改的部分同步到真实的 RenderObject 树中，最大程度降低对真实渲染视图的修改，提高渲染效率，而不是销毁整个渲染视图树重建。

这三棵树如下图所示，是我们讨论的核心内容。

从上图可以看出，widget 树和 Element 树节点是一一对应关系，每一个 Widget 都会有其对应的 Element，但是 RenderObject 树则不然，只有需要渲染的 Widget 才会有对应的节点。Element 树相当于一个中间层，大管家，它对 Widget 和 RenderObject 都有引用。当 Widget 不断变化的时候，将新 Widget 拿到 Element 来进行对比，看一下和之前保留的 Widget 类型和 Key 是否相同，如果都一样，那完全没有必要重新创建 Element 和 RenderObject，只需要更新里面的一些属性即可，这样可以以最小的开销更新 RenderObject，引擎在解析 RenderObject 的时候，发现只有属性修改了，那么也可以以最小的开销来做渲染。

以上只是引出了非常重要的三棵树和他们之间的关系，简而言之，Widget 树就是配置信息的树，我们平时写代码写的就是这棵树，RenderObject 树是渲染树，负责计算布局，绘制，Flutter 引擎就是根据这棵树来进行渲染的，Element 树作为中间者，管理着将 Widget 生成 RenderObject和一些更新操作。

前面只是从概念角度粗略来介绍，下面我们从源码层面来看一看。

从源码来了解 Widget、Element 和 RenderObject

Widget

下面对 Widget 的概述截图来自官网

翻译一下就是，Widget 描述 Element 的配置信息，是 Flutter 框架里的核心类层次结构，一个 Widget 是用户界面某一部分的不可变描述。Widgets 可以转为 Elements，Elements 管理着底层的渲染树。

有这么多 Widget，我们来简单分各类吧，前面已经提到 Widget 有可渲染和不可渲染的分别了。可渲染里面分为多孩子和单孩子，也就是属性为 child 或 children，在不可渲染的 Widgets 里面又分为有状态和无状态，也就是 StatefullWidget 和 StatelessWidget。我们选择四个典型的Widgets来看看吧，如 Padding、RichText、Container、TextField。通过查阅源码，我们看到这几个类的继承关系如下图所示。

在根Widget类中有一个抽象方法createElement(),也就意味着所有的Widget子类必须实现此方法:

  @protected
  Element createElement();

Widget 是个抽象类，所有的 Widgets 都是它的子类，其抽象方法 createElement 需要子类实现，这里体现了之前我们说的 Widget 和 Element 的一一对应关系。来到 StatelessWidget、StatefulWidget、MultiChildRenderObjectWidget、SingleChildRenderObjectWidget 里面我们可以找到 createElement 的实现。

SingleChildRenderObjectWidget

@override
 SingleChildRenderObjectElement createElement() => SingleChildRenderObjectElement(this);

MultiChildRenderObjectWidget

@override
MultiChildRenderObjectElement createElement() => MultiChildRenderObjectElement(this);

StatefulWidget

@override
StatefulElement createElement() => StatefulElement(this);

StatelessWidget

@override
StatelessElement createElement() => StatelessElement(this);

可以发现规律，创建 Element 都会传入 this，也就是当前 Widget，然后返回对应的 Element，这些 Element 都是继承自 Element，Element 会有引用指向当前 Widget。

我们继续来到 RichText 和 Padding 类定义里面，他们都是继承自 RenderObjectWidget，可以看到他们都有 createRenderObject 方法，如下

Padding

  @override
  RenderPadding createRenderObject(BuildContext context) {
    return RenderPadding(
      padding: padding,
      textDirection: Directionality.of(context),
    );
  }

RichText

@override
  RenderParagraph createRenderObject(BuildContext context) {
    assert(textDirection != null || debugCheckHasDirectionality(context));
    return RenderParagraph(text,
      textAlign: textAlign,
      textDirection: textDirection ?? Directionality.of(context),
      softWrap: softWrap,
      overflow: overflow,
      textScaleFactor: textScaleFactor,
      maxLines: maxLines,
      strutStyle: strutStyle,
      textWidthBasis: textWidthBasis,
      locale: locale ?? Localizations.localeOf(context, nullOk: true),
    );
  }

RenderPadding 和 RenderParagraph 最终都是继承自 RenderObject。通过以上源码分析，我们可以看出来 Widget 里面有生成 Element 和 RenderObject 的方法，所以我们平时只需要埋头写好 Widget 就行，Flutter 框架会帮我们生成对应的 Element 和 RenderObject。但是在什么时候调用 createElement 和 createRenderObject呢，后面继续分析。

Element

以下对 Element 描述来自官网

直接翻译过来就是，Element 是树中特定位置 Widget 的一个实例化对象。这句话有两层意思：1. 表示 Widget 是一个配置，Element 才是最终的对象；2. Element 是通过遍历 Widget 树时，调用 Widget 的方法创建的。Element 承载了视图构建的上下文数据，是连接结构化的配置信息到完成最终渲染的桥梁。

上面从源码里面介绍 Widget 都会生成对应的 Element，这里我们也对 Element 简单做一个分类，和 Widget 相对应，如下图所示。

首先还是进入 Element 类里面看看，这是个抽象类，可以看到一些关键的方法和属性。

  /// Typically called by an override of [Widget.createElement].
  Element(Widget widget)
    : assert(widget != null),
      _widget = widget;

上面介绍Widget 里面 createElement 方法的时候可以看到会传入 this，这里从 Element 的构造方法中可以看到，this 最后传给了 Element 里面的 _widget。也就是说每个 Element 里面都会有一个 Widget 的引用(Element中会持有 widget)。_widget 在 Element 里面定义如下

  /// The configuration for this element.
  @override
  Widget get widget => _widget;
  Widget _widget;

从源码里面知道 Element 里面的 widget 是一个 get 方法，直接返回 _widget。从上面的注释信息也再一次提到 Widget 和 Element 的关系，Widget 是 Element 的配置。

对于 Element 的构造方法，StatelessfulElement 有一些特殊的地方，如下

class StatefulElement extends ComponentElement {
  /// Creates an element that uses the given widget as its configuration.
  StatefulElement(StatefulWidget widget)
      : _state = widget.createState(),
        super(widget) {
    ... 省略断言 ...
    assert(_state._element == null);
    _state._element = this;
     ... 省略断言 ...
    _state._widget = widget;
    assert(_state._debugLifecycleState == _StateLifecycle.created);
  }
  
  /// The [State] instance associated with this location in the tree.
  ///
  /// There is a one-to-one relationship between [State] objects and the
  /// [StatefulElement] objects that hold them. The [State] objects are created
  /// by [StatefulElement] in [mount].
  State<StatefulWidget> get state => _state;
  State<StatefulWidget> _state;
}

StatefulElement 的构造方法中还调用了对应 Widget 的 createState 方法，并赋值给 _state，这也解答了我们在文章开头提出的问题（createState 方法在什么时候调用？）。StatefulElement 里面不仅有对 Widget 的引用，也有对 StatefulWidget 的 State 的引用。并且在构造函数里面还将 widget 赋值给了 _state 里面的 _widget。所以我们在 State 里面可以直接使用 widget 就可以拿到 State 对应的 Widget。原来是在 StatefulElement 构造函数的时候赋值的。解释了开头提到的问题（state 里面为啥可以直接获取到 widget 对象？）。

Element 还有一个关键的方法 mount，如下

  @mustCallSuper
  void mount(Element? parent, Object? newSlot) {
    assert(_lifecycleState == _ElementLifecycle.initial);
    assert(widget != null);
    assert(_parent == null);
    assert(parent == null || parent._lifecycleState == _ElementLifecycle.active);
    assert(slot == null);
    _parent = parent;
    _slot = newSlot;
    _lifecycleState = _ElementLifecycle.active;
    _depth = _parent != null ? _parent!.depth + 1 : 1;
    if (parent != null) {
      // Only assign ownership if the parent is non-null. If parent is null
      // (the root node), the owner should have already been assigned.
      // See RootRenderObjectElement.assignOwner().
      _owner = parent.owner;
    }
    assert(owner != null);
    final Key? key = widget.key;
    if (key is GlobalKey) {
      owner!._registerGlobalKey(key, this);
    }
    _updateInheritance();
  }

Flutter 框架会根据 Widget 创建对应的 Element，Element 生成以后会调用 Element 的 mount 方法，将生成的 Element 挂载到 Element 树上。这里的 createElement 和 mount 都是 Flutter 框架自动调用的，不需要开发者手动调用。因此我们平时可能没关注这些过程。Element 里面的 mount 方法需要子类实现，我们来看看ComponentElement 里的 mount 方法。

  @override
  void mount(Element parent, dynamic newSlot) {
    super.mount(parent, newSlot);
    assert(_child == null);
    assert(_active);
    _firstBuild();
    assert(_child != null);
  }

这里一步一步看源码，发现执行链路如下： _firstBuild()【ComponentElement】 -> rebuild() 【Element】-> performRebuild()【ComponentElement】 -> build()【StatelessElement】 ,

看一看最后 StatelessElement build() 的源码

  @override
  StatelessWidget get widget => super.widget;

  @override
  Widget build() => widget.build(this);

StatefulElement 的 build() 的源码如下

  @override
  Widget build() => state.build(this);

可以看出ComponentElement 的 mount 最后执行的是 build 方法。不过 StatelessElement 和 StatefulElement 是有区别的，StatelessElement 执行的是 Widget 里的 build 方法，而 StatefulElement 里面执行的是 state 的 build 方法。因此，这里也解决了文章开始提到的一个问题（build 方法是在什么时候调用的？）。也知道了 StatefulWidget 和它的 State 是如何联系起来的。

创建 widget 时,Flutter 框架会自动调用 createElement() 生成对应的 Element,Element 生成后会自动调用 Element 的 mount() 方法将当前的 Element 挂载到 Element 数上.而在 mount() 方法内部会调用 StateLessWidget 的 build() 方法和 StateFulWidget 中 State 的 build() 方法.

另外，我们看到上面执行执行build 方法传递的参数 this，也就是当前 Element，而我们在写代码的时候 build 方法是这样的

  @override
  Widget build(BuildContext context) {
  }

因此我们知道了，这个 BuildContext 其实就是这个 Widget 所对应的 Element。看看 Element 的定义就更清楚了。这也解释了开始提到的问题（BuildContext 是什么？）。

abstract class Element extends DiagnosticableTree implements BuildContext {
}

再来看看 RenderObjectElement 里的 mount 方法

  @override
  void mount(Element parent, dynamic newSlot) {
    ... 省略断言 ...
    _renderObject = widget.createRenderObject(this);
    ... 省略断言 ...
    attachRenderObject(newSlot);
    _dirty = false;
  }

对比一下 ComponentElement 和 RenderObjectElement 里面的 mount 方法，前面介绍过，ComponentElement 是非渲染 Widget 对应的 Element，而 RenderObjectElement 是渲染 Widget 对应的 Element，前者的mount 方法主要是负责执行 build 方法，而后者的 mount 方法主要是调用 Widget 里面的 createRenderObject 方法生成 RenderObject，然后赋值给自己的 _renderObject。

因此可以总结，ComponentElement 的 mount 方法主要作用是执行 build，而 RenderObjectElement 的 mount 方法主要作用是生成 RenderObject。

Widget 类里面有一个很重要的静态方法，本来可以放到上面讲 Widget 的时候说，但是还是放到 Element 里面吧。就是这个

  /// Whether the `newWidget` can be used to update an [Element] that currently
  /// has the `oldWidget` as its configuration.
  ///
  /// An element that uses a given widget as its configuration can be updated to
  /// use another widget as its configuration if, and only if, the two widgets
  /// have [runtimeType] and [key] properties that are [operator==].
  ///
  /// If the widgets have no key (their key is null), then they are considered a
  /// match if they have the same type, even if their children are completely
  /// different.
  static bool canUpdate(Widget oldWidget, Widget newWidget) {
    return oldWidget.runtimeType == newWidget.runtimeType
        && oldWidget.key == newWidget.key;
  }

Element 里面有一个 _widget 作为其配置信息，当widget变化或重新生成以后，Element 要不要销毁重建呢，还是直接将新生成的 Widget 替换旧的 Widget。答案就是通过这个方法判断的，上面的注释可以翻译如下

判断新 Widget 是否可以用来取代 Element 当前的配置信息 _widget。 Element 使用特定的 widget 作为其配置信息，如果 runtimeType 和 key 和之前的 widget 相同，那么可以使用一个新的 widget 更新 Element 里面旧的 widget。如果这两个widget 都没有赋值 key，那么只要 runtimeType 相同也可以更新，即使这两个 widget 的孩子 widget 都完全不一样。

因此可以看出，即使外面的 widget 树经常变换重建，我们的 Element 可以维持相对稳定，不会重复创建，当然也就不会重复 mount，生成 RenderObject，只需要以最小代价更新相关属性即可，最大可能减小了性能消耗。Widget 本身只是一些配置信息，简单的对象，它的变更重建不直接影响渲染，对性能影响很小。这就解决了上文提到的另外一个问题（Widget 频繁更改创建是否会影响性能？复用和更新机制是什么样的？）。

RenderObject

从 RenderObject 的名字，我们就能很直观地知道，RendreObject 是主要负责实现视图渲染的对象。从上文中我们知道了一下几点

RenderObject 和 widget 并不是一一对应的，只有继承自 RenderObjectWidget 的 widget 才有对应的 RenderObject；
生成 RenderObject 的方法 createRenderObject 是在 Widget 里面定义的；
在 RenderObjectElement 执行 mount 方法的时候调用的 widget 里面的 createRenderObject 方法的；
RenderObjectElement 里面既有对 Widget 的引用也有对 RenderObject 的引用，它作为中间者，管理着双方。

RenderObject 在 Flutter 的展示分为四个阶段，即布局、绘制、合成和渲染。其中，布局和绘制在 RenderObject 中完成，Flutter 采用深度优先机制遍历渲染对象树，确定树中各个对象的位置和尺寸，并把它们绘制在不同的图层上。绘制完毕后，合成和渲染的工作则交给 Skia 搞定。

总结

上面通过源码讲解了一下 Widget、Element、RenderObject 的联系。下面简单来个总结。

我们写好 Widget 树后，Flutter 会在遍历 Widget 树时调用 Widget 里面的 createElement 方法去生成对应节点的 Element 对象，同时 Element 里面也有了对 Widget 的引用。特别的是当 StatefulElement 创建的时候也执行 StatefulWidget 里面的 createState 方法创建 state，并且赋值给 Element 里的 _state 属性，当前 widget 也同时赋值给了 state 里的_widget。Element 创建好以后 Flutter 框架会执行 mount 方法，对于非渲染的 ComponentElement 来说 mount 主要执行 widget 里的 build 方法，而对于渲染的 RenderObjectElement 来说 mount 里面会调用 widget 里面的 createRenderObject 方法生成 RenderObject，并赋值给 RenderObjectElement 里的相应属性。StatefulElement 执行 build 方法的时候是执行的 state 里面的 build 方法，并且将自身传入，也就是常见的 BuildContext。

如果 Widget 的配置数据发生了改变，那么持有该 Widget 的 Element 节点也会被标记为 dirty。在下一个周期的绘制时，Flutter 就会触发该 Element 树的更新，通过 canUpdate 方法来判断是否可以使用新的 Widget 来更新 Element 里面的配置，还是重新生成 Element。并使用最新的 Widget 数据更新自身以及关联的 RenderObject对象。布局和绘制完成后，接下来的事情交给 Skia 了。在 VSync 信号同步时直接从渲染树合成 Bitmap，然后提交给 GPU。

回答开头提出的问题

createState 方法在什么时候调用？state 里面为啥可以直接获取到 widget 对象？

答：Flutter 会在遍历 Widget 树时调用 Widget 里面的 createElement 方法去生成对应节点的 Element 对象，同时执行 StatefulWidget 里面的 createState 方法创建 state，并且赋值给 Element 里的 _state 属性，当前 widget 也同时赋值给了 state 里的_widget，state 里面有个 widget 的get 方法可以获取到 _widget 对象。

build 方法是在什么时候调用的？

答：Element 创建好以后 Flutter 框架会执行 mount 方法，对于非渲染的 ComponentElement 来说 mount 主要执行 widget 里的 build 方法，StatefulElement 执行 build 方法的时候是执行的 state 里面的 build 方法，并且将自身传入，也就是常见的 BuildContext

BuildContext 是什么？

答：StatefulElement 执行 build 方法的时候是执行的 state 里面的 build 方法，并且将自身传入，也就是常见的 BuildContext。简而言之 BuidContext 就是 Element。

Widget 频繁更改创建是否会影响性能？复用和更新机制是什么样的？

答：不会影响性能，widget 只是简单的配置信息，并不直接涉及布局渲染相关。Element 层通过判断新旧 widget 的runtimeType 和 key 是否相同决定是否可以直接更新之前的配置信息，也就是替换之前的 widget，而不必每次都重新创建新的 Element。

创建 Widget 里面的 Key 到底是什么作用？

答：Key 作为 Widget 的标志，在widget 变更的时候通过判断 Element 里面之前的 widget 的 runtimeType 和 key来决定是否能够直接更新。需要了解更多 Key 的作用可以阅读这边文章 Flutter渲染之通过demo了解Key的作用

对象的创建过程

我们这里以Padding为例，Padding用来设置内边距

Widget

我们常见的几种构建的Widget在渲染的层面主要分成两种

组件Widget：不会生成RenderObject

Containr
Text
HYHomePage

渲染Widget: 会生成RenderObject

Padding
Row

Padding是一个Widget，并且继承自SingleChildRenderObjectWidget

继承关系如下：

Padding -> SingleChildRenderObjectWidget -> RenderObjectWidget -> Widget

我们之前在创建Widget时，经常使用StatelessWidget和StatefulWidget，这种Widget只是将其他的Widget在build方法中组装起来，并不是一个真正可以渲染的Widget（在之前的课程中其实有提到）。

在Padding的类中，我们找不到任何和渲染相关的代码，这是因为Padding仅仅作为一个配置信息，这个配置信息会随着我们设置的属性不同，频繁的销毁和创建。

问题：频繁的销毁和创建会不会影响Flutter的性能呢？

并不会，答案在我的另一篇文章中；
https://mp.weixin.qq.com/s/J4XoXJHJSmn8VaMoz3BZJQ

那么真正的渲染相关的代码在哪里执行呢？

RenderObject

2.2. RenderObject

我们来看Padding里面的代码，有一个非常重要的方法：

这个方法其实是来自RenderObjectWidget的类，在这个类中它是一个抽象方法；
抽象方法是必须被子类实现的，但是它的子类SingleChildRenderObjectWidget也是一个抽象类，所以可以不实现父类的抽象方法
但是Padding不是一个抽象类，必须在这里实现对应的抽象方法，而它的实现就是下面的实现

@override
RenderPadding createRenderObject(BuildContext context) {
  return RenderPadding(
    padding: padding,
    textDirection: Directionality.of(context),
  );
}

上面的代码创建了什么呢？RenderPadding

RenderPadding的继承关系是什么呢？

RenderPadding -> RenderShiftedBox -> RenderBox -> RenderObject

我们来具体查看一下RenderPadding的源代码：

如果传入的_padding和原来保存的value一样，那么直接return；
如果不一致，调用_markNeedResolution，而_markNeedResolution内部调用了markNeedsLayout；
而markNeedsLayout的目的就是标记在下一帧绘制时，需要重新布局performLayout；
如果我们找的是Opacity，那么RenderOpacity是调用markNeedsPaint，RenderOpacity中是有一个paint方法的；

  set padding(EdgeInsetsGeometry value) {
    assert(value != null);
    assert(value.isNonNegative);
    if (_padding == value)
      return;
    _padding = value;
    _markNeedResolution();
  }

Element

我们来思考一个问题：

之前我们写的大量的Widget在树结构中存在引用关系，但是Widget会被不断的销毁和重建，那么意味着这棵树非常不稳定；
那么由谁来维系整个Flutter应用程序的树形结构的稳定呢？
答案就是Element。
官方的描述：Element是一个Widget的实例，在树中详细的位置。

Element什么时候创建？

在每一次创建Widget的时候，会创建一个对应的Element，然后将该元素插入树中。

Element保存着对Widget的引用；

在SingleChildRenderObjectWidget中，我们可以找到如下代码：

在Widget中，Element被创建，并且在创建时，将this（Widget）传入了；
Element就保存了对Widget的应用；

  @override
  SingleChildRenderObjectElement createElement() => SingleChildRenderObjectElement(this);

在创建完一个Element之后，Framework会调用mount方法来将Element插入到树中具体的位置：

mount方法

在调用mount方法时，会同时使用Widget来创建RenderObject，并且保持对RenderObject的引用：

_renderObject = widget.createRenderObject(this);

  @override
  void mount(Element parent, dynamic newSlot) {
    super.mount(parent, newSlot);
    _renderObject = widget.createRenderObject(this);
    assert(() {
      _debugUpdateRenderObjectOwner();
      return true;
    }());
    assert(_slot == newSlot);
    attachRenderObject(newSlot);
    _dirty = false;
  }

但是，如果你去看类似于Text这种组合类的Widget，它也会执行mount方法，但是mount方法中并没有调用createRenderObject这样的方法。

我们发现ComponentElement最主要的目的是挂载之后，调用_firstBuild方法

  @override
  void mount(Element parent, dynamic newSlot) {
    super.mount(parent, newSlot);
    assert(_child == null);
    assert(_active);
    _firstBuild();
    assert(_child != null);
  }
 
  void _firstBuild() {
    rebuild();
  }

如果是一个StatefulWidget，则创建出来的是一个StatefulElement

我们来看一下StatefulElement的构造器：

调用widget的createState()
所以StatefulElement对创建出来的State是有一个引用的
而_state又对widget有一个引用

  StatefulElement(StatefulWidget widget)
      : _state = widget.createState(),
  ....省略代码
  _state._widget = widget;

而调用build的时候，本质上调用的是_state中的build方法：

Widget build() => state.build(this);

build的context是什么

在StatelessElement中，我们发现是将this传入，所以本质上BuildContext就是当前的Element

Widget build() => widget.build(this);

我们来看一下继承关系图：

Element是实现了BuildContext类（隐式接口）

abstract class Element extends DiagnosticableTree implements BuildContext

在StatefulElement中，build方法也是类似，调用state的build方式时，传入的是this

Widget build() => state.build(this);

对象创建过程小结

Widget只是描述了配置信息：

其中包含createElement方法用于创建Element
也包含createRenderObject，但是不是自己在调用

Element是真正保存树结构的对象：

创建出来后会由framework调用mount方法；
在mount方法中会调用widget的createRenderObject对象；
并且Element对widget和RenderObject都有引用；

RenderObject是真正渲染的对象：

其中有markNeedsLayout performLayout markNeedsPaint paint等方法

小总结

widget创建出来后，flutter框架一定会根据widget创建一个element，每一个widget都有一个对应的element，接下来就会调用mount方法，mount经过一系列的调用方法最终会调用widget里面的build方法，这里还会传入一个build（BuildContext.context）,

如果element是一个renderelement，他最主要的事情是创建一个renderObject，elment里面有有个_renderObjec指向renderObject.

刚才创建elment时候，会创建一个_widget，是对widget的引用。

如果elment是一个StatefulElement，会创建一个_state._widget = widget.

BuildContext context = Element. 就是 context就是elment

建立Element树最重要的操作就是`Element.mount`。

每一种具体类型的Element，实现了如何将当前Element挂接(mount)到父节点上的操作；这个挂接操作除了与父Element建立指向关系外，还规定了当前Element的一些其它属性的创建时机和操作。

创建一个Element最重要的操作就是`Element.updateChild`。

更具体的是Element.inflateWidget方法；通过创建子Widget方式的不同，区分了两大类Element和Widget: (StatelessElement, StatelessWidget)和(StatefulElement, StatefulWidget)

所谓的Element树更像是前向单链表网，单链表有共同的表头。

父类Element不持有Element子节点，而是通过Element.visitChildren把遍历操作交给具体的Element子类型来实现。

但是RenderObject却像普通的单链表，因为通过mixin RenderObjectWithChildMixin<RenderObject>提供的child, RenderObject能够直接遍历子节点。

一叶飘舟

关注

2
点赞
踩
7

收藏

觉得还不错? 一键收藏
1
评论
Flutter渲染之Widget、Element 和 RenderObject

上面通过源码讲解了一下 Widget、Element、RenderObject 的联系。下面简单来个总结。我们写好 Widget 树后，Flutter 会在遍历 Widget 树时调用 Widget 里面的 createElement 方法去生成对应节点的 Element 对象，同时 Element 里面也有了对 Widget 的引用。
复制链接

扫一扫