【动画图解】是怎样的方法,能被称作是 Flutter Widget 系统的核心?

202 阅读9分钟

上一篇文章我们探讨了 Flutter 布局初始化的流程,本文我们将继续深入,分析 Flutter 是如何更新现有布局的。

相较于初始化布局,根据变化的状态更新现有布局是一个更为频繁的操作。在这个过程中,如何最大限度地重用 Element 对象,对于性能的优化至关重要。这不仅可以更好地重用与状态和布局相关的信息,还能避免重新遍历整棵子树。

而这其中涉及的一个最关键的方法就是 Element 的 updateChild() 方法,updateChild() 方法是 Widgets 系统的核心。每次我们要根据更新的配置添加、更新或删除子项时,都会调用它

但在深入探讨这个方法之前,让我们先从 Flutter 开发者更为熟悉的 setState() 方法开始切入。

setState() 方法背后做了什么?

setState() 方法用于通知 Flutter 框架 State 对象的内部状态已更改,随后,框架会调用该对象的 build 方法,以使用最新的状态更新用户界面。

  Future<void> _incrementCounter() {
    setState(() {
      _counter++;
    });
  }

setState() 方法内部会将 Element 标记为需要重建,标记的方式是将 Element 设置为“脏”(dirty):

  @protected
  void setState(VoidCallback fn) {
    /// 将 Element 标记为需要重建
    _element!.markNeedsBuild();
  }
  void markNeedsBuild() {
    if (dirty) {
      return;
    }
    /// 将 Element 设置为脏元素
    _dirty = true;
    owner!.scheduleBuildFor(this);
  }

随后,将该 Element 添加到脏元素列表,然后等待在下一帧中重新构建:

void scheduleBuildFor(Element element) {
  /// 将 Element 添加到脏元素列表
  _dirtyElements.add(element);
  element._inDirtyList = true;
}

到了下一帧时,WidgetsBinding.drawFrame() 方法内部会调用 buildScope() 方法,按深度优先的顺序重新构建被标记为 dirty 的所有 Element:

  void buildScope(Element context, [ VoidCallback? callback ]) {
     while (index < dirtyCount) {
        /// 按深度优先的顺序重新构建标记为 dirty 的所有 Element。
        final Element element = _dirtyElements[index];
        element.rebuild();
     }
  }
  void rebuild({bool force = false}) {
    performRebuild();
  }

performRebuild() 方法在 Element 类自身的基本实现中,仅仅是清除了 dirty 标记:

  @protected
  @mustCallSuper
  void performRebuild() {
    _dirty = false;
  }

而在 ComponentElement 的实现中,则是调用 build() 方法重新构建 Widget 子树,获取新的 UI 配置,并使用新的配置来更新子项:

  void performRebuild() {
    /// 重新构建 Widget 子树,获取新的 UI 配置
    Widget? built;
    try {
      built = build();
    } catch (e, stack) { 
      ...
    } finally {
      super.performRebuild(); // 清除 dirty 标记
    }  
    /// 使用新的配置来更新子项
    _child = updateChild(_child, built, slot);
  }

这也解释了为什么当需要创建可重用的 UI 时,Flutter 更建议我们将其提取为单独的 Widget 而不是辅助方法(Helper Method)。因为当我们在 State 对象上调用 setState()时,所有后代 Widget 都将重建。

将可重用的 UI 提取为单独的 Widget 后,就可以将 setState() 的调用转移到实际需要更改 UI 的 Widget 中,从而减少 Widget 重建的范围。

另外在 RenderObjectElement 的实现中,performRebuild() 方法则是更新了 RenderObject 对象:

  @override
  void performRebuild() { 
    _performRebuild();
  }

  @pragma('vm:prefer-inline')
  void _performRebuild() {
    (widget as RenderObjectWidget).updateRenderObject(this, renderObject);
    super.performRebuild(); 
  }

好了,现在我们知道调用了 setState() 方法后是如何走到 updateChild() 方法的了。其实在上一篇的初始化布局中我们已经快速过了 updateChild() 方法的其中一种场景,这次我们索性把所有场景都分析一下。

updateChild() 方法的所有场景

场景1:Widget 被移除

  Element? updateChild(Element? child, Widget? newWidget, Object? newSlot) {
    /// Widget 树中某个指定位置的 Widget 被移除
    if (newWidget == null) {
      if (child != null) {
        deactivateChild(child);
      }
      return null;
    }
    /// ...
  }

当重建的 Widget 树中某个指定位置的 Widget 被移除后,Flutter 框架首先会将对应位置的 Element 对象从 Element 树中分离:

  void deactivateChild(Element child) {
    /// 将对应位置的 Element 对象从 Element 树中分离
    child._parent = null;
    /// 依次访问其子项,将 RenderObjectElement 类型的节点
    /// 关联的 RenderObject 与 RenderObject 树分离
    child.detachRenderObject();
    /// 将给定 Element 移动到非活动的 Element 列表中,
    /// 最终会依次将其子节点的Key和Widget清空
    owner!._inactiveElements.add(child); 
  }

随后,会依次访问该 Element 对象的子项,将 RenderObjectElement 类型的节点关联的 RenderObject 对象也从 RenderObject 树中分离:

  void detachRenderObject() {
    visitChildren((Element child) {
      child.detachRenderObject();
    });
    _slot = null;
  }
  @override
  void detachRenderObject() {
    if (_ancestorRenderObjectElement != null) {
      _ancestorRenderObjectElement!.removeRenderObjectChild(renderObject, slot);
      _ancestorRenderObjectElement = null;
    }
    _slot = null;
  }

这一场景的动画演示如下:

场景2:Widget 实例不变

  Element? updateChild(Element? child, Widget? newWidget, Object? newSlot) {
    final Element newChild;
    if (child != null) {
      if (hasSameSuperclass && child.widget == newWidget) {
        if (child.slot != newSlot) {
          updateSlotForChild(child, newSlot);
        }
        /// Element 保持不变,直接重用
        newChild = child;
      } 
    }
  }

这种场景一般出现在使用 const 构造函数构建 Widget 实例的情况,这相当于将 Widget 实例缓存起来,然后在每次构建的时候直接重用。

Widget 实例不变,其关联的 Element 对象及其子级自然也是同样保持不变,因此可以直接重用。

这一场景的动画演示如下:

场景3:Widget 类型不变,只更新属性

Element? updateChild(Element? child, Widget? newWidget, Object? newSlot) {
  final Element newChild;
  if (child != null) {
    /// 同一个超类且 Widget 的类型和 Key 相同
    if (hasSameSuperclass && Widget.canUpdate(child.widget, newWidget)) {
      /// 更新 Element 所持有的 Widget 引用
      child.update(newWidget);
      /// Element 保持不变,直接重用
      newChild = child;
    }
  }
}

static bool canUpdate(Widget oldWidget, Widget newWidget) {
  return oldWidget.runtimeType == newWidget.runtimeType
    && oldWidget.key == newWidget.key;
}

这种场景适用于绝大部分的情况。只要 Widget 的类型和 Key 保持不变(Key 默认为空),就会使用新的 Widget 实例来更新 Element 所持有的 Widget 引用,也即更新为新的 UI 配置。

  @mustCallSuper
  void update(covariant Widget newWidget) {
    _widget = newWidget;
  }

而在其子类 StatefulElement 和 StatelessElement 的 update() 方法实现中,会再次调用 rebuild() 方法,继续执行对下一级的递归构建,就这样逐级进行,最终完成了整棵 Widget 树的重新构建和 Element 树中每个节点对 Widget 的引用更新。

class StatelessElement extends ComponentElement {
  @override
  void update(StatelessWidget newWidget) {
    super.update(newWidget);
    rebuild(force: true);
  }
}

另外,对于 RenderObjectElement 类型,update() 方法还会更新对应的 RenderObject:

abstract class RenderObjectElement extends Element {
  @override
  void update(covariant RenderObjectWidget newWidget) {
    super.update(newWidget);
    _performRebuild(); // calls widget.updateRenderObject()
  }

  void performRebuild() { 
    (widget as RenderObjectWidget).updateRenderObject(this, renderObject);
    super.performRebuild();
  }
}

以 Text Widget 更新文本的过程为例,作为 RenderObjectWidget 类型的 RichText 会使用传入的最新文本来更新 RenderParagraph,使其能够重新渲染为最新文本:

  void updateRenderObject(BuildContext context, RenderParagraph renderObject) {
    assert(textDirection != null || debugCheckHasDirectionality(context));
    renderObject
      ..text = text
      ..textAlign = textAlign
      ..textDirection = textDirection ?? Directionality.of(context)
      ..softWrap = softWrap
      ..overflow = overflow
      ..textScaler = textScaler
      ..maxLines = maxLines
      ..strutStyle = strutStyle
      ..textWidthBasis = textWidthBasis
      ..textHeightBehavior = textHeightBehavior
      ..locale = locale ?? Localizations.maybeLocaleOf(context)
      ..registrar = selectionRegistrar
      ..selectionColor = selectionColor;
  }

场景4:Widget 类型或 Key 发生改变

  Element? updateChild(Element? child, Widget? newWidget, Object? newSlot) {
    final Element newChild;
    if (child != null) {
      if (hasSameSuperclass && Widget.canUpdate(child.widget, newWidget)) {
      } else {
        /// 将原有的 Element 对象和 RenderObject 对象从树中分离
        deactivateChild(child);
        /// 创建新的 Element 对象和 RenderObject 对象并挂载到树上
        newChild = inflateWidget(newWidget, newSlot);
      }
    }
  }

当 Widget 类型或 Key 发生改变时,Flutter 框架首先会将原有的 Element 对象和 RenderObject 对象及其子级从树中分离,

随后递归创建新的 Element 对象和 RenderObject 对象及其子级并挂载到树上。

场景5:Widget 不为空但 Elemet 子项为空

  Element? updateChild(Element? child, Widget? newWidget, Object? newSlot) {
    final Element newChild;
    if (child != null) {
    } else {
      newChild = inflateWidget(newWidget, newSlot);
    }
  }

这种场景一般出现在初始化布局或往布局中插入新的节点的情况,这个时候就会直接递归创建新的 Element 对象和 RenderObject 对象及其子级并挂载到树上。

问题解答

分析过了所有场景之后,现在,我们就可以来回顾一下上一篇文章开头提出的另外两个关键问题:

  1. Widget树的每一次变更都会导致Element树和Render树重建吗?

并不一定,取决于 Widget 的变更内容。Flutter框架采用了一种高效的差异化更新机制:

    1. 当 Widget 被移除时,会将关联的 Element 和 RenderObject 也从树中移除;
    2. 当 Widget 实例不变时,会直接重用原来的 Element 。
    3. 当 Widget 类型不变,只更新属性时,会重用原来的 Element ,并更新其持有的 Widget 引用。对于 RenderObjectElement,还有更新其持有的 RenderObject 的属性。
    4. 当 Widget 类型或 Key 发生改变时,会将关联的 Element 和 RenderObject 从树中移除,然后创建新的对象集合挂载到树上。
    5. 当 Widget 不为空但 Elemet 子项为空时,会创建新的对象集合挂载到树上。
  1. Widget树被销毁重建后,它是如何与原先的Element树重新建立关联的?

准确来说,「Widget树被销毁重建」和「与原先的Element树重新建立关联」并不是两个独立的过程,而是从被标记为 dirty 的 Element 节点开始,递归地进行差异化比对和更新的。

对于 Element 树中的每个节点,都会先调用 build() 方法来获取新的 Widget,随后调用 updateChild() 方法来比较新 Widget 与现有 Element 节点持有的旧 Widget的差异:

    1. 当新的 Widget 为空时,将 Element 节点也从树中移除;
    2. 当新旧 Widget 为同一个实例时,与 Element 节点的关联关系不变。
    3. 当新旧 Widget 类型相同,仅属性不同时,Element 节点会与新的 Widget 重新建立关联。
    4. 当新旧 Widget 的类型或 Key 不同时,将旧的 Element 节点从树中移除,然后使用新的 Widget 创建新的 Element 并挂载到树上。
    5. 当新的 Widget 在 Element 树上找不到关联的节点时,会创建新的 Element 并挂载到树上。

"隐式" Widget 的真正影响

综合了以上所有内容后,我们再来回顾一下上一篇文章中遗留的一个讨论点,也就是:

"隐式" Widget 的引入改变了 Widget 树的层次结构,可能会对 Flutter 的渲染性能产生显著影响。

这个显著影响具体是什么呢?当 Container 的 color 属性引入了一个 ColoredBox 用以处理颜色渲染后,相当于原本对应位置的 Widget 类型发生了改变,原有的 Element 对象和 RenderObject 对象就无法再复用了,只能从 ColoredBox 对应的节点往下开始创建新的对象并挂载到树上,这也就意味着需要重新进行布局计算,会造成不必要性能开销。

我们可以通过在 Flutter Inspect 工具中的 Widget Tree Detail 面板中对比前后的 RenderObject 实例是否一致来验证:

原始布局Container增加了alignment属性

由此得到的启示是,在根据不同的应用状态进行 UI 声明时,我们应该尽量避免更改 Widget 子树的深度或更改 Widget 子树中 的 Widget 类型。