這是我參與8月更文挑戰的第1天，活動詳情檢視： 8月更文挑戰

Flutter 系列文章連載～

• 《Flutter Android 工程結構及應用層編譯原始碼深入分析》

• 《Flutter 命令本質之 Flutter tools 機制原始碼深入分析》

• 《Flutter 的 runApp 與三棵樹誕生流程原始碼分析》

• 《Flutter Android 端 Activity/Fragment 流程原始碼分析》

背景

從寫 Flutter 第一行程式開始我們就知道在 Dart 的 main 方法中通過呼叫 runApp 方法把自己編寫的 Widget 傳遞進去，只有這樣編譯執行後才能得到預期效果。你有沒有好奇這背後都經歷了什麼？runApp 為什麼這麼神祕？或者說，在你入門 Flutter 後應該經常聽到或看到過 Flutter 三棵樹核心機制的東西，你有真正的想過他們都是什麼嗎？如果都沒有，那麼本文就是一場解密之旅。

Flutter 程式入口

我們編寫的 Flutter App 一般入口都是在 main 方法，其內部通過呼叫 runApp 方法將我們自己整個應用的 Widget 新增並執行，所以我們直接去看下 runApp 方法實現，如下：

/**
 * 位置：FLUTTER_SDK\packages\flutter\lib\src\widgets\binding.dart
 * 注意：app引數的Widget佈局盒子約束constraints會被強制為填充螢幕，這是框架機制，自己想要調整可以用Align等包裹。
 * 多次重複呼叫runApp將會從螢幕上移除已新增的app Widget並新增新的上去，
 * 框架會對新的Widget樹與之前的Widget樹進行比較，並將任何差異應用於底層渲染樹，有點類似於StatefulWidget
呼叫State.setState後的重建機制。
 */
void runApp(Widget app) {
  WidgetsFlutterBinding.ensureInitialized()
    ..scheduleAttachRootWidget(app)
    ..scheduleWarmUpFrame();
}
複製程式碼

可以看到上面三行程式碼代表了 Flutter 啟動的核心三步（級聯運算子呼叫）：

1. WidgetsFlutterBinding 初始化（ensureInitialized()）
2. 繫結根節點建立核心三棵樹（scheduleAttachRootWidget(app)）
3. 繪製熱身幀（scheduleWarmUpFrame()）

WidgetsFlutterBinding 例項及初始化

直接看原始碼，如下：

class WidgetsFlutterBinding extends BindingBase with GestureBinding, SchedulerBinding, ServicesBinding, PaintingBinding, SemanticsBinding, RendererBinding, WidgetsBinding {
  static WidgetsBinding ensureInitialized() {
    if (WidgetsBinding.instance == null)
      WidgetsFlutterBinding();
    return WidgetsBinding.instance!;
  }
}
複製程式碼

WidgetsFlutterBinding 繼承自 BindingBase，並且 with 了大量的 mixin 類。WidgetsFlutterBinding 就是將 Widget 架構和 Flutter Engine 連線的核心橋樑，也是整個 Flutter 的應用層核心。通過 ensureInitialized() 方法我們可以得到一個全域性單例的 WidgetsFlutterBinding 例項，且 mixin 的一堆 XxxBinding 也被例項化。

BindingBase 抽象類的構造方法中會呼叫initInstances()方法，而各種 mixin 的 XxxBinding 例項化重點也都在各自的initInstances()方法中，每個 XxxBinding 的職責不同，如下：

• WidgetsFlutterBinding：核心橋樑主體，Flutter app 全域性唯一。
• BindingBase：繫結服務抽象類。
• GestureBinding：Flutter 手勢事件繫結，處理螢幕事件分發及事件回撥處理，其初始化方法中重點就是把事件處理回撥_handlePointerDataPacket函式賦值給 window 的屬性，以便 window 收到螢幕事件後呼叫，window 例項是 Framework 層與 Engine 層處理螢幕事件的橋樑。
• SchedulerBinding：Flutter 繪製排程器相關繫結類，debug 編譯模式時統計繪製流程時長等操作。
• ServicesBinding：Flutter 系統平臺訊息監聽繫結類。即 Platform 與 Flutter 層通訊相關服務，同時註冊監聽了應用的生命週期回撥。
• PaintingBinding：Flutter 繪製預熱快取等繫結類。
• SemanticsBinding：語義樹和 Flutter 引擎之間的粘合劑繫結類。
• RendererBinding：渲染樹和 Flutter 引擎之間的粘合劑繫結類，內部重點是持有了渲染樹的根節點。
• WidgetsBinding：Widget 樹和 Flutter 引擎之間的粘合劑繫結類。

從 Flutter 架構巨集觀抽象看，這些 XxxBinding 承擔的角色大致是一個橋樑關聯繫結，如下：

本文由於是啟動主流程相關機制分析，所以初始化中我們需要關注的主要是 RendererBinding 和 WidgetsBinding 類的initInstances()方法，如下：

mixin WidgetsBinding on BindingBase, ServicesBinding, SchedulerBinding, GestureBinding, RendererBinding, SemanticsBinding {
  @override
  void initInstances() {
    ......
    /**
     *1、建立一個管理Widgets的類物件
     *BuildOwner類用來跟蹤哪些Widget需要重建，並處理用於Widget樹的其他任務，例如管理不活躍的Widget等，除錯模式觸發重建等。
     */
    _buildOwner = BuildOwner();
    //2、回撥方法賦值，當第一個可構建元素被標記為髒時呼叫。
    buildOwner!.onBuildScheduled = _handleBuildScheduled;
    //3、回撥方法賦值，當本地配置變化或者AccessibilityFeatures變化時呼叫。
    window.onLocaleChanged = handleLocaleChanged;
    window.onAccessibilityFeaturesChanged = handleAccessibilityFeaturesChanged;
    ......
  }
}

mixin RendererBinding on BindingBase, ServicesBinding, SchedulerBinding, GestureBinding, SemanticsBinding, HitTestable {
  @override
  void initInstances() {
    ......
    /**
     * 4、建立管理rendering渲染管道的類
     * 提供介面呼叫用來觸發渲染。
     */
    _pipelineOwner = PipelineOwner(
      onNeedVisualUpdate: ensureVisualUpdate,
      onSemanticsOwnerCreated: _handleSemanticsOwnerCreated,
      onSemanticsOwnerDisposed: _handleSemanticsOwnerDisposed,
    );
    //5、一堆window變化相關的回撥監聽
    window
      ..onMetricsChanged = handleMetricsChanged
      ..onTextScaleFactorChanged = handleTextScaleFactorChanged
      ..onPlatformBrightnessChanged = handlePlatformBrightnessChanged
      ..onSemanticsEnabledChanged = _handleSemanticsEnabledChanged
      ..onSemanticsAction = _handleSemanticsAction;
    //6、建立RenderView物件，也就是RenderObject渲染樹的根節點
    initRenderView();
    ......
  }

  void initRenderView() {
    ......
    //RenderView extends RenderObject with RenderObjectWithChildMixin<RenderBox>
    //7、渲染樹的根節點物件
    renderView = RenderView(configuration: createViewConfiguration(), window: window);
    renderView.prepareInitialFrame();
  }
  //定義renderView的get方法，獲取自_pipelineOwner.rootNode
  RenderView get renderView => _pipelineOwner.rootNode! as RenderView;
  //定義renderView的set方法，上面initRenderView()中例項化賦值就等於給_pipelineOwner.rootNode也進行了賦值操作。
  set renderView(RenderView value) {
    assert(value != null);
    _pipelineOwner.rootNode = value;
  }
}
複製程式碼

到此基於初始化過程我們已經得到了一些重要資訊，請記住 RendererBinding 中的 RenderView 就是 RenderObject 渲染樹的根節點。上面這部分程式碼的時序圖大致如下：

通過 scheduleAttachRootWidget 建立關聯三棵核心樹

WidgetsFlutterBinding 例項化單例初始化之後先呼叫了scheduleAttachRootWidget(app)方法，這個方法位於 mixin 的 WidgetsBinding 類中，本質是非同步執行了attachRootWidget(rootWidget)方法，這個方法完成了 Flutter Widget 到 Element 到 RenderObject 的整個關聯過程。原始碼如下：

mixin WidgetsBinding on BindingBase, ServicesBinding, SchedulerBinding, GestureBinding, RendererBinding, SemanticsBinding {
  @protected
  void scheduleAttachRootWidget(Widget rootWidget) {
  	//簡單的非同步快速執行，將attachRootWidget非同步化
    Timer.run(() {
      attachRootWidget(rootWidget);
    });
  }

  void attachRootWidget(Widget rootWidget) {
  	//1、是不是啟動幀，即看renderViewElement是否有賦值，賦值時機為步驟2
    final bool isBootstrapFrame = renderViewElement == null;
    _readyToProduceFrames = true;
    //2、橋樑建立RenderObject、Element、Widget關係樹，_renderViewElement值為attachToRenderTree方法返回值
    _renderViewElement = RenderObjectToWidgetAdapter<RenderBox>(
      //3、RenderObjectWithChildMixin型別，繼承自RenderObject，RenderObject繼承自AbstractNode。
      //來自RendererBinding的_pipelineOwner.rootNode，_pipelineOwner來自其初始化initInstances方法例項化的PipelineOwner物件。
      //一個Flutter App全域性只有一個PipelineOwner例項。
      container: renderView, 
      debugShortDescription: '[root]',
      //4、我們平時寫的dart Widget app
      child: rootWidget,
    //5、attach過程，buildOwner來自WidgetsBinding初始化時例項化的BuildOwner例項，renderViewElement值就是_renderViewElement自己，此時由於呼叫完appach才賦值，所以首次進來也是null。
    ).attachToRenderTree(buildOwner!, renderViewElement as RenderObjectToWidgetElement<RenderBox>?);
    if (isBootstrapFrame) {
      //6、首幀主動更新一下，匹配條件的情況下內部本質是呼叫SchedulerBinding的scheduleFrame()方法。
      //進而本質呼叫了window.scheduleFrame()方法。
      SchedulerBinding.instance!.ensureVisualUpdate();
    }
  }
}
複製程式碼

上面程式碼片段的步驟 2 和步驟 5 需要配合 RenderObjectToWidgetAdapter 類片段檢視，如下：

//1、RenderObjectToWidgetAdapter繼承自RenderObjectWidget，RenderObjectWidget繼承自Widget
class RenderObjectToWidgetAdapter<T extends RenderObject> extends RenderObjectWidget {
  ......
  //3、我們編寫dart的runApp函式引數中傳遞的Flutter應用Widget樹根
  final Widget? child;
  //4、繼承自RenderObject，來自PipelineOwner物件的rootNode屬性，一個Flutter App全域性只有一個PipelineOwner例項。
  final RenderObjectWithChildMixin<T> container;
  ......
  //5、重寫Widget的createElement實現，構建了一個RenderObjectToWidgetElement例項，它繼承於Element。	     		
  //Element樹的根結點是RenderObjectToWidgetElement。
  @override
  RenderObjectToWidgetElement<T> createElement() => RenderObjectToWidgetElement<T>(this);
  //6、重寫Widget的createRenderObject實現，container本質是一個RenderView。
  //RenderObject樹的根結點是RenderView。
  @override
  RenderObjectWithChildMixin<T> createRenderObject(BuildContext context) => container;

  @override
  void updateRenderObject(BuildContext context, RenderObject renderObject) { }

  /**
   *7、上面程式碼片段中RenderObjectToWidgetAdapter例項建立後呼叫
   *owner來自WidgetsBinding初始化時例項化的BuildOwner例項，element 值就是自己。
   *該方法建立根Element(RenderObjectToWidgetElement)，並將Element與Widget進行關聯，即建立WidgetTree對應的ElementTree。
   *如果Element已經建立過則將根Element中關聯的Widget設為新的(即_newWidget)。
   *可以看見Element只會建立一次，後面都是直接複用的。
   */
  RenderObjectToWidgetElement<T> attachToRenderTree(BuildOwner owner, [ RenderObjectToWidgetElement<T>? element ]) {
    //8、由於首次例項化RenderObjectToWidgetAdapter呼叫attachToRenderTree後才不為null，所以當前流程為null
    if (element == null) {
      //9、在lockState裡面程式碼執行過程中禁止呼叫setState方法
      owner.lockState(() {
        //10、建立一個Element例項，即呼叫本段程式碼片段中步驟5的方法。
        //呼叫RenderObjectToWidgetAdapter的createElement方法構建了一個RenderObjectToWidgetElement例項，繼承RootRenderObjectElement，又繼續繼承RenderObjectElement，接著繼承Element。
        element = createElement();
        assert(element != null);
        //11、給根Element的owner屬性賦值為WidgetsBinding初始化時例項化的BuildOwner例項。
        element!.assignOwner(owner);
      });
      //12、重點！mount裡面RenderObject 
      owner.buildScope(element!, () {
        element!.mount(null, null);
      });
    } else {
      //13、更新widget樹時_newWidget賦值為新的，然後element數根標記為markNeedsBuild
      element._newWidget = this;
      element.markNeedsBuild();
    }
    return element!;
  }
  ......
}
複製程式碼

對於上面步驟 12 我們先進去簡單看下 Element （RenderObjectToWidgetElement extends RootRenderObjectElement extends RenderObjectElement extends Element）的 mount 方法，重點關注的是父類 RenderObjectElement 中的 mount 方法，如下：

abstract class RenderObjectElement extends Element {
  //1、Element樹通過構造方法RenderObjectToWidgetElement持有了Widget樹例項。（RenderObjectToWidgetAdapter）。
  @override
  RenderObjectWidget get widget => super.widget as RenderObjectWidget;

  //2、Element樹通過mount後持有了RenderObject渲染樹例項。
  @override
  RenderObject get renderObject => _renderObject!;
  RenderObject? _renderObject;

  @override
  void mount(Element? parent, Object? newSlot) {
    ......
    //3、通過widget樹（即RenderObjectToWidgetAdapter）呼叫createRenderObject方法傳入Element例項自己獲取RenderObject渲染樹。
    //RenderObjectToWidgetAdapter.createRenderObject(this)返回的是RenderObjectToWidgetAdapter的container成員，也就是上面分析的RenderView渲染樹根節點。
    _renderObject = widget.createRenderObject(this);
    ......
  }
}
複製程式碼

到這裡對於 Flutter 的靈魂“三棵樹”來說也能得出如下結論：

• Widget 樹的根結點是 RenderObjectToWidgetAdapter（繼承自 RenderObjectWidget extends Widget），我們 runApp 中傳遞的 Widget 樹就被追加到了這個樹根的 child 屬性上。
• Element 樹的根結點是 RenderObjectToWidgetElement（繼承自 RootRenderObjectElement extends RenderObjectElement extends Element），通過呼叫 RenderObjectToWidgetAdapter 的 createElement 方法建立，建立 RenderObjectToWidgetElement 的時候把 RenderObjectToWidgetAdapter 通過構造引數傳遞進去，所以 Element 的 _widget 屬性值為 RenderObjectToWidgetAdapter 例項，也就是說 Element 樹中 _widget 屬性持有了 Widget 樹例項。RenderObjectToWidgetAdapter 。
• RenderObject 樹的根結點是 RenderView（RenderView extends RenderObject with RenderObjectWithChildMixin<RenderBox>），在 Element 進行 mount 時通過呼叫 Widget 樹（RenderObjectToWidgetAdapter）的createRenderObject方法獲取 RenderObjectToWidgetAdapter 構造例項化時傳入的 RenderView 渲染樹根節點。

上面程式碼流程對應的時序圖大致如下： 結合上一小結可以很容易看出來三棵樹的建立時機（時序圖中紫紅色節點），也可以很容易看出來 Element 是 Widget 和 RenderObject 之前的一個“橋樑”，其內部持有了兩者樹根，抽象表示如下：

由於篇幅和本文主題原因，我們重心關注三棵樹的誕生流程，對於三棵樹之間如何配合進行繪製渲染這裡先不展開，後面會專門一篇分析。

熱身幀繪製

到此讓我們先將目光再回到一開始runApp方法的實現中，我們還差整個方法實現中的最後一個scheduleWarmUpFrame()呼叫，如下：

mixin SchedulerBinding on BindingBase {
  void scheduleWarmUpFrame() {
    ......
    Timer.run(() {
      assert(_warmUpFrame);
      handleBeginFrame(null);
    });
    Timer.run(() {
      assert(_warmUpFrame);
      handleDrawFrame();
      //重置時間戳，避免熱過載情況從熱身幀到熱過載幀的時間差，導致隱式動畫的跳幀情況。
      resetEpoch();
      ......
      if (hadScheduledFrame)
        scheduleFrame();
    });
	//在此次繪製結束前該方法會鎖定事件分發，可保證繪製過程中不會再觸發新重繪。
	//也就是說在本次繪製結束前不會響應各種事件。
    lockEvents(() async {
      await endOfFrame;
      Timeline.finishSync();
    });
  }
}
複製程式碼

這段程式碼的本質這裡先不詳細展開，因為本質就是渲染幀的提交與觸發相關，我們後邊文章會詳細分析 framework 層繪製渲染相關邏輯，那時再展開。在這裡只用知道它被呼叫後會立即執行一次繪製（不用等待 VSYNC 訊號到來）。

這時候細心的話，你可能會有疑問，前面分析 attachRootWidget 方法呼叫時，它的最後一行發現是啟動幀則會呼叫window.scheduleFrame()然後等系統 VSYNC 訊號到來觸發繪製，既然 VSYNC 訊號到來時會觸發繪製，這個主動熱身幀豈不是可以不要？

是的，不要也是沒問題的，只是體驗不是很好，會導致初始化卡幀的效果。因為前面window.scheduleFrame()發起的繪製請求是在收到系統 VSYNC 訊號後才真正執行，而 Flutter app 初始化時為了儘快呈現 UI 而沒有等待系統 VSYNC 訊號到來就主動發起一針繪製（也被形象的叫做熱身幀），這樣最長可以減少一個 VSYNC 等待時間。

總結

上面就是 Flutter Dart 端三棵樹的誕生流程，關於三棵樹是如何互相工作的，我們會在後面專門篇章做分析，這裡就先不展開了。