Flutter UI 渲染原理概覽

三棵樹

什么是三棵樹？ 在 Flutter 中 Widget 是核心，一切都是 Widget，但一起協同作業的還有另外兩個元素：Element 和 RenderObject，由于它們都是有著樹形結構，所以經常會稱它們為三棵樹，

Widget

在開發 Flutter 應用程序中，接觸最多的無疑就是Widget，是『描述』 Flutter UI 的基本單元，Flutter 在 widgets 層中使用了相同的概念（一個 Widget）來表示螢屏上的繪制、布局（位置和大小）、用戶互動、狀態管理、主題、影片及導航，

Google 在設計 Widget 時，還賦予它一些鮮明的特點：

• 宣告式 UI —— 相對于傳統 Native 開發中的命令式 UI，宣告式 UI 有不少優勢，如：開發效率顯著提升、UI 可維護性明顯加強等；
• 不可變性 —— Flutter 中所有 Widget 都是不可變的(immutable)，即其內部成員都是不可變的(final)，對于變化的部分需要通過「Stateful Widget-State」的方式實作；
• 組合大于繼承 —— Widget 設計遵循組合大于繼承這一優秀的設計理念，再小的功能也能被抽象，通過組合實作復雜的功能，

Widget 從功能上可以分為 3 類：「Component Widget」、「Proxy Widget」以及「Renderer Widget」，但只有 Renderer Widget 會轉換為 Render Object 最終顯示在 UI 上，

在 Widget 注釋開頭就可以看到：

/// Describes the configuration for an [Element].
///
/// Widgets are the central class hierarchy in the Flutter framework. A widget
/// is an immutable description of part of a user interface. Widgets can be
/// inflated into elements, which manage the underlying render tree.
///

這段注釋闡明了Widget的本質：用于配置 Element 的，Widget 本質上是 UI 的配置資訊 (附帶部分業務邏輯)，

Element

我們知道 Widget 本質上是 UI 的配置資料 (靜態、不可變)，Element 則是通過 Widget 生成的『實體』，兩者間的關系就像是 JSON 與 Object ，同一份配置 (Widget) 可以生成多個實體 (Element)，這些實體可能會被安插在樹上不同的位置，

同樣，Element 注釋中第一句話也可以看出：

/// An instantiation of a [Widget] at a particular location in the tree.
///
/// Widgets describe how to configure a subtree but the same widget can be used
/// to configure multiple subtrees simultaneously because widgets are immutable.
/// An [Element] represents the use of a widget to configure a specific location
/// in the tree. Over time, the widget associated with a given element can
/// change, for example, if the parent widget rebuilds and creates a new widget
/// for this location.
///

Element 間實際上有一棵真實存在的樹「Element Tree」，Element 有 2 個主要職責：

• 根據 UI (「Widget Tree」) 的變化來維護「Element Tree」，包括：節點的插入、更新、洗掉、移動等；
• Widget 與 RenderObject 間的協調者，(它內部持有 Widget 和 RenderObject 的參考)

「Component Element」 —— 組合型 Element，「Component Widget」、「Proxy Widget」對應的 Element 都屬于這一型別，其特點是子節點對應的 Widget 需要通過build方法去創建，同時，該型別 Element 都只有一個子節點 (single child)； 「Renderer Element」 —— 渲染型 Element，對應「Renderer Widget」，其不同的子型別包含的子節點個數也不一樣，

RenderObject

官方檔案中有一段話

//In Android, the View is the foundation of everything that shows up on the screen. Buttons, toolbars, and
//inputs, everything is a View. In Flutter, the rough equivalent to a View is a Widget. Widgets don’t map 
//exactly to Android views, but while you’re getting acquainted with how Flutter works you can think of them 
//as “the way you declare and construct UI”.

意思是，Widget 可以粗糙地看做 Android 中的 View，因為他們都可以描述 UI，但準確來說他們是不相等的，

實際上，RenderObject 更像是 Android 中的 View， RenderObject 是實際用來參與繪制的物件，它有和 View 類似的Layout Paint Composite 渲染流程，包括很多方法也一致，

當然，RenderObject 也只是抽象類，描述了渲染的基本協議，一些具體的實作比如坐標系都沒有定義， Flutter 原生提供的實作是 RenderBox ，大部分 widgets 都是基于它實作的，

渲染程序

構建 Widgets

首先觀察以下的代碼片段，它代表了一個簡單的 widget 結構：

Container(
  color: Colors.blue,
  child: Row(
    children: [
      Image.network('https://www.example.com/1.png'),
      Text('A'),
    ],
  ),
);

當 Flutter 需要繪制這段代碼片段時，框架會呼叫 build() 方法，回傳一棵基于當前應用狀態來繪制 UI 的 widget 子樹，在這個程序中，build() 方法可能會在必要時，根據狀態引入新的 widget，在上面的例子中，Container 的 color 和 child 就是典型的例子，我們可以查看 Container 的 源代碼，你會看到當 color 屬性不為空時，ColoredBox 會被加入用于顏色布局，

if (color != null)
  current = ColoredBox(color: color!, child: current);

與之對應的，Image 和 Text 在構建程序中也會引入 RawImage 和 RichText，如此一來，最終生成的 widget 結構比代碼表示的層級更深，在該場景中如下圖2：

這就是為什么你在使用 Dart DevTools 的 Flutter inspector 除錯 widget 樹結構時，會發現實際的結構比你原本代碼中的結構層級更深，

從 Widget 到 Element

在構建的階段，Flutter 會將代碼中描述的 widgets 轉換成對應的 Element 樹，每一個 Widget 都有一個對應的 Element，每一個 Element 代表了樹狀層級結構中特定位置的 widget 實體，目前有兩種 Element 的基本型別：

• ComponentElement，其他 Element 的宿主，

• RenderObjectElement，參與布局或繪制階段的 Element，

RenderObjectElement 是底層 RenderObject 與對應的 widget 之間的橋梁，

任何 widget 都可以通過其 BuildContext 參考到 Element，它是該 widget 在樹中的位置的背景關系，類似 Theme.of(context) 方法呼叫中的 context，它作為 build() 方法的引數被傳遞，

由于 widgets 以及它上下節點的關系都是不可變的，因此，對 widget 樹做的任何操作（例如將 Text(‘A’) 替換成 Text(‘B’)）都會回傳一個新的 widget 物件集合，但這并不意味著底層呈現的內容必須要重新構建， Element 樹每一幀之間都是持久化的，因此起著至關重要的性能作用， Flutter 依靠該優勢，實作了一種好似 widget 樹被完全拋棄，而快取了底層表示的機制， Flutter 可以根據發生變化的 widget，來重建需要重新配置的 Element 樹的部分，

布局和渲染

很少有應用只繪制單個 widget，因此，有效地排布 widget 的結構及在渲染完成前決定每個 Element 的大小和位置，是所有 UI 框架的重點之一，

在渲染樹中，每個節點的基類都是 RenderObject，該基類為布局和繪制定義了一個抽象模型，這是再平凡不過的事情：它并不總是一個固定的大小，甚至不遵循笛卡爾坐標規律（根據該 極坐標系的示例 所示），每一個 RenderObject 都了解其父節點的資訊，但對于其子節點，除了如何 訪問 和獲得他們的布局約束，并沒有更多的資訊，這樣的設計讓 RenderObject 擁有高效的抽象能力，能夠處理各種各樣的使用場景，

在構建階段，Flutter 會為 Element 樹中的每個 RenderObjectElement 創建或更新其對應的一個從 RenderObject 繼承的物件， RenderObject 實際上是原語：渲染文字的 RenderParagraph、渲染圖片的 RenderImage 以及在繪制子節點內容前應用變換的 RenderTransform 是更為上層的實作，

更新 UI

上面介紹了 Flutter 在 Framework 級別渲染的流程（后續交給影像引擎），這只是一幀的流程，Flutter 在更新 UI 上也有一些不同，

更新 Widget Tree

之前提到了 Widget 的不可變性，所以每一幀都會呼叫 build()方法回傳 widget 樹，即使是 StatefulWidget ,也只是根據不同的狀態回傳不同的 widget 樹 ，但這樣的話理論上會有大量的實體的產生和銷毀，頻繁 GC， 不過實際上，上面提到了 Widget 只是 UI 的配置，不負責實際的渲染，開銷并沒有那么大，

更新 Element Tree

更重量級的 Element Tree 并不會全部重新渲染，而是根據 Widget Tree 的變化維護 Element Tree （插入、洗掉、更新、移動…），其中核心的幾個方法包括:

1.Element 呼叫 Widget.canUpdate()，去判斷新的 widget 是否能用于更新 Element，

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

2.可以更新的話呼叫 Element.update() Element.updateChild() …

//繼承類自行實作
@mustCallSuper
void update(covariant Widget newWidget) {
  _widget = newWidget;
}

//framework.dart
 @protected
  Element updateChild(Element child, Widget newWidget, dynamic newSlot) {
    if (newWidget == null) {
      if (child != null)
        deactivateChild(child);
      return null;
    }
    Element newChild;
    if (child != null) {
      assert(() {
        final int oldElementClass = Element._debugConcreteSubtype(child);
        final int newWidgetClass = Widget._debugConcreteSubtype(newWidget);
        hasSameSuperclass = oldElementClass == newWidgetClass;
        return true;
      }());
      if (hasSameSuperclass && child.widget == newWidget) {
        if (child.slot != newSlot)
          updateSlotForChild(child, newSlot);
        newChild = child;
      } else if (hasSameSuperclass && Widget.canUpdate(child.widget, newWidget)) {
        if (child.slot != newSlot)
          updateSlotForChild(child, newSlot);
        child.update(newWidget);
        assert(child.widget == newWidget);
        assert(() {
          child.owner._debugElementWasRebuilt(child);
          return true;
        }());
        newChild = child;
      } else {
        deactivateChild(child);
        assert(child._parent == null);
        newChild = inflateWidget(newWidget, newSlot);
      }
    } else {
      newChild = inflateWidget(newWidget, newSlot);
    }

    assert(() {
      if (child != null)
        _debugRemoveGlobalKeyReservation(child);
      final Key key = newWidget?.key;
      if (key is GlobalKey) {
        key._debugReserveFor(this, newChild);
      }
      return true;
    }());

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

• newWidget == null —— 說明子節點對應的 Widget 已被移除，直接 remove child element (如有)；
• child == null —— 說明 newWidget 是新插入的，創建子節點 (inflateWidget)；
• child != null —— 此時，分為 3 種情況：
  • 若 child.widget == newWidget，說明 child.widget 前后沒有變化，若 child.slot != newSlot 表明子節點在兄弟結點間移動了位置，通過updateSlotForChild修改 child.slot 即可；
  • 通過Widget.canUpdate判斷是否可以用 newWidget 修改 child element，若可以，則呼叫update方法；
  • 否則先將 child element 移除，并通 newWidget 創建新的 element 子節點，

更新 RenderObject Tree

…

Dart VM

DartVM 的記憶體回識訓制采用多生代無鎖垃圾回收器，專門為UI框架中常見的大量Widgets物件創建和銷毀優化， 基本的流程： DartVM的記憶體分配策略非常簡單，創建物件時只需要在現有堆上移動指標，記憶體增長始終是線形的，省去了查找可用記憶體段的程序：

Dart中類似執行緒的概念叫做Isolate，每個Isolate之間是無法共享記憶體的，所以這種分配策略可以讓Dart實作無鎖的快速分配， Dart的垃圾回收也采用了多生代演算法，新生代在回收記憶體時采用了“半空間”演算法，觸發垃圾回收時Dart會將當前半空間中的“活躍”物件拷貝到備用空間，然后整體釋放當前空間的所有記憶體：

整個程序中Dart只需要操作少量的“活躍”物件，大量的沒有參考的“死亡”物件則被忽略，這種演算法也非常適合Flutter框架中大量Widget重建的場景，