背靠大樹好乘涼——Flutter 視圖渲染機制探究之三棵樹

Flutter 在維基百科中的介紹中第一句就是「Flutter is an open-source UI software development kit created by Google」，可見，它是一個以 UI 爲主的開發環境，那 UI 就是它的重中之重。那麼，做爲一個 UI 開發套件，它到底是如何工做的呢？或者說，它到底是怎麼把咱們的代碼轉化爲一個個的界面，渲染在設備的方寸屏幕之上呢？node

三棵樹——視圖建立

Widget 和 Element

試想一下，若是公司的 UI 給了你一個界面，讓你完成它，那麼你會如何開始？是否是首先肯定這是一個靜態的（stateless）仍是動態的（stateful）頁面？若是是靜態的，那麼自定義一個 StatelessWidget 的子類，而後重寫其 build() 方法，在 build() 方法中，咱們只需構造出咱們的頁面（Widget 對象），而後將其返回方法外便可。若是是動態的，那麼須要自定義 StatefulWidget 和 State 的子類，這裏先按下不表，後面咱們再和它們有一個深刻的認識。express

那麼可想而知，flutter 就是把咱們在 build() 方法中深耕細做的圖形相關的代碼拿去畫出了形形色色的按鈕、文字等這些真實可見的圖形，那麼它到底是如何在「神不知鬼不覺」的狀況下完成這一切的呢？markdown

咱們以 StatelessWidget 的 build() 方法爲源頭出發，看看它創造出來的 widget 到底去了哪裏，作了什麼。app

/// StatelessElement 
@override
Widget build() => widget.build(this);
複製代碼

/// ComponentElement（StatelessElement 的父類）
@override
void performRebuild() {
    // ...
    Widget built;
    try {
        // ...
        built = build();
        // ...
    } catch (e, stack) {
        _debugDoingBuild = false;
        built = ErrorWidget.builder(
            _debugReportException(
                ErrorDescription('building $this'),
                e,
                stack,
                informationCollector: () sync* {
                    yield DiagnosticsDebugCreator(DebugCreator(this));
                },
            ),
        );
    } finally {
        // ...
    }
    try {
        _child = updateChild(_child, built, slot);
        assert(_child != null);
    } catch (e, stack) {
        built = ErrorWidget.builder(
            _debugReportException(
                ErrorDescription('building $this'),
                e,
                stack,
                informationCollector: () sync* {
                    yield DiagnosticsDebugCreator(DebugCreator(this));
                },
            ),
        );
        _child = updateChild(null, built, slot);
    }

    // ...
}
複製代碼

咱們建立的 widget 做爲參數傳遞給 updateChild() 方法。框架

/// Element
@protected
Element updateChild(Element child, Widget newWidget, dynamic newSlot) {
    if (newWidget == null) {
        if (child != null)
            deactivateChild(child);
        return null;
    }
    Element newChild;
    if (child != null) {
        bool hasSameSuperclass = true;
        // ...
        // Widget 和 Element 的類型（Stateless 或 Stateful 等）沒有變化且 widget 沒有變動
        if (hasSameSuperclass && child.widget == newWidget) {
            if (child.slot != newSlot)
                updateSlotForChild(child, newSlot);
            newChild = child;
        } else if (hasSameSuperclass && Widget.canUpdate(child.widget, newWidget)) {
            /// Widget 和 Element 的類型（Stateless 或 Stateful 等）沒有變化
            /// 且新舊 widget 的運行時類型和 key 是相同的（canUpdate() 方法的內容）
            if (child.slot != newSlot)
                updateSlotForChild(child, newSlot);
            child.update(newWidget);
            assert(child.widget == newWidget);
            assert(() {
                child.owner._debugElementWasRebuilt(child);
                return true;
            }());
            newChild = child;
        } else {
            /// 對於剛建立的 widget，由於以前尚未掛載過，因此要走這裏先進行掛載
            deactivateChild(child);
            assert(child._parent == null);
            newChild = inflateWidget(newWidget, newSlot);
        }
    } else {
        newChild = inflateWidget(newWidget, newSlot);
    }

    //...

    return newChild;
}
複製代碼

上面的方法中我添加了一些註釋，因此下面將要進行的就是將咱們建立的 widget 掛載到 flutter 已有的視圖樹上，看看具體操做了些什麼：less

/// Element
@protected
Element inflateWidget(Widget newWidget, dynamic newSlot) {
    assert(newWidget != null);
    final Key key = newWidget.key;
    if (key is GlobalKey) {
        final Element newChild = _retakeInactiveElement(key, newWidget);
        if (newChild != null) {
            assert(newChild._parent == null);
            assert(() {
                _debugCheckForCycles(newChild);
                return true;
            }());
            newChild._activateWithParent(this, newSlot);
            final Element updatedChild = updateChild(newChild, newWidget, newSlot);
            assert(newChild == updatedChild);
            return updatedChild;
        }
    }
    /// newWidget 是咱們建立的 StatelessWidget 子類，經過參數傳遞過來，
    /// 這裏經過 newWidget 建立了一個 Element類。
    final Element newChild = newWidget.createElement();
    assert(() {
        _debugCheckForCycles(newChild);
        return true;
    }());
    /// 這一步將新建立的 element 掛載到 Element 樹上
    newChild.mount(this, newSlot);
    assert(newChild._debugLifecycleState == _ElementLifecycle.active);
    return newChild;
}
複製代碼

mount() 方法是將建立的 element 掛載到 Element 樹上，看方法：ide

/// Element
void mount(Element parent, dynamic newSlot) {
    // ...
    _parent = parent;
    _slot = newSlot;
    _depth = _parent != null ? _parent.depth + 1 : 1;
    _active = true;
    if (parent != null) // Only assign ownership if the parent is non-null
        _owner = parent.owner;
    final Key key = widget.key;
    if (key is GlobalKey) {
        key._register(this);
    }
    _updateInheritance();
    // ...
}
複製代碼

經過一種相似鏈式的賦值，將新的 element 連接到樹的尾端。可是這裏有一個問題，就是新建立的 element 將 _parent 變量指向了原 Element 樹的末端節點，這僅僅是單向的鏈，父節點的 _child 變量並無指向新的 element，那麼如何向下遍歷呢？咱們將上面的方法倒着再走一遍，新建立的 element 被返回，那麼它又被用來作什麼呢？一路向上，看到 ComponentElement 的performRebuild() 方法，這裏返回的 element 被賦值給父節點的 _child 變量，至此，雙向連接完成。函數

還有一個變量須要在這裏提早關注一下，就是這個「slot」，到目前爲止，它好像一直在伴隨着咱們走過各個方法，可是好像並無實際的做用。其實咱們後面主要研究的幾乎全部方法都能看到它的身影，不過既然暫時沒有發揮到它的做用，那咱們就先記住有這麼個東西，並且賦值給了 Element 的_slot 成員，後面在它須要發揮做用的時候，咱們會繼續介紹這個同行者。ui

一條完整的 Element 樹有了，那這棵樹是怎麼渲染到屏幕上的呢？咱們暫時先無論，繼續看看 StatefulWidget 的「種樹」過程。this

StatefulWidget 和 StatelessWidget 有一點不同的地方在於，StatefulWidget 的 build() 方法是在 State 中的，StatefulWidget 經過 createState() 方法建立 State，咱們看看調用關係：

能夠看到，StatefulElement 持有 State，那明確了這一點以後，再看 State 的 build() 方法的調用關係：

/// StatefulElement
@override
Widget build() => _state.build(this);
複製代碼

StatefulElement 和 StatelessElement 同樣，同屬於 ComponentElement 的子類。因此咱們上面看到的 ComponentElement 的 performRebuild() 方法調用 build() 方法的過程一樣適用於它，後面的流程就和 StatelessWidget 同樣了。

介紹到這裏，咱們已經揭開了兩棵樹的神祕面紗——Widget 樹和 Element 樹，目前來看，它們是一一對應的。在 Element 類的成員變量中就有一個 Widget 實例 _widget，它會在 Element 建立時和調用 update() 時被賦值，這也側面佐證了兩者的一一對應關係。那麼第三棵樹到底是什麼呢？

RenderObject

咱們在 Android studio 裏打開 Widget 類的源碼，而後打開 Hierarchy（能夠雙擊 Shift 或者使用快捷鍵 Ctrl + Shift + A 搜索，也可使用你的快捷鍵打開），咱們看到 Widget 的直接子類有下面幾個，咱們注意到，除了剛剛已經接觸的 StatelessWidget 和 StatefulWidget，還有其餘幾個陌生的子類。

其中 PreferredSizeWidget 和 ProxyWidget 是對 Widget 某方面需求的簡單封裝，各拓展了一個屬性，因此在必定程度上能夠認爲等同於 Widget，那還有一個 RenderObjectWidget，這個類是幹什麼的呢？咱們看看它的源碼：

/// RenderObjectWidgets provide the configuration for [RenderObjectElement]s,
/// which wrap [RenderObject]s, which provide the actual rendering of the
/// application.
abstract class RenderObjectWidget extends Widget {
  /// Abstract const constructor. This constructor enables subclasses to provide
  /// const constructors so that they can be used in const expressions.
  const RenderObjectWidget({ Key key }) : super(key: key);

  /// RenderObjectWidgets always inflate to a [RenderObjectElement] subclass.
  @override
  @factory
  RenderObjectElement createElement();

  /// Creates an instance of the [RenderObject] class that this
  /// [RenderObjectWidget] represents, using the configuration described by this
  /// [RenderObjectWidget].
  ///
  /// This method should not do anything with the children of the render object.
  /// That should instead be handled by the method that overrides
  /// [RenderObjectElement.mount] in the object rendered by this object's
  /// [createElement] method. See, for example,
  /// [SingleChildRenderObjectElement.mount].
  @protected
  @factory
  RenderObject createRenderObject(BuildContext context);

  /// Copies the configuration described by this [RenderObjectWidget] to the
  /// given [RenderObject], which will be of the same type as returned by this
  /// object's [createRenderObject].
  ///
  /// This method should not do anything to update the children of the render
  /// object. That should instead be handled by the method that overrides
  /// [RenderObjectElement.update] in the object rendered by this object's
  /// [createElement] method. See, for example,
  /// [SingleChildRenderObjectElement.update].
  @protected
  void updateRenderObject(BuildContext context, covariant RenderObject renderObject) { }

  /// A render object previously associated with this widget has been removed
  /// from the tree. The given [RenderObject] will be of the same type as
  /// returned by this object's [createRenderObject].
  @protected
  void didUnmountRenderObject(covariant RenderObject renderObject) { }
}
複製代碼

能夠看到，相比於 StatelessWidget 和 StatefulWidget，它多了三個方法，分別是 createRenderObject()、updateRenderObject() 和 didUnmountRenderObject()，咱們先研究建立的過程。

RenderObjectElement 的 mount() 方法調用了 createRenderObject() 方法（這裏能夠看到對於 RenderObjectWidget，一樣有 RenderObjectElement 與之對應）：

/// RenderObjectElement
@override
void mount(Element parent, dynamic newSlot) {
    super.mount(parent, newSlot);
    // ...
    _renderObject = widget.createRenderObject(this);
    // ...
    attachRenderObject(newSlot);
    _dirty = false;
}
複製代碼

建立的 RenderObject 對象賦值給 _renderObject 對象存儲起來，緊接着執行 attachRenderObject() 方法：

/// RenderObjectElement
@override
void attachRenderObject(dynamic newSlot) {
    assert(_ancestorRenderObjectElement == null);
    _slot = newSlot;
    _ancestorRenderObjectElement = _findAncestorRenderObjectElement();
    _ancestorRenderObjectElement?.insertRenderObjectChild(renderObject, newSlot);
    final ParentDataElement<ParentData> parentDataElement = _findAncestorParentDataElement();
    if (parentDataElement != null)
        _updateParentData(parentDataElement.widget);
}
複製代碼

_findAncestorRenderObjectElement() 方法的做用是向上尋找第一個 RenderObjectElement 對象的實例：

/// RenderObjectElement
RenderObjectElement _findAncestorRenderObjectElement() {
    Element ancestor = _parent;
    while (ancestor != null && ancestor is! RenderObjectElement)
        ancestor = ancestor._parent;
    return ancestor as RenderObjectElement;
}
複製代碼

這裏咱們就能夠知道一點，RenderObject 並不和 Element 樹一一對應，也就不和 Widget 樹對應了，咱們能夠這樣理解，咱們建立的 StatelessWidget 和 StatefulWidget 更大程度上是一個容器，它們並非實際的可見的視圖元素，而只是對一組可見的視圖元素的排列組合，規定了排列位置和大小等，因此它們並不須要實際渲染出來，而那些繼承了 RenderObjectWidget 的 widget 纔是須要渲染的，也纔會在 RenderObject 樹上有與之相對應的節點。

好了，言歸正傳，而後調用第一個 RenderObjectElement 祖先的 insertRenderObjectChild() 方法，該方法如今以重寫的方式實現，那麼咱們看兩個比較經常使用的 RenderObjectElement 的子類——SingleChildRenderObjectElement 和 MultiChildRenderObjectElement 的實現。首先是 SingleChildRenderObjectElement：

/// SingleChildRenderObjectElement
@override
void insertRenderObjectChild(RenderObject child, dynamic slot) {
    final RenderObjectWithChildMixin<RenderObject> renderObject = this.renderObject as RenderObjectWithChildMixin<RenderObject>;
    assert(slot == null);
    assert(renderObject.debugValidateChild(child));
    renderObject.child = child;
    assert(renderObject == this.renderObject);
}
複製代碼

須要注意的是，這裏的「this」是第一個 RenderObjectElement 類型的祖先，因此 this.renderObject 也是祖先（父）RenderObject，child 則是咱們建立的 RenderObject 實例。經過給 RenderObject 的 child 成員賦值實現前面和 Element 同樣的連接。

而在 MultiChildRenderObjectElement 的方法中，則經過 ContainerRenderObjectMixin 這個 mixin 來進行插入操做：

/// MultiChildRenderObjectElement
@override
void insertRenderObjectChild(RenderObject child, IndexedSlot<Element> slot) {
    final ContainerRenderObjectMixin<RenderObject, ContainerParentDataMixin<RenderObject>> renderObject =
        this.renderObject as ContainerRenderObjectMixin<RenderObject, ContainerParentDataMixin<RenderObject>>;
    assert(renderObject.debugValidateChild(child));
    renderObject.insert(child, after: slot?.value?.renderObject);
    assert(renderObject == this.renderObject);
}
 
/// ContainerRenderObjectMixin 實際上就是 RenderObject
mixin ContainerRenderObjectMixin<ChildType extends RenderObject, ParentDataType extends ContainerParentDataMixin<ChildType>> on RenderObject {
	/// ... 
}
複製代碼

這裏的關鍵代碼是 renderObject.insert(child, after: slot?.value?.renderObject)，可是在理解 insert() 方法的實現以前，咱們要先搞清楚傳遞的第二個參數 after: slot?.value?.renderObject 究竟是神麼。Slot 咱們在上面也提醒讀者要對它保留一點印象，由於它真的跟着咱們走了一路。一路走來，它神祕又低調，但如今，它再也不低調，由於它終於要發揮它的做用了，隨着咱們對它的研究，它也終將再也不神祕。咱們首先看 Element 類對它的註釋：

/// Information set by parent to define where this child fits in its parent's
/// child list.
///
/// Subclasses of Element that only have one child should use null for
/// the slot for that child.
dynamic get slot => _slot;
dynamic _slot;
複製代碼

哦，孩子的父節點用來判斷孩子的位置的，之因此強調「孩子的」，是爲了代表它是存儲在孩子的對象空間中的，用來找到相對於父節點來講孩子的合適位置。那這麼聽來，父節點應該有不止一個孩子嘍，否則一個位置哪有什麼合適和不合適之說呢。確實如此，對於單孩子的節點來講，這個變量通常爲 null，對於多孩子的節點，這個變量才變得有意義。

上溯到 MultiChildRenderObjectElement 的 mount() 方法：

@override
void mount(Element parent, dynamic newSlot) {
    super.mount(parent, newSlot);
    _children = List<Element>(widget.children.length);
    Element previousChild;
    for (int i = 0; i < _children.length; i += 1) {
        final Element newChild = inflateWidget(widget.children[i], IndexedSlot<Element>(i, previousChild));
        _children[i] = newChild;
        previousChild = newChild;
    }
}

@protected
Element inflateWidget(Widget newWidget, dynamic newSlot) {
    // ...
    newChild.mount(this, newSlot);
    // ...
    return newChild;
}

@immutable
class IndexedSlot<T> {
  /// Creates an [IndexedSlot] with the provided [index] and slot [value].
  const IndexedSlot(this.index, this.value);

  /// Information to define where the child occupying this slot fits in its
  /// parent's child list.
  final T value;

  /// The index of this slot in the parent's child list.
  final int index;
 
  /// ...
}
複製代碼

Slot 就是 IndexedSlot<Element>(i, previousChild) 了，它的 value 指向上一個兄弟節點。那麼 after 就是 child 的上一個兄弟RenderObject，明確了這一點，咱們就能夠繼續往下看renderObject.insert() 方法的實現了：

/// ContainerRenderObjectMixin
ChildType? _firstChild;
ChildType? _lastChild;
/// [child] 新建立的 RenderObject 類，
/// [after] 新建立的 RenderObject 須要插入其後的父節點
void _insertIntoChildList(ChildType child, { ChildType? after }) {
    final ParentDataType childParentData = child.parentData as ParentDataType;
    // ...
    _childCount += 1;
    assert(_childCount > 0);
    if (after == null) {
        // insert at the start (_firstChild)
        childParentData.nextSibling = _firstChild;
        if (_firstChild != null) {
            final ParentDataType _firstChildParentData = _firstChild!.parentData as ParentDataType;
            _firstChildParentData.previousSibling = child;
        }
        _firstChild = child;
        _lastChild ??= child;
    } else {
        // ...
        final ParentDataType afterParentData = after.parentData as ParentDataType;
        if (afterParentData.nextSibling == null) {
            // insert at the end (_lastChild); we'll end up with two or more children
            assert(after == _lastChild);
            childParentData.previousSibling = after;
            afterParentData.nextSibling = child;
            _lastChild = child;
        } else {
            // insert in the middle; we'll end up with three or more children
            // set up links from child to siblings
            childParentData.nextSibling = afterParentData.nextSibling;
            childParentData.previousSibling = after;
            // set up links from siblings to child
            final ParentDataType childPreviousSiblingParentData = childParentData.previousSibling!.parentData as ParentDataType;
            final ParentDataType childNextSiblingParentData = childParentData.nextSibling!.parentData as ParentDataType;
            childPreviousSiblingParentData.nextSibling = child;
            childNextSiblingParentData.previousSibling = child;
            assert(afterParentData.nextSibling == child);
        }
    }
}
複製代碼

這裏的代碼邏輯就很清晰了，將多個孩子以及兄弟關係都清楚地連接起來，RenderObject 的樹就是在這樣的開枝散葉中成長起來的。

欣欣向榮——視圖更新

咱們上面探究了建立三棵樹的節點並插入到樹中的過程，正是在這種機制的保證下，咱們的三棵樹才得以茁壯成長，咱們也才得以憑藉咱們本身的代碼創造出咱們本身的參天大樹。可是爲了保證大樹的欣欣向榮，咱們就要修剪枯枝，將空間和營養留給新芽。因此對於那些已通過時的或者狀態已經再也不正確的「樹枝」和「樹葉」，咱們要如何更新它們呢？

一般咱們在 State 中使用setState() 方法來進行 StatefulWidget 的更新，那麼咱們就從這個方法入手，研究在咱們手動調用了這個方法以後，Flutter 到底作了那些事。

/// State
@protected
void setState(VoidCallback fn) {
    assert(fn != null);
    // ...
    final dynamic result = fn() as dynamic;
    // ...
    _element.markNeedsBuild();
}
複製代碼

setState() 方法中傳入的回調函數會首先被執行，接着會將 StatefulWidget 對應的 StatefulElement 標記爲須要從新構建。

/// Element
void markNeedsBuild() {
    // ...
    if (dirty)
        return;
    _dirty = true;
    owner.scheduleBuildFor(this);
}
複製代碼

接着，將 _dirty 屬性修改成 true，這個變量用來標識此 element 是否須要從新構建，而後調用 BuildOwner 的 scheduleBuildFor() 方法。這裏先簡要地介紹一下 BuildOwner 這個類，老規矩仍是看一下官方的註釋：

Manager class for the widgets framework.

This class tracks which widgets need rebuilding, and handles other tasks that apply to widget trees as a whole, such as managing the inactive element list for the tree and triggering the "reassemble" command when necessary during hot reload when debugging.

The main build owner is typically owned by the [WidgetsBinding], and is driven from the operating system along with the rest of the build/layout/paint pipeline.

Additional build owners can be built to manage off-screen widget trees.

To assign a build owner to a tree, use the [RootRenderObjectElement.assignOwner] method on the root element of the widget tree.

可見，這個類是用來管理視圖框架的一些諸如 rebuild、inactive 狀態等功能的。它會在 WidgetBinding 中建立並賦予給根節點，而後根據視圖樹向下傳遞給每個節點，因此在整棵視圖樹中，它的實例只有一個。更多相關的知識點你們能夠本身研究。

回到 scheduleBuildFor() 方法：

/// BuildOwner

/// Adds an element to the dirty elements list so that it will be rebuilt
/// when [WidgetsBinding.drawFrame] calls [buildScope].
void scheduleBuildFor(Element element) {
    // ...
    if (element._inDirtyList) {
        // ...
        _dirtyElementsNeedsResorting = true;
        return;
    }
    // 當尚未安排刷新髒數據時就給安排上
    // 若是當前處於兩個刷新幀之間，這個方法最終會調用 [window.scheduleFrame]方法，爲下一幀作準備
    if (!_scheduledFlushDirtyElements && onBuildScheduled != null) {
        _scheduledFlushDirtyElements = true;
        onBuildScheduled();
    }
    _dirtyElements.add(element);
    element._inDirtyList = true;
    // ...
}
複製代碼

經過 _dirtyElements.add(element) 將全部須要更新的節點登記在冊以後，在接收到下一個 Vsync 信號進行視圖刷新的時候，就會對這些髒節點按照在樹的深度排序進行依次刷新。這些都在 WidgetsBinding.drawFrame() 方法中完成，但咱們暫時不進入這個方法詳細研究，咱們看它的調用方法：

void buildScope(Element context, [ VoidCallback callback ]) {
    // ...
    Timeline.startSync('Build', arguments: timelineArgumentsIndicatingLandmarkEvent);
    try {
      _scheduledFlushDirtyElements = true;
      // ...
      _dirtyElements.sort(Element._sort);
      _dirtyElementsNeedsResorting = false;
      int dirtyCount = _dirtyElements.length;
      int index = 0;
      while (index < dirtyCount) {
        // ...
        try {
          _dirtyElements[index].rebuild();
        } catch (e, stack) {
          // ...
        }
        index += 1;
        if (dirtyCount < _dirtyElements.length || _dirtyElementsNeedsResorting) {
          _dirtyElements.sort(Element._sort);
          _dirtyElementsNeedsResorting = false;
          dirtyCount = _dirtyElements.length;
          while (index > 0 && _dirtyElements[index - 1].dirty) {
            // It is possible for previously dirty but inactive widgets to move right in the list.
            // We therefore have to move the index left in the list to account for this.
            // We don't know how many could have moved. However, we do know that the only possible
            // change to the list is that nodes that were previously to the left of the index have
            // now moved to be to the right of the right-most cleaned node, and we do know that
            // all the clean nodes were to the left of the index. So we move the index left
            // until just after the right-most clean node.
            index -= 1;
          }
        }
      }
      // ...
    } finally {
      for (final Element element in _dirtyElements) {
        assert(element._inDirtyList);
        element._inDirtyList = false;
      }
      _dirtyElements.clear();
      _scheduledFlushDirtyElements = false;
      _dirtyElementsNeedsResorting = null;
      Timeline.finishSync();
      // ...
    }
    // ...
  }
複製代碼

對前面登記在冊的髒節點進行遍歷，而後依次調用它們的 rebuild() 方法，並且在執行完 build() 方法後，爲了防止視圖樹產生變化，在必要時須要對視圖樹進行從新排序。在最後，再清空全部的登記的髒節點。

rebuild() 方法中調用的是 performRebuild() 方法，這裏就又回到了文章開始的地方，會在這裏經過調用 Widget 的 build() 方法建立 widget，這也就是爲何咱們在手動調用 setState() 方法後，build() 方法會被從新執行的緣由。不過須要注意的是，在 updateChild() 方法中，由於此時的 element 可能已經對應了 widget，因此不會再從新掛載 widget 樹，而只是對 widget 節點作更新操做。

上面咱們也提到，只有 RenderObjectElement 纔會有對應的 RenderObject 對象，RenderObjectElement 的 performRebuild() 方法會對對應的髒的 renderObject 進行更新，具體更新邏輯由 RenderObjectWidget 的子類實現：

@override
void performRebuild() {
    // ..
    widget.updateRenderObject(this, renderObject);
    // ..
    _dirty = false;
}
複製代碼

這樣，三棵樹的更新就全都覆蓋到了，正是在這樣的機制下，三棵樹才能剪掉壞枝葉，健康茁壯成長。

寫在最後（廢話可跳過）

今天這篇文章主要從經常使用方法入手研究了 Widget 的三棵樹以及三棵樹的更新機制，篇幅所限，還有不少的問題暫時都尚未深刻到，好比咱們上面遺留的問題：RenderObject 樹已經造成了，那麼它是如何渲染成畫面的？更多的問題，咱們會再以一個篇幅繼續一塊兒探究。上面的全部文章內容我事先也並非很瞭解，也是邊寫邊看源碼摸索，並且自知功力有限，因此有不少邏輯不嚴謹和疏漏的地方，那若是有誤的地方，歡迎雅正，幫助我這個敲代碼的小學生進步，感謝。