devbox
菜鸟追梦旅行
这个屌丝很懒，什么也没留下！
关注作者
热门标签
热门文章
当前位置:   article > 正文

透过源码理解Flutter中widget、state和element的关系_flutter widget源码

作者：菜鸟追梦旅行 | 2024-03-26 00:07:32

赞

踩

flutter widget源码

1、framework源码组成

Flutter中widget、state、element的源码位于framework.dart中，整个文件6693行(版本Flutter 3.12.0-14.0.pre.28)。整个代码可划分为若干部分，主要包括key、widget、state、element四部分。

1.1 key

关于key的代码65行到272行，这里的key包括ObjectKey、GlobalKey、LabeledGlobalKey、GlobalObjectKey。整个key体系的代码还包括key.dart这个文件，里面包括Key、LocalKey、UniqueKey和ValueKey。Key是GlobalKey和LocalKey的抽象基类。LabeledGlobalKey和GlobalObjectKey是GlobalKey的抽象子类。ObjectKey、UniqueKey和ValueKey是LocalKey的三个具体子类。

1.2 widget

关于widget的代码274行到1922行。包括10个抽象类：Widget、StatelessWidget、StatefulWidget、ProxyWidget、ParentDataWidget、InheritedWidget、RenderObjectWidget、LeafRenderObjectWidget、SingleChildRenderObjectWidget、MultiChildRenderObjectWidget。这些类，大体可以把Widget分为组合式、渲染、功能性三种。

1.3 state

State的代码在823附近。State是一个抽象类。State首先起着一个枢纽的作用，它持有widget，也持有element。从state里获取context，只是简单返回持有的element。另一方面，State对外提供了widget的生命周期：initState、didUpdateWidget、reassemble、deactivate、activate、dispose、didChangeDependencies。这些生命周期方法是系统提供给我们的钩子。如果我们要主动发起渲染请求的话，就要调用State提供给我们的setState方法。而build则是我们告诉系统如何渲染这个widget的地方。前者提供时机，后者提供内容。

1.4 BuildContext

BuildContext是一个抽象类，代码位于2129-2485行。Element实现了BuildContext。

1.5 BuildOwner

BuildOwner位于2511-3168行。

1.6 element

element相关的代码位于3259行到6597行之间。接近一半的代码量，可以看出element是核心部分。

2 StatelessWidget和StatefulWidget

Widget是一个抽象类，里面关键的三个东西：

  1. final Key? key;
  2.  
  3. Element createElement();
  4.  
  5. static bool canUpdate(Widget oldWidget, Widget newWidget) {
  6.     return oldWidget.runtimeType == newWidget.runtimeType
  7.         && oldWidget.key == newWidget.key;
  8.   }

我们要关注下canUpdate这个方法的实现，决定我们能否复用这个widget是由这个widget的runtimeType和key决定的。runtimeType表明了widget的类型，不同类型的widget是不能复用的。key是我们人为指定的一个值，它可以在同类型widget之间产生个体差异，以便我们或者渲染系统找到它。不设置的时候就是null，这时候只比较runtimeType就行。

我们先来介绍widget中的组合式子类：StatelessWidget和StatefulWidget。StatelessWidget创建的element是StatelessElement：

  1. @override
  2.   StatelessElement createElement() => StatelessElement(this);

而StatefulWidget创建的是StatefulElement，并且还能创建state：

  1. @override
  2.   StatefulElement createElement() => StatefulElement(this);
  3.  
  4. @protected
  5.   @factory
  6.   State createState();

StatelessWidget和StatefulWidget仍然是抽象类，需要我们子类化。根据源码，我们发现StatefulWidget和StatelessWidget只负责创建对应element，并不持有它。而Statefulwidget只负责创建state，同样也并不持有它。

3 RenderObjectWidget

RenderObjectWidget有三个抽象子类LeafRenderObjectWidget、SingleChildRenderObjectWidget、MultiChildRenderObjectWidget。分别代表了没有孩子、只有一个孩子和有多个孩子的三种RenderObjectWidget。源码我们不再展开，想必你也猜到了是一个啥都没，一个有个child，最后一个有个children属性罢了。

相比于前面的StatelessWidget，RenderObjectWidget返回自己独特的RenderObjectElement，并且还多了一个RenderObject：

  1. RenderObject createRenderObject(BuildContext context);
  2.  
  3.   
  4.   @protected
  5.   void updateRenderObject(BuildContext context, covariant RenderObject renderObject) { }
  6.  
  7.  
  8.   @protected
  9.   void didUnmountRenderObject(covariant RenderObject renderObject) { }

RenderObjectWidget我们后面在RenderObjectElement的performRebuild里讲到了，它会调用updateRenderObject进行更新。这里我们无法展开讲updateRenderObject，需要去看具体子类里的实现。 

3.1 ColoredBox

我们以SingleChildRenderObjectWidget的一个具体子类ColoredBox为例：

  1. final Color color;
  2.  
  3.   @override
  4.   RenderObject createRenderObject(BuildContext context) {
  5.     return _RenderColoredBox(color: color);
  6.   }
  7.  
  8. @override
  9.   void updateRenderObject(BuildContext context, RenderObject renderObject) {
  10.     (renderObject as _RenderColoredBox).color = color;
  11.   }

我们发现它创建的RenderObject是一个私有类_RenderColoredBox。而我们前面提到的updateRenderObject在这里只是设置一下新的颜色。

我们再转去看_RenderColoredBox的实现：

  1. class _RenderColoredBox extends RenderProxyBoxWithHitTestBehavior {
  2.   _RenderColoredBox({ required Color color })
  3.     : _color = color,
  4.       super(behavior: HitTestBehavior.opaque);
  5.  
  6.   /// The fill color for this render object.
  7.   ///
  8.   /// This parameter must not be null.
  9.   Color get color => _color;
  10.   Color _color;
  11.   set color(Color value) {
  12.     if (value == _color) {
  13.       return;
  14.     }
  15.     _color = value;
  16.     markNeedsPaint();
  17.   }
  18.  
  19.   @override
  20.   void paint(PaintingContext context, Offset offset) {
  21.     // It's tempting to want to optimize out this `drawRect()` call if the
  22.     // color is transparent (alpha==0), but doing so would be incorrect. See
  23.     // https://github.com/flutter/flutter/pull/72526#issuecomment-749185938 for
  24.     // a good description of why.
  25.     if (size > Size.zero) {
  26.       context.canvas.drawRect(offset & size, Paint()..color = color);
  27.     }
  28.     if (child != null) {
  29.       context.paintChild(child!, offset);
  30.     }
  31.   }
  32. }

主要是根据颜色在canvas上绘制背景色和child。设置新颜色会引起markNeedsPaint。markNeedsPaint相关代码在RenderObject里。

3.2 markNeedsPaint

  1. void markNeedsPaint() {
  2.    
  3.     if (_needsPaint) {
  4.       return;
  5.     }
  6.     _needsPaint = true;
  7.     // If this was not previously a repaint boundary it will not have
  8.     // a layer we can paint from.
  9.     if (isRepaintBoundary && _wasRepaintBoundary) {
  10.      
  11.       if (owner != null) {
  12.         owner!._nodesNeedingPaint.add(this);
  13.         owner!.requestVisualUpdate();
  14.       }
  15.     } else if (parent is RenderObject) {
  16.       parent!.markNeedsPaint();
  17.     } else {
  18.       
  19.       // If we are the root of the render tree and not a repaint boundary
  20.       // then we have to paint ourselves, since nobody else can paint us.
  21.       // We don't add ourselves to _nodesNeedingPaint in this case,
  22.       // because the root is always told to paint regardless.
  23.       //
  24.       // Trees rooted at a RenderView do not go through this
  25.       // code path because RenderViews are repaint boundaries.
  26.       if (owner != null) {
  27.         owner!.requestVisualUpdate();
  28.       }
  29.     }
  30.   }

这里出现了新的Owner：PipelineOwner。markNeedsPaint标记自己需要重新绘制，如果自己是绘制边界，就把自己加入需要绘制的节点列表里。如果不是绘制边界，就调用父节点的markNeedsPaint。这里只是简单标记和放入列表，真正执行绘制的时机是在WidgetsBinding.drawFrame里的flushPaint：

  1. void drawFrame() {
  2.   buildOwner!.buildScope(renderViewElement!); // 1.重新构建widget
  3.   super.drawFrame();
  4.   //下面几个是在super.drawFrame()执行的
  5.   pipelineOwner.flushLayout();          // 2.更新布局
  6.   pipelineOwner.flushCompositingBits();     //3.更新“层合成”信息
  7.   pipelineOwner.flushPaint();               // 4.重绘
  8.   if (sendFramesToEngine) {
  9.     renderView.compositeFrame();            // 5. 上屏，将绘制出的bit数据发送给GPU
  10.   }
  11. }

3.3 markNeedsLayout

上面的代码里，我们也看到了布局是在这之前的flushLayout执行的。RenderBox源码里PipelineOwner通过markNeedsLayout标记、收集需要布局节点：

  1. void markNeedsLayout() {
  2.  
  3.     if (_needsLayout) {
  4.  
  5.       return;
  6.     }
  7.     if (_relayoutBoundary == null) {
  8.       _needsLayout = true;
  9.       if (parent != null) {
  10.         // _relayoutBoundary is cleaned by an ancestor in RenderObject.layout.
  11.         // Conservatively mark everything dirty until it reaches the closest
  12.         // known relayout boundary.
  13.         markParentNeedsLayout();
  14.       }
  15.       return;
  16.     }
  17.     if (_relayoutBoundary != this) {
  18.       markParentNeedsLayout();
  19.     } else {
  20.       _needsLayout = true;
  21.       if (owner != null) {
  22.         owner!._nodesNeedingLayout.add(this);
  23.         owner!.requestVisualUpdate();
  24.       }
  25.     }
  26.   }
  27.  
  28. void markParentNeedsLayout() {
  29.     assert(_debugCanPerformMutations);
  30.     _needsLayout = true;
  31.     assert(this.parent != null);
  32.     final RenderObject parent = this.parent!;
  33.     if (!_doingThisLayoutWithCallback) {
  34.       parent.markNeedsLayout();
  35.     } else {
  36.       assert(parent._debugDoingThisLayout);
  37.     }
  38.     assert(parent == this.parent);
  39.   }

我们发现布局标记和绘制标记的实现是类似的，都需要标记自身，都需要向上寻找布局或者绘制的边界。PipelineOwner最终对其调用performLayout和markNeedsPaint：

  1. void flushLayout() {
  2.    
  3.     try {
  4.       while (_nodesNeedingLayout.isNotEmpty) {
  5.         final List<RenderObject> dirtyNodes = _nodesNeedingLayout;
  6.         _nodesNeedingLayout = <RenderObject>[];
  7.         dirtyNodes.sort((RenderObject a, RenderObject b) => a.depth - b.depth);
  8.         for (int i = 0; i < dirtyNodes.length; i++) {
  9.           if (_shouldMergeDirtyNodes) {
  10.             _shouldMergeDirtyNodes = false;
  11.             if (_nodesNeedingLayout.isNotEmpty) {
  12.               _nodesNeedingLayout.addAll(dirtyNodes.getRange(i, dirtyNodes.length));
  13.               break;
  14.             }
  15.           }
  16.           final RenderObject node = dirtyNodes[i];
  17.           if (node._needsLayout && node.owner == this) {
  18.             node._layoutWithoutResize();
  19.           }
  20.         }
  21.         // No need to merge dirty nodes generated from processing the last
  22.         // relayout boundary back.
  23.         _shouldMergeDirtyNodes = false;
  24.       }
  25.  
  26.       
  27.       for (final PipelineOwner child in _children) {
  28.         child.flushLayout();
  29.       }
  30.  
  31.  
  32.     } finally {
  33.       _shouldMergeDirtyNodes = false;
  34.       
  35.     }
  36.   }
  37.  
  38.  
  39.  
  40.   void _layoutWithoutResize() {
  41.  
  42.     RenderObject? debugPreviousActiveLayout;
  43.     try {
  44.       performLayout();
  45.       markNeedsSemanticsUpdate();
  46.     } catch (e, stack) {
  47.       _reportException('performLayout', e, stack);
  48.     }
  49.     _needsLayout = false;
  50.     markNeedsPaint();
  51.   }

performLayout这个方法在RenderBox里实现为空，需要子类自行实现。

前面ColoredBox这个例子里我们在updateRenderObject里改变颜色并不会引起布局变化。现在我们找一个RenderPositionedBox的源码来看看。

3.3 RenderPositionedBox

RenderPositionedBox是Align使用的renderObject。我们看看它的updateRenderObject实现：

  1. void updateRenderObject(BuildContext context, RenderPositionedBox renderObject) {
  2.     renderObject
  3.       ..alignment = alignment
  4.       ..widthFactor = widthFactor
  5.       ..heightFactor = heightFactor
  6.       ..textDirection = Directionality.maybeOf(context);
  7.   }

再进到RenderPositionedBox的set alignment实现：

  1. set alignment(AlignmentGeometry value) {
  2.     if (_alignment == value) {
  3.       return;
  4.     }
  5.     _alignment = value;
  6.     _markNeedResolution();
  7.   }
  8.  
  9. void _markNeedResolution() {
  10.     _resolvedAlignment = null;
  11.     markNeedsLayout();
  12.   }

我们发现设置新的alignment，会引起markNeedsLayout的调用。

4 三个功能性widget：ProxyWidget、ParentDataWidget、InheritedWidget

暂不展开，详见透过源码理解Flutter InheritedWidget_Mamong的博客-CSDN博客

5 StatefulElement和StatelessElement

我们再跳到StatelessElement构造方法：

  1.  
  2. class StatelessElement extends ComponentElement {
  3.   /// Creates an element that uses the given widget as its configuration.
  4.   StatelessElement(StatelessWidget super.widget);
  5.  
  6.   @override
  7.   Widget build() => (widget as StatelessWidget).build(this);
  8. }

StatelessElement自身可以通过build返回子element对应的widget。

而StatefulElement构造方法：

  1.  /// Creates an element that uses the given widget as its configuration.
  2.   StatefulElement(StatefulWidget widget)
  3.       : _state = widget.createState(),
  4.         super(widget) {
  5.     state._element = this;
  6.     state._widget = widget;
  7.   }

我们发现在创建element的时候，会先调用widget的createState创建state，并指向它，然后state就伸出两只手，一只手拉着widget，另一只手拉着element。element里面有一个重要的方法：

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

这里我们可以认为state build出来的是element持有的widget的“child”。事实上，无论StatelessElement还是Statefulwidget，它们都没child这个概念，但是对应的element是有一个child的属性的。所以我们姑且这么看待它们的关系。这里把element传进去，只是因为我们可能需要用到element树一些上下文信息。

3.1 setState

现在看看我们的老朋友，state里的setState方法的实现：

  1.   void setState(VoidCallback fn) {
  2.     _element!.markNeedsBuild();
  3.   }
  4.  
  5.  
  6.  void markNeedsBuild() {
  7.     if (dirty) {
  8.       return;
  9.     }
  10.     _dirty = true;
  11.     owner!.scheduleBuildFor(this);
  12.   }
  13.  
  14.   void scheduleBuildFor(Element element) {
  15.     _dirtyElements.add(element);
  16.     element._inDirtyList = true;
  17.   }
  18.  
  19. void rebuild() {
  20.     performRebuild();
  21.   }
  22.  
  23. void performRebuild() {
  24.     _dirty = false;
  25.   }

完整的流程如下：

中间省略一些代码，我们直接跳到performRebuild实现。对于基类Element的实现，只是简单标记为dirty。Element分为渲染和组件两种类型，前者与渲染相关，后者用于组成其他element。

3.2 performRebuild

对于跟渲染相关的RenderObjectElement的performRebuild，则需要更新它的renderObject：

  1. void _performRebuild() {
  2.     (widget as RenderObjectWidget).updateRenderObject(this, renderObject);
  3.     super.performRebuild(); // clears the "dirty" flag
  4.   }

对于跟组件相关的ComponentElement的performRebuild实现：

  1.   void performRebuild() {
  2.     Widget? built;
  3.     try {
  4.       built = build();
  5.     } catch (e, stack) {
  6.       
  7.     } finally {
  8.       // We delay marking the element as clean until after calling build() so
  9.       // that attempts to markNeedsBuild() during build() will be ignored.
  10.       super.performRebuild(); // clears the "dirty" flag
  11.     }
  12.     try {
  13.       _child = updateChild(_child, built, slot);
  14.     } catch (e, stack) {
  15.       _child = updateChild(null, built, slot);
  16.     }
  17.   }

这里的核心是会调用build方法创建新的widget，然后使用这个widget去更新child element。从前面的代码中我们可以看到statefulElement和statelessElement的build实现是有差异的。但是返回的widget，其实都是它们的child对应的widget。在多个渲染周期，child element会一直存在，而需要更新时widget就会重新创建。更新后的Element设置为当前Element的child。至于怎么更新，我们等下再讲。

ComponentElement是ProxyElement、StatefulElement和StatelessElement的父类。但是只有StatefulElement覆写了performRebuild。进一步来到StatefulElement的performRebuild实现：

  1. void performRebuild() {
  2.     if (_didChangeDependencies) {
  3.       state.didChangeDependencies();
  4.       _didChangeDependencies = false;
  5.     }
  6.     super.performRebuild();
  7.   }

StatefulElement增加的任务是如果依赖发生了变化，要触发state的didChangeDependencies方法。

3.3 updateChild

回到前文，我们再来看Element的updateChild实现：

  1. Element? updateChild(Element? child, Widget? newWidget, Object? newSlot) {
  2.     // 如果'newWidget'为null，而'child'不为null，那么我们删除'child'，返回null。
  3.     if (newWidget == null) {
  4.       if (child != null) {
  5.         deactivateChild(child);
  6.       }
  7.       return null;
  8.     }
  9.  
  10.     final Element newChild;
  11.     if (child != null) {
  12.       // 两个widget相同，位置不同更新位置。先更新位置，然后返回child。这里比较的是hashCode
  13.       if (child.widget == newWidget) {
  14.         if (child.slot != newSlot) {
  15.           updateSlotForChild(child, newSlot);
  16.         }
  17.         newChild = child;
  18.       } else if (Widget.canUpdate(child.widget, newWidget)) {
  19.         //两个widget不同，但是可以复用。位置不同则先更新位置。然后用新widget更新element
  20.         if (child.slot != newSlot) {
  21.           updateSlotForChild(child, newSlot);
  22.         }
  23.         child.update(newWidget);
  24.         newChild = child;
  25.       } else {
  26.         // 如果无法更新复用，那么删除原来的child，然后创建一个新的Element并返回。
  27.         deactivateChild(child);
  28.         newChild = inflateWidget(newWidget, newSlot);
  29.       }
  30.     } else {
  31.       // 如果是初次创建，那么创建一个新的Element并返回。
  32.       newChild = inflateWidget(newWidget, newSlot);
  33.     }
  34.  
  35.     return newChild;
  36.   }

这里关键的两个方法是update和inflateWidget。

3.4 update

对于不同类型的child的update方法是不一样的。基类Element只是用新的替换旧的而已:

  1. void update(covariant Widget newWidget) {
  2.     _widget = newWidget;
  3.   }

对于StatelessElement的update，就是直接更换widget：

  1.  @override
  2.   void update(StatelessWidget newWidget) {
  3.     //直接更换widget
  4.     super.update(newWidget);
  5.     assert(widget == newWidget);
  6.     rebuild(force: true);
  7.   }

对于StatefulElement的update，除了更换widget，还要更换state指向的widget：

  1. void update(StatefulWidget newWidget) {
  2.     super.update(newWidget);
  3.  
  4.     final StatefulWidget oldWidget = state._widget!;
  5.     state._widget = widget as StatefulWidget;
  6.     final Object? debugCheckForReturnedFuture = state.didUpdateWidget(oldWidget) as dynamic;
  7.     rebuild(force: true);
  8.   }

最后都通过调用rebuild，标记自身dirty。

对于SingleChildRenderObjectElement就是对它的child调用updateChild，对于MultiChildRenderObjectElement就是对它的children调用updateChildren：

  1. void update(SingleChildRenderObjectWidget newWidget) {
  2.     super.update(newWidget);
  3.     _child = updateChild(_child, (widget as SingleChildRenderObjectWidget).child, null);
  4.   }
  5.  
  6. void update(MultiChildRenderObjectWidget newWidget) {
  7.     super.update(newWidget);
  8.     final MultiChildRenderObjectWidget multiChildRenderObjectWidget = widget as MultiChildRenderObjectWidget;
  9.     _children = updateChildren(_children, multiChildRenderObjectWidget.children, forgottenChildren: _forgottenChildren);
  10.     _forgottenChildren.clear();
  11.   }

而对于ProxyElement主要是更新widget和通知：

  1. @override
  2.   void update(ProxyWidget newWidget) {
  3.     final ProxyWidget oldWidget = widget as ProxyWidget;
  4.     //使用新的widget更新持有的widget
  5.     super.update(newWidget);
  6.     //通知其他关联widget自己发生了变化
  7.     updated(oldWidget);
  8.     //标记dirty
  9.     rebuild(force: true);
  10.   }
  11.  
  12.   @protected
  13.   void updated(covariant ProxyWidget oldWidget) {
  14.     notifyClients(oldWidget);
  15.   }

3.5 updateChildren

updateChild前面我们已经提到了，而对于updateChildren的实现：

  1. List<Element> updateChildren(List<Element> oldChildren, List<Widget> newWidgets, { Set<Element>? forgottenChildren, List<Object?>? slots }) {
  2.  
  3.     Element? replaceWithNullIfForgotten(Element child) {
  4.       return forgottenChildren != null && forgottenChildren.contains(child) ? null : child;
  5.     }
  6.  
  7.     Object? slotFor(int newChildIndex, Element? previousChild) {
  8.       return slots != null
  9.           ? slots[newChildIndex]
  10.           : IndexedSlot<Element?>(newChildIndex, previousChild);
  11.     }
  12.  
  13.     // This attempts to diff the new child list (newWidgets) with
  14.     // the old child list (oldChildren), and produce a new list of elements to
  15.     // be the new list of child elements of this element. The called of this
  16.     // method is expected to update this render object accordingly.
  17.  
  18.     // The cases it tries to optimize for are:
  19.     //  - the old list is empty
  20.     //  - the lists are identical
  21.     //  - there is an insertion or removal of one or more widgets in
  22.     //    only one place in the list
  23.     // If a widget with a key is in both lists, it will be synced.
  24.     // Widgets without keys might be synced but there is no guarantee.
  25.  
  26.     // The general approach is to sync the entire new list backwards, as follows:
  27.     // 1. Walk the lists from the top, syncing nodes, until you no longer have
  28.     //    matching nodes.
  29.     // 2. Walk the lists from the bottom, without syncing nodes, until you no
  30.     //    longer have matching nodes. We'll sync these nodes at the end. We
  31.     //    don't sync them now because we want to sync all the nodes in order
  32.     //    from beginning to end.
  33.     // At this point we narrowed the old and new lists to the point
  34.     // where the nodes no longer match.
  35.     // 3. Walk the narrowed part of the old list to get the list of
  36.     //    keys and sync null with non-keyed items.
  37.     // 4. Walk the narrowed part of the new list forwards:
  38.     //     * Sync non-keyed items with null
  39.     //     * Sync keyed items with the source if it exists, else with null.
  40.     // 5. Walk the bottom of the list again, syncing the nodes.
  41.     // 6. Sync null with any items in the list of keys that are still
  42.     //    mounted.
  43.  
  44.     int newChildrenTop = 0;
  45.     int oldChildrenTop = 0;
  46.     int newChildrenBottom = newWidgets.length - 1;
  47.     int oldChildrenBottom = oldChildren.length - 1;
  48.  
  49.     final List<Element> newChildren = List<Element>.filled(newWidgets.length, _NullElement.instance);
  50.  
  51.     Element? previousChild;
  52.  
  53.    // 从前往后依次对比，相同的更新Element，记录位置，直到不相等时跳出循环。.
  54.     while ((oldChildrenTop <= oldChildrenBottom) && (newChildrenTop <= newChildrenBottom)) {
  55.       final Element? oldChild = replaceWithNullIfForgotten(oldChildren[oldChildrenTop]);
  56.       final Widget newWidget = newWidgets[newChildrenTop];
  57.  
  58.       // 注意这里的canUpdate，本例中在没有添加key时返回true。
  59.       // 因此直接执行updateChild，本循环结束返回newChildren。后面因条件不满足都在不执行。
  60.       // 一旦添加key，这里返回false，不同之处就此开始。
  61.       if (oldChild == null || !Widget.canUpdate(oldChild.widget, newWidget)) {
  62.         break;
  63.       }
  64.       final Element newChild = updateChild(oldChild, newWidget, slotFor(newChildrenTop, previousChild))!;
  65.  
  66.       newChildren[newChildrenTop] = newChild;
  67.       previousChild = newChild;
  68.       newChildrenTop += 1;
  69.       oldChildrenTop += 1;
  70.     }
  71.  
  72.     // 从后往前依次对比，记录位置，直到不相等时跳出循环。
  73.     while ((oldChildrenTop <= oldChildrenBottom) && (newChildrenTop <= newChildrenBottom)) {
  74.       final Element? oldChild = replaceWithNullIfForgotten(oldChildren[oldChildrenBottom]);
  75.       final Widget newWidget = newWidgets[newChildrenBottom];
  76.  
  77.  
  78.       if (oldChild == null || !Widget.canUpdate(oldChild.widget, newWidget)) {
  79.         break;
  80.       }
  81.       oldChildrenBottom -= 1;
  82.       newChildrenBottom -= 1;
  83.     }
  84.  
  85.     // 至此，就可以得到新旧List中不同Weiget的范围。
  86.     final bool haveOldChildren = oldChildrenTop <= oldChildrenBottom;
  87.     Map<Key, Element>? oldKeyedChildren;
  88. // 如果存在中间范围，扫描旧children，获取所有的key与Element保存至oldKeyedChildren。
  89.     if (haveOldChildren) {
  90.       oldKeyedChildren = <Key, Element>{};
  91.       while (oldChildrenTop <= oldChildrenBottom) {
  92.         final Element? oldChild = replaceWithNullIfForgotten(oldChildren[oldChildrenTop]);
  93.  
  94.  
  95.         if (oldChild != null) {
  96.           if (oldChild.widget.key != null) {
  97.             oldKeyedChildren[oldChild.widget.key!] = oldChild;
  98.           } else {
  99.             deactivateChild(oldChild);
  100.           }
  101.         }
  102.         oldChildrenTop += 1;
  103.       }
  104.     }
  105.  
  106.     // 更新中间不同的部分，如果新旧key相同就更新一下重新利用，否则新的widget就没有旧的对应，是插入行为
  107.     while (newChildrenTop <= newChildrenBottom) {
  108.       Element? oldChild;
  109.       final Widget newWidget = newWidgets[newChildrenTop];
  110.       if (haveOldChildren) {
  111.         final Key? key = newWidget.key;
  112.         if (key != null) {
  113.           // key不为null，通过key获取对应的旧Element
  114.           oldChild = oldKeyedChildren![key];
  115.           if (oldChild != null) {
  116.             if (Widget.canUpdate(oldChild.widget, newWidget)) {
  117.               // we found a match!
  118.               // remove it from oldKeyedChildren so we don't unsync it later
  119.               oldKeyedChildren.remove(key);
  120.             } else {
  121.               // Not a match, let's pretend we didn't see it for now.
  122.               oldChild = null;
  123.             }
  124.           }
  125.         }
  126.       }
  127.  
  128.       final Element newChild = updateChild(oldChild, newWidget, slotFor(newChildrenTop, previousChild))!;
  129.       
  130.       newChildren[newChildrenTop] = newChild;
  131.       previousChild = newChild;
  132.       newChildrenTop += 1;
  133.     }
  134.  
  135.     // We've scanned the whole list.
  136.     // 重置
  137.  
  138.     newChildrenBottom = newWidgets.length - 1;
  139.     oldChildrenBottom = oldChildren.length - 1;
  140.  
  141.     // 将后面相同的Element更新后添加到newChildren，至此形成新的完整的children。
  142.     while ((oldChildrenTop <= oldChildrenBottom) && (newChildrenTop <= newChildrenBottom)) {
  143.       final Element oldChild = oldChildren[oldChildrenTop];
  144.      
  145.  
  146.       final Widget newWidget = newWidgets[newChildrenTop];
  147.  
  148.  
  149.       final Element newChild = updateChild(oldChild, newWidget, slotFor(newChildrenTop, previousChild))!;
  150.      
  151.  
  152.       newChildren[newChildrenTop] = newChild;
  153.       previousChild = newChild;
  154.       newChildrenTop += 1;
  155.       oldChildrenTop += 1;
  156.     }
  157.  
  158.     // 清除旧列表中多余的带key的Element
  159.     if (haveOldChildren && oldKeyedChildren!.isNotEmpty) {
  160.       for (final Element oldChild in oldKeyedChildren.values) {
  161.         if (forgottenChildren == null || !forgottenChildren.contains(oldChild)) {
  162.           deactivateChild(oldChild);
  163.         }
  164.       }
  165.     }
  166.  
  167.     return newChildren;
  168.   }

dif算法相对比较复杂，可能理解起来比较困难。值得一提的是，无论 updateChild还是updateChildren都实现在基类element里。同层diff算法里使用key并不是出于性能考虑，没有key能够就地复用，使用key能够指定复用对象。有时候就地复用会有一些问题，譬如某个widget自身有一些状态，你如果就地复用其他widget，就会导致这些状态的丢失。

3.6 inflateWidget

再来看看inflateWidget的实现，它主要是用来创建新的element，并且mount。如果widget有GlobalKey的话，则会尝试获取对应的element，然后更新后返回。

  1. Element inflateWidget(Widget newWidget, Object? newSlot) {
  2.  
  3.     try {
  4.       //如果widget带key，并且是GlobalKey，则尝试获取一下对应的element，并用新的widget更新它然后返回
  5.       final Key? key = newWidget.key;
  6.       if (key is GlobalKey) {
  7.         final Element? newChild = _retakeInactiveElement(key, newWidget);
  8.         if (newChild != null) {
  9.           
  10.           newChild._activateWithParent(this, newSlot);
  11.           final Element? updatedChild = updateChild(newChild, newWidget, newSlot);
  12.  
  13.           return updatedChild!;
  14.         }
  15.       }
  16.  
  17.     // 这里就调用到了createElement，重新创建了Element
  18.       final Element newChild = newWidget.createElement();
  19.       
  20.       newChild.mount(this, newSlot);
  21.  
  22.       return newChild;
  23.     } 
  24.   }

3.7 mount

我们再来看看element基类的mount：

  1. void mount(Element? parent, Object? newSlot) {
  2.     
  3.     _parent = parent;
  4.     _slot = newSlot;
  5.     _lifecycleState = _ElementLifecycle.active;
  6.     _depth = _parent != null ? _parent!.depth + 1 : 1;
  7.     if (parent != null) {
  8.       // Only assign ownership if the parent is non-null. If parent is null
  9.       // (the root node), the owner should have already been assigned.
  10.       // See RootRenderObjectElement.assignOwner().
  11.       _owner = parent.owner;
  12.     }
  13.  
  14.     final Key? key = widget.key;
  15.     if (key is GlobalKey) {
  16.       owner!._registerGlobalKey(key, this);
  17.     }
  18.     _updateInheritance();
  19.     attachNotificationTree();
  20.   }

mount就是将自身插入父element的某个slot中。我们发现Element在mount的时候，会将父element的ower设置给自己。如果widget带有key，那么ower会将这个element注册到自己的map里。

而对于组合式Element的mount有所差异，除了上述基类行为，还会调用_firstBuild：

  1. @override
  2.   void mount(Element? parent, Object? newSlot) {
  3.     super.mount(parent, newSlot);
  4.     _firstBuild();
  5.  
  6.   }
  7.  
  8.   void _firstBuild() {
  9.     // StatefulElement overrides this to also call state.didChangeDependencies.
  10.     rebuild(); // This eventually calls performRebuild.
  11.   }

对于StatelessElement，_firstBuild的实现只是单纯rebuild一下。而对于StatefulElement:

  1. @override
  2.   void _firstBuild() {
  3.  
  4.     final Object? debugCheckForReturnedFuture = state.initState() as dynamic;
  5.     state.didChangeDependencies();
  6.     super._firstBuild();
  7.   }

我们发现_firstBuild里调用了state的initState方法，这里说明我们在state里实现的生命周期方法，其实会被StatefulElement根据自身的不同状态而调用。因此其他方法我们不再赘述。

3.8 why?

在参考文章里有一个问题，我们来分析一下，增加我们对本文的理解程度。现在我们有如下一段代码：

  1. import 'dart:math';
  2.  
  3. import 'package:flutter/foundation.dart';
  4. import 'package:flutter/material.dart';
  5.  
  6. void main() => runApp(MyApp());
  7.  
  8. class MyApp extends StatelessWidget {
  9.   @override
  10.   Widget build(BuildContext context) {
  11.     return MaterialApp(
  12.       title: 'Flutter Demo',
  13.       theme: ThemeData(
  14.         primarySwatch: Colors.blue,
  15.       ),
  16.       home: MyHomePage(title: 'Home Page'),
  17.     );
  18.   }
  19. }
  20.  
  21. class MyHomePage extends StatefulWidget {
  22.   MyHomePage({Key key, this.title}) : super(key: key);
  23.  
  24.   final String title;
  25.  
  26.   @override
  27.   _MyHomePageState createState() => _MyHomePageState();
  28. }
  29.  
  30. class _MyHomePageState extends State<MyHomePage> {
  31.   List<Widget> widgets;
  32.  
  33.   @override
  34.   void initState() {
  35.     super.initState();
  36.     widgets = [
  37.       StatelessColorfulTile(),
  38.       StatelessColorfulTile()
  39.     ];
  40.   }
  41.  
  42.   @override
  43.   Widget build(BuildContext context) {
  44.     return Scaffold(
  45.       appBar: AppBar(
  46.         title: Text(widget.title),
  47.       ),
  48.       body: Row(
  49.         children: widgets,
  50.       ),
  51.       floatingActionButton: FloatingActionButton(
  52.         child: Icon(Icons.refresh),
  53.         onPressed: _swapTile,
  54.       ),
  55.     );
  56.   }
  57.  
  58.   _swapTile() {
  59.     setState(() {
  60.       widgets.insert(1, widgets.removeAt(0));
  61.     });
  62.   }
  63. }
  64.  
  65. class StatelessColorfulTile extends StatelessWidget {
  66.  
  67.   final Color _color = Utils.randomColor();
  68.  
  69.   @override
  70.   Widget build(BuildContext context) {
  71.     return Container(
  72.       height: 150,
  73.       width: 150,
  74.       color: _color,
  75.     );
  76.   }
  77. }
  78.  
  79. class Utils {
  80.   static Color randomColor() {
  81.     var red = Random.secure().nextInt(255);
  82.     var greed = Random.secure().nextInt(255);
  83.     var blue = Random.secure().nextInt(255);
  84.     return Color.fromARGB(255, red, greed, blue);
  85.   }
  86. }

代码可以直接复制到DartPad中运行查看效果。 或者点击这里直接运行。

效果很简单，就是两个彩色方块，点击右下角的按钮后交换两个方块的位置。上面的方块是StatelessWidget，那我们把它换成StatefulWidget呢？。

  1. class StatefulColorfulTile extends StatefulWidget {
  2.   StatefulColorfulTile({Key key}) : super(key: key);
  3.  
  4.   @override
  5.   StatefulColorfulTileState createState() => StatefulColorfulTileState();
  6. }
  7.  
  8. class StatefulColorfulTileState extends State<StatefulColorfulTile> {
  9.   final Color _color = Utils.randomColor();
  10.  
  11.   @override
  12.   Widget build(BuildContext context) {
  13.     return Container(
  14.       height: 150,
  15.       width: 150,
  16.       color: _color,
  17.     );
  18.   }
  19. }

 再次执行代码，发现方块没有“交换”。这是为什么？结论是widget层面而言，两个widget的确发生了交换，但是Element并没有发生交换，原来位置的Element持有的state build出原来颜色的Container。

6 key

可以看参考，这里暂不展开

7 BuildOwner

buildOwner是framework这些代码背后的大boss。我们来看看它做了哪些事情。每个element都指向一个Owner用来维护它的生命周期：

  1. BuildOwner? get owner => _owner;
  2. BuildOwner? _owner;

为什么我们能用globalKey找到对应的element，没有什么神奇的，因为buildOwner有一个map维护着globalKey和element的对应关系：

  1.   final Map<GlobalKey, Element> _globalKeyRegistry = <GlobalKey, Element>{};
  2.  
  3. void _registerGlobalKey(GlobalKey key, Element element)
  4. void _unregisterGlobalKey(GlobalKey key, Element element)

buildOwner另一个作用是维护着element的build列表：

  1.   final List<Element> _dirtyElements = <Element>[];
  2.  
  3. void scheduleBuildFor(Element element) {
  4.     if (element._inDirtyList) {
  5.       _dirtyElementsNeedsResorting = true;
  6.       return;
  7.     }
  8.     if (!_scheduledFlushDirtyElements && onBuildScheduled != null) {
  9.       _scheduledFlushDirtyElements = true;
  10.       onBuildScheduled!();
  11.     }
  12.     _dirtyElements.add(element);
  13.     element._inDirtyList = true;
  14.     
  15.   }

WidgetsBinding会通过WidgetsBinding.drawFrame调用buildOwner的buildScope：

  1. void drawFrame() {
  2.   buildOwner!.buildScope(renderViewElement!); // 1.重新构建widget
  3.   super.drawFrame();
  4.   //下面几个是在super.drawFrame()执行的
  5.   pipelineOwner.flushLayout();          // 2.更新布局
  6.   pipelineOwner.flushCompositingBits();     //3.更新“层合成”信息
  7.   pipelineOwner.flushPaint();               // 4.重绘
  8.   if (sendFramesToEngine) {
  9.     renderView.compositeFrame();            // 5. 上屏，将绘制出的bit数据发送给GPU
  10.   }
  11. }

buildScope对_dirtyElements里的element调用rebuild：

  1. void buildScope(Element context, [ VoidCallback? callback ]) {
  2.     if (callback == null && _dirtyElements.isEmpty) {
  3.       return;
  4.     }
  5.     try {
  6.       _scheduledFlushDirtyElements = true;
  7.       if (callback != null) {
  8.         _dirtyElementsNeedsResorting = false;
  9.         try {
  10.           callback();
  11.         }
  12.         
  13.       }
  14.       _dirtyElements.sort(Element._sort);
  15.       _dirtyElementsNeedsResorting = false;
  16.       int dirtyCount = _dirtyElements.length;
  17.       int index = 0;
  18.       while (index < dirtyCount) {
  19.         final Element element = _dirtyElements[index];
  20.         try {
  21.           element.rebuild();
  22.         } 
  23.  
  24.         index += 1;
  25.         if (dirtyCount < _dirtyElements.length || _dirtyElementsNeedsResorting!) {
  26.           _dirtyElements.sort(Element._sort);
  27.           _dirtyElementsNeedsResorting = false;
  28.           dirtyCount = _dirtyElements.length;
  29.           while (index > 0 && _dirtyElements[index - 1].dirty) {
  30.             // It is possible for previously dirty but inactive widgets to move right in the list.
  31.             // We therefore have to move the index left in the list to account for this.
  32.             // We don't know how many could have moved. However, we do know that the only possible
  33.             // change to the list is that nodes that were previously to the left of the index have
  34.             // now moved to be to the right of the right-most cleaned node, and we do know that
  35.             // all the clean nodes were to the left of the index. So we move the index left
  36.             // until just after the right-most clean node.
  37.             index -= 1;
  38.           }
  39.         }
  40.       }
  41.      
  42.     } finally {
  43.       for (final Element element in _dirtyElements) {
  44.         assert(element._inDirtyList);
  45.         element._inDirtyList = false;
  46.       }
  47.       _dirtyElements.clear();
  48.       _scheduledFlushDirtyElements = false;
  49.       _dirtyElementsNeedsResorting = null;
  50.     }
  51.   }

后面的流程就回到了我们前面的performRebuild方法 。

8 没有覆盖的内容

本文没有提及具体的布局逻辑，将在后面的文章里进行讲述。

9 图示

文中出现的一些关键类的继承关系：

参考

1.说说Flutter中最熟悉的陌生人 —— Key_flutter globalkey 源码_唯鹿的博客-CSDN博客

声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/菜鸟追梦旅行/article/detail/313322
推荐阅读