Element

在“Widget简介”一节，我们介绍了Widget和Element的关系，我们知道最终的UI树其实是由一个个独立的Element节点构成。我们也说过组件最终的Layout、渲染都是通过 RenderObject 来完成的，从创建到渲染的大体流程是：

  • 根据Widget生成Element
  • 然后创建相应的 RenderObject 并关联到 Element.renderObject 属性上
  • 最后再通过 RenderObject 来完成布局排列和绘制

    Element就是Widget在UI树具体位置的一个实例化对象，大多数Element只有唯一的renderObject，但还有一些Element会有多个子节点，如继承自RenderObjectElement的一些类，比如 MultiChildRenderObjectElement。最终所有Element的RenderObject构成一棵树，我们称之为”Render Tree“即”渲染树“。总结一下，我们可以认为Flutter的UI系统包含三棵树：Widget树、Element树、渲染树。他们的依赖关系是： Element树根据Widget树生成，而渲染树又依赖于Element树，如图所示:

Element与BuildContext - 图1

现在我们重点看一下Element，Element的生命周期如下

  1. Framework 调用 Widget.createElement 创建一个Element实例，记为 element
  2. Framework 调用 element.mount(parentElement,newSlot)
    • mount方法中首先调用 element 所对应Widget的 createRenderObject 方法创建与 element 相关联的RenderObject对象，
    • 然后调用 element.attachRenderObject 方法将element.renderObject添加到渲染树中插槽指定的位置（这一步不是必须的，一般发生在Element树结构发生变化时才需要重新attach）。插入到渲染树后的element就处于“active”状态，处于“active”状态后就可以显示在屏幕上了（可以隐藏）。
  3. 当有父Widget的配置数据改变时，同时其 State.build 返回的Widget结构与之前不同，此时就需要重新构建对应的Element树
    • 为了进行Element复用，在Element重新构建前会先尝试是否可以复用旧树上相同位置的 element，element 节点在更新前都会调用其对应Widget的canUpdate方法，如果返回true，则复用旧Element，旧的Element会使用新Widget配置数据更新，反之则会创建一个新的Element。Widget.canUpdate 主要是判断newWidget与oldWidget的runtimeType和key是否同时相等，如果同时相等就返回true，否则就会返回false。根据这个原理，当我们需要强制更新一个Widget时，可以通过指定不同的Key来避免复用。
  4. 当有祖先Element决定要移除element 时（如Widget树结构发生了变化，导致 element 对应的Widget被移除），这时该祖先Element就会调用 deactivateChild 方法来移除它，移除后element.renderObject也会被从渲染树中移除，然后Framework会调用 element.deactivate 方法，这时element状态变为“inactive”状态。
  5. “inactive”态的element将不会再显示到屏幕。为了避免在一次动画执行过程中反复创建、移除某个特定element，“inactive”态的 element 在当前动画最后一帧结束前都会保留，如果在动画执行结束后它还未能重新变成“active”状态，Framework就会调用其 unmount 方法将其彻底移除，这时 element 的状态为defunct,它将永远不会再被插入到树中。
  6. 如果 element 要重新插入到Element树的其它位置，如element或element的祖先拥有一个 GlobalKey（用于全局复用元素），那么Framework会先将 element 从现有位置移除，然后再调用其activate方法，并将其renderObject重新attach到渲染树。

    看完Element的生命周期，可能有些读者会有疑问，开发者会直接操作Element树吗？ 其实对于开发者来说，大多数情况下只需要关注Widget树就行，Flutter框架已经将对Widget树的操作映射到了Element树上，这可以极大的降低复杂度，提高开发效率。 但是了解Element对理解整个Flutter UI框架是至关重要的，Flutter正是通过Element这个纽带将Widget和RenderObject关联起来，了解Element层不仅会帮助读者对Flutter UI框架有个清晰的认识，而且也会提高自己的抽象能力和设计能力。另外在有些时候，我们必须得直接使用Element对象来完成一些操作，比如获取主题Theme数据，具体细节将在下文介绍。

BuildContext

我们已经知道，StatelessWidget 和 StatefulWidget 的 build 方法都会传一个 BuildContext 对象：

  1. Widget build(BuildContext context) {}

我们也知道，在很多时候我们都需要使用这个 context 做一些事，比如：

  1. Navigator.push(context, route)  //入栈新路由
  2. Theme.of(context)               //获取主题
  3. Localizations.of(context, type) //获取Local
  4. context.size                    //获取上下文大小
  5. context.findRenderObject()      //查找当前或最近的一个祖先RenderObject

那么 BuildContext 到底是什么呢，查看其定义，发现其是一个抽象接口类：

  1. abstract class BuildContext {
  2.   Widget get widget;
  3.   BuildOwner get owner;
  4.   RenderObject findRenderObject();
  5.   Size get size;
  7.   @Deprecated(
  8.     'Use dependOnInheritedElement instead. '
  9.     'This feature was deprecated after v1.12.1.'
  10.   )
  11.   InheritedWidget inheritFromElement(InheritedElement ancestor, { Object aspect });
  13.   InheritedWidget dependOnInheritedElement(InheritedElement ancestor, { Object aspect });
  15.   @Deprecated(
  16.     'Use dependOnInheritedWidgetOfExactType instead. '
  17.     'This feature was deprecated after v1.12.1.'
  18.   )
  19.   InheritedWidget inheritFromWidgetOfExactType(Type targetType, { Object aspect });
  21.   T dependOnInheritedWidgetOfExactType<T extends InheritedWidget>({ Object aspect });
  23.   @Deprecated(
  24.     'Use getElementForInheritedWidgetOfExactType instead. '
  25.     'This feature was deprecated after v1.12.1.'
  26.   )
  27.   InheritedElement ancestorInheritedElementForWidgetOfExactType(Type targetType);
  29.   InheritedElement getElementForInheritedWidgetOfExactType<T extends InheritedWidget>();
  31.   @Deprecated(
  32.     'Use findAncestorWidgetOfExactType instead. '
  33.     'This feature was deprecated after v1.12.1.'
  34.   )
  35.   Widget ancestorWidgetOfExactType(Type targetType);
  37.   T findAncestorWidgetOfExactType<T extends Widget>();
  39.   @Deprecated(
  40.     'Use findAncestorStateOfType instead. '
  41.     'This feature was deprecated after v1.12.1.'
  42.   )
  43.   State ancestorStateOfType(TypeMatcher matcher);
  45.   T findAncestorStateOfType<T extends State>();
  47.   @Deprecated(
  48.     'Use findRootAncestorStateOfType instead. '
  49.     'This feature was deprecated after v1.12.1.'
  50.   )
  51.   State rootAncestorStateOfType(TypeMatcher matcher);
  53.   T findRootAncestorStateOfType<T extends State>();
  55.   @Deprecated(
  56.     'Use findAncestorRenderObjectOfType instead. '
  57.     'This feature was deprecated after v1.12.1.'
  58.   )
  59.   RenderObject ancestorRenderObjectOfType(TypeMatcher matcher);
  61.   T findAncestorRenderObjectOfType<T extends RenderObject>();
  63.   void visitAncestorElements(bool visitor(Element element));
  65.   void visitChildElements(ElementVisitor visitor);
  67.   DiagnosticsNode describeElement(String name, {DiagnosticsTreeStyle style = DiagnosticsTreeStyle.errorProperty});
  69.   DiagnosticsNode describeWidget(String name, {DiagnosticsTreeStyle style = DiagnosticsTreeStyle.errorProperty});
  71.   List<DiagnosticsNode> describeMissingAncestor({ @required Type expectedAncestorType });
  73.   DiagnosticsNode describeOwnershipChain(String name);
  74. }

那这个 context 对象对应的实现类到底是谁呢？我们顺藤摸瓜，发现 build 调用是发生在

  • StatelessWidget 对应的 StatelessElement
  • StatefulWidget 对应的 StatefulElement

StatelessElement 中

  1. /// An [Element] that uses a [StatelessWidget] as its configuration.
  2. class StatelessElement extends ComponentElement {
  3.   /// Creates an element that uses the given widget as its configuration.
  4.   StatelessElement(StatelessWidget widget) : super(widget);
  6.   @override
  7.   StatelessWidget get widget => super.widget as StatelessWidget;
  9.   @override
  10.   Widget build() => widget.build(this);
  12.   @override
  13.   void update(StatelessWidget newWidget) {
  14.     super.update(newWidget);
  15.     assert(widget == newWidget);
  16.     _dirty = true;
  17.     rebuild();
  18.   }
  19. }

StatelessElement 中：

  1. /// An [Element] that uses a [StatefulWidget] as its configuration.
  2. class StatefulElement extends ComponentElement {
  3.   /// Creates an element that uses the given widget as its configuration.
  4.   StatefulElement(StatefulWidget widget)
  5.       : _state = widget.createState(),
  6.         super(widget) {
  7.     assert(() {
  8.       if (!state._debugTypesAreRight(widget)) {
  9.         throw FlutterError.fromParts(<DiagnosticsNode>[
  10.           ErrorSummary('StatefulWidget.createState must return a subtype of State<${widget.runtimeType}>'),
  11.           ErrorDescription(
  12.             'The createState function for ${widget.runtimeType} returned a state '
  13.             'of type ${state.runtimeType}, which is not a subtype of '
  14.             'State<${widget.runtimeType}>, violating the contract for createState.',
  15.           ),
  16.         ]);
  17.       }
  18.       return true;
  19.     }());
  20.     assert(state._element == null);
  21.     state._element = this;
  22.     assert(
  23.       state._widget == null,
  24.       'The createState function for $widget returned an old or invalid state '
  25.       'instance: ${state._widget}, which is not null, violating the contract '
  26.       'for createState.',
  27.     );
  28.     state._widget = widget;
  29.     assert(state._debugLifecycleState == _StateLifecycle.created);
  30.   }
  32.   @override
  33.   Widget build() => state.build(this);
  35.   /// The [State] instance associated with this location in the tree.
  36.   ///
  37.   /// There is a one-to-one relationship between [State] objects and the
  38.   /// [StatefulElement] objects that hold them. The [State] objects are created
  39.   /// by [StatefulElement] in [mount].
  40.   State<StatefulWidget> get state => _state!;
  41.   State<StatefulWidget>? _state;
  43.   @override
  44.   void reassemble() {
  45.     if (_debugShouldReassemble(_debugReassembleConfig, _widget)) {
  46.       state.reassemble();
  47.     }
  48.     super.reassemble();
  49.   }
  51.   @override
  52.   void _firstBuild() {
  53.     assert(state._debugLifecycleState == _StateLifecycle.created);
  54.     try {
  55.       _debugSetAllowIgnoredCallsToMarkNeedsBuild(true);
  56.       final Object? debugCheckForReturnedFuture = state.initState() as dynamic;
  57.       assert(() {
  58.         if (debugCheckForReturnedFuture is Future) {
  59.           throw FlutterError.fromParts(<DiagnosticsNode>[
  60.             ErrorSummary('${state.runtimeType}.initState() returned a Future.'),
  61.             ErrorDescription('State.initState() must be a void method without an `async` keyword.'),
  62.             ErrorHint(
  63.               'Rather than awaiting on asynchronous work directly inside of initState, '
  64.               'call a separate method to do this work without awaiting it.',
  65.             ),
  66.           ]);
  67.         }
  68.         return true;
  69.       }());
  70.     } finally {
  71.       _debugSetAllowIgnoredCallsToMarkNeedsBuild(false);
  72.     }
  73.     assert(() {
  74.       state._debugLifecycleState = _StateLifecycle.initialized;
  75.       return true;
  76.     }());
  77.     state.didChangeDependencies();
  78.     assert(() {
  79.       state._debugLifecycleState = _StateLifecycle.ready;
  80.       return true;
  81.     }());
  82.     super._firstBuild();
  83.   }
  85.   @override
  86.   void performRebuild() {
  87.     if (_didChangeDependencies) {
  88.       state.didChangeDependencies();
  89.       _didChangeDependencies = false;
  90.     }
  91.     super.performRebuild();
  92.   }
  94.   @override
  95.   void update(StatefulWidget newWidget) {
  96.     super.update(newWidget);
  97.     assert(widget == newWidget);
  98.     final StatefulWidget oldWidget = state._widget!;
  99.     // We mark ourselves as dirty before calling didUpdateWidget to
  100.     // let authors call setState from within didUpdateWidget without triggering
  101.     // asserts.
  102.     _dirty = true;
  103.     state._widget = widget as StatefulWidget;
  104.     try {
  105.       _debugSetAllowIgnoredCallsToMarkNeedsBuild(true);
  106.       final Object? debugCheckForReturnedFuture = state.didUpdateWidget(oldWidget) as dynamic;
  107.       assert(() {
  108.         if (debugCheckForReturnedFuture is Future) {
  109.           throw FlutterError.fromParts(<DiagnosticsNode>[
  110.             ErrorSummary('${state.runtimeType}.didUpdateWidget() returned a Future.'),
  111.             ErrorDescription( 'State.didUpdateWidget() must be a void method without an `async` keyword.'),
  112.             ErrorHint(
  113.               'Rather than awaiting on asynchronous work directly inside of didUpdateWidget, '
  114.               'call a separate method to do this work without awaiting it.',
  115.             ),
  116.           ]);
  117.         }
  118.         return true;
  119.       }());
  120.     } finally {
  121.       _debugSetAllowIgnoredCallsToMarkNeedsBuild(false);
  122.     }
  123.     rebuild();
  124.   }
  126.   @override
  127.   void activate() {
  128.     super.activate();
  129.     state.activate();
  130.     // Since the State could have observed the deactivate() and thus disposed of
  131.     // resources allocated in the build method, we have to rebuild the widget
  132.     // so that its State can reallocate its resources.
  133.     assert(_lifecycleState == _ElementLifecycle.active); // otherwise markNeedsBuild is a no-op
  134.     markNeedsBuild();
  135.   }
  137.   @override
  138.   void deactivate() {
  139.     state.deactivate();
  140.     super.deactivate();
  141.   }
  143.   @override
  144.   void unmount() {
  145.     super.unmount();
  146.     state.dispose();
  147.     assert(() {
  148.       if (state._debugLifecycleState == _StateLifecycle.defunct)
  149.         return true;
  150.       throw FlutterError.fromParts(<DiagnosticsNode>[
  151.         ErrorSummary('${state.runtimeType}.dispose failed to call super.dispose.'),
  152.         ErrorDescription(
  153.           'dispose() implementations must always call their superclass dispose() method, to ensure '
  154.          'that all the resources used by the widget are fully released.',
  155.         ),
  156.       ]);
  157.     }());
  158.     state._element = null;
  159.     // Release resources to reduce the severity of memory leaks caused by
  160.     // defunct, but accidentally retained Elements.
  161.     _state = null;
  162.   }
  164.   @override
  165.   InheritedWidget dependOnInheritedElement(Element ancestor, { Object? aspect }) {
  166.     assert(ancestor != null);
  167.     assert(() {
  168.       final Type targetType = ancestor.widget.runtimeType;
  169.       if (state._debugLifecycleState == _StateLifecycle.created) {
  170.         throw FlutterError.fromParts(<DiagnosticsNode>[
  171.           ErrorSummary('dependOnInheritedWidgetOfExactType<$targetType>() or dependOnInheritedElement() was called before ${state.runtimeType}.initState() completed.'),
  172.           ErrorDescription(
  173.             'When an inherited widget changes, for example if the value of Theme.of() changes, '
  174.             "its dependent widgets are rebuilt. If the dependent widget's reference to "
  175.             'the inherited widget is in a constructor or an initState() method, '
  176.             'then the rebuilt dependent widget will not reflect the changes in the '
  177.             'inherited widget.',
  178.           ),
  179.           ErrorHint(
  180.             'Typically references to inherited widgets should occur in widget build() methods. Alternatively, '
  181.             'initialization based on inherited widgets can be placed in the didChangeDependencies method, which '
  182.             'is called after initState and whenever the dependencies change thereafter.',
  183.           ),
  184.         ]);
  185.       }
  186.       if (state._debugLifecycleState == _StateLifecycle.defunct) {
  187.         throw FlutterError.fromParts(<DiagnosticsNode>[
  188.           ErrorSummary('dependOnInheritedWidgetOfExactType<$targetType>() or dependOnInheritedElement() was called after dispose(): $this'),
  189.           ErrorDescription(
  190.             'This error happens if you call dependOnInheritedWidgetOfExactType() on the '
  191.             'BuildContext for a widget that no longer appears in the widget tree '
  192.             '(e.g., whose parent widget no longer includes the widget in its '
  193.             'build). This error can occur when code calls '
  194.             'dependOnInheritedWidgetOfExactType() from a timer or an animation callback.',
  195.           ),
  196.           ErrorHint(
  197.             'The preferred solution is to cancel the timer or stop listening to the '
  198.             'animation in the dispose() callback. Another solution is to check the '
  199.             '"mounted" property of this object before calling '
  200.             'dependOnInheritedWidgetOfExactType() to ensure the object is still in the '
  201.             'tree.',
  202.           ),
  203.           ErrorHint(
  204.             'This error might indicate a memory leak if '
  205.             'dependOnInheritedWidgetOfExactType() is being called because another object '
  206.             'is retaining a reference to this State object after it has been '
  207.             'removed from the tree. To avoid memory leaks, consider breaking the '
  208.             'reference to this object during dispose().',
  209.           ),
  210.         ]);
  211.       }
  212.       return true;
  213.     }());
  214.     return super.dependOnInheritedElement(ancestor as InheritedElement, aspect: aspect);
  215.   }
  217.   /// This controls whether we should call [State.didChangeDependencies] from
  218.   /// the start of [build], to avoid calls when the [State] will not get built.
  219.   /// This can happen when the widget has dropped out of the tree, but depends
  220.   /// on an [InheritedWidget] that is still in the tree.
  221.   ///
  222.   /// It is set initially to false, since [_firstBuild] makes the initial call
  223.   /// on the [state]. When it is true, [build] will call
  224.   /// `state.didChangeDependencies` and then sets it to false. Subsequent calls
  225.   /// to [didChangeDependencies] set it to true.
  226.   bool _didChangeDependencies = false;
  228.   @override
  229.   void didChangeDependencies() {
  230.     super.didChangeDependencies();
  231.     _didChangeDependencies = true;
  232.   }
  234.   @override
  235.   DiagnosticsNode toDiagnosticsNode({ String? name, DiagnosticsTreeStyle? style }) {
  236.     return _ElementDiagnosticableTreeNode(
  237.       name: name,
  238.       value: this,
  239.       style: style,
  240.       stateful: true,
  241.     );
  242.   }
  244.   @override
  245.   void debugFillProperties(DiagnosticPropertiesBuilder properties) {
  246.     super.debugFillProperties(properties);
  247.     properties.add(DiagnosticsProperty<State<StatefulWidget>>('state', _state, defaultValue: null));
  248.   }
  249. }

通过上面我们发现build传递的参数是 this，很明显！

  • BuildContext 就是 StatelessElement。
  • StatefulWidget 的 context 是 StatefulElement。

但 StatelessElement 和 StatefulElement 本身并没有实现 BuildContext 接口，继续跟踪代码，发现它们间接继承自Element 类，然后查看 Element 类定义，发现 Element 类果然实现了BuildContext接口:

  1. class Element extends DiagnosticableTree implements BuildContext {
  2.     ...
  3. }

至此真相大白，BuildContext就是widget对应的Element
所以我们可以通过 context 在 StatelessWidget 和 StatefulWidget 的 build 方法中直接访问Element对象。我们获取主题数据的代码 Theme.of(context) 内部正是调用了Element的dependOnInheritedWidgetOfExactType()方法。

思考题：为什么build方法的参数不定义成Element对象，而要定义成BuildContext ?

进阶

我们可以看到 Element是Flutter UI框架内部连接widget和 RenderObject 的纽带
大多数时候开发者只需要关注widget层即可，但是widget层有时候并不能完全屏蔽 Element 细节，所以Framework在 StatelessWidget 和 StatefulWidget 中通过build方法参数又将 Element 对象也传递给了开发者，这样一来，开发者便可以在需要时直接操作 Element 对象。那么现在笔者提两个问题，请读者先自己思考一下：

  1. 如果没有widget层，单靠 Element 层是否可以搭建起一个可用的UI框架？如果可以应该是什么样子？
  2. Flutter UI框架能不做成响应式吗？

    对于问题1，答案当然是肯定的，因为我们之前说过widget树只是 Element 树的映射，我们完全可以直接通过Element 来搭建一个UI框架。下面举一个例子：

我们通过纯粹的Element来模拟一个 StatefulWidget 的功能，假设有一个页面，该页面有一个按钮，按钮的文本是一个9位数，点击一次按钮，则对9个数随机排一次序，代码如下：

  1. import 'package:flutter/material.dart';
  3. void main() => runApp(MyApp());
  5. class MyApp extends StatelessWidget {
  6.   @override
  7.   Widget build(BuildContext context) {
  8.     return MaterialApp(
  9.       title: 'Flutter Demo',
  10.       theme: ThemeData(
  11.         primarySwatch: Colors.blue,
  12.       ),
  13.       home:
  14.           Scaffold(appBar: AppBar(title: Text('自定义UI框架')), body: CustomHome()),
  15.     );
  16.   }
  17. }
  19. class CustomHome extends Widget {
  20.   // @override
  21.   // Element createElement() {
  22.   //   return CustomElement(this);
  23.   // }
  25.   @override
  26.   Element createElement() => CustomElement(this);
  27. }
  29. class CustomElement extends ComponentElement {
  30.   CustomElement(Widget widget) : super(widget);
  31.   String text = "123456789";
  33.   @override
  34.   Widget build() {
  35.     Color primary = Theme.of(this).primaryColor; //1
  36.     return GestureDetector(
  37.       child: Center(
  38.         child: FlatButton(
  39.           child: Text(
  40.             text,
  41.             style: TextStyle(color: primary),
  42.           ),
  43.           onPressed: () {
  44.             var t = text.split("")..shuffle();
  45.             text = t.join();
  46.             markNeedsBuild(); //点击后将该Element标记为dirty，Element将会rebuild
  47.           },
  48.         ),
  49.       ),
  50.     );
  51.   }
  52. }
  • 上面build方法不接收参数，这一点和在StatelessWidget和StatefulWidget中build(BuildContext)方法不同。代码中需要用到BuildContext的地方直接用 this 代替即可，如代码注释1处Theme.of(this)参数直接传this即可，因为当前对象本身就是Element实例。
  • 当text发生改变时，我们调用 markNeedsBuild() 方法将当前Element标记为dirty即可，标记为dirty的Element会在下一帧中重建。实际上，State.setState()在内部也是调用的markNeedsBuild()方法。
  • 上面代码中build方法返回的仍然是一个widget，这是由于Flutter框架中已经有了widget这一层，并且组件库都已经是以widget的形式提供了，如果在Flutter框架中所有组件都像示例的HomeView一样以Element形式提供，那么就可以用纯Element来构建UI了HomeView的build方法返回值类型就可以是Element了。
  • 如果我们需要将上面代码在现有Flutter框架中跑起来，那么还是得提供一个“适配器”widget将HomeView结合到现有框架中，下面CustomHome就相当于“适配器”：
    1. class CustomHome extends Widget {
    2. @override
    3. Element createElement() => HomeView(this)
    4. }

    现在就可以将 CustomHome 添加到widget树了，我们在一个新路由页创建它，最终效果如下如图所示：

Element与BuildContext - 图2 Element与BuildContext - 图3

对于问题2，答案当然也是肯定的，Flutter engine提供的dart API是原始且独立的，这个与操作系统提供的API类似，上层UI框架设计成什么样完全取决于设计者，完全可以将UI框架设计成Android风格或iOS风格，但这些事Google不会再去做，我们也没必要再去搞这一套，这是因为响应式的思想本身是很棒的，之所以提出这个问题，是因为笔者认为做与不做是一回事，但知道能不能做是另一回事，这能反映出我们对知识的理解程度。

总结

本节详细的介绍了 Element 的生命周期，以及它Widget、BuildContext的关系，也介绍了Element在Flutter UI系统中的角色和作用，我们将在下一节介绍Flutter UI系统中另一个重要的角色RenderObject。