紛爭再起：Flutter-UI繪製解析

爲避免傳統的源碼講解方式的枯燥乏味，這一次，我嘗試換一種方式，帶着你以輕鬆的心態瞭解Flutter世界裏的UI繪製流程，去探究Widget、Element、RenderObject的祕密。

廢話不多說，聽故事！《紛爭再起》

故事

十載干戈，移動端格局漸定，壁壘分明。

北方草原金帳王朝Javascript雖內部紛爭不斷，但卻一直窺視中原大陸，數年來襲擾不斷，如今已奪得小片領土(ReactNative)。民間盛傳：大前端融合之勢已現！

2018年冬，Android邊境小城Flutter突然宣佈立國！並對兩個移動端帝國正式宣戰！！短短几日，已攻下數城。

而今天我們要講的故事，就發生在戰火最嚴重的Android邊陲重鎮：View城。

某日，Android View 城軍事會議：

鎮邊大將軍對手下謀士道：“Flutter 最近對我們發起了數次進攻，已下數城，知己不知彼乃軍家大忌！誰能給我說說這個Flutter和我們現在的View到底有什麼區別？”

下方謀士面面相窺，不得已終於一個謀士站了出來：“我願意替將軍前去打探一番！”

數日後，謀士：“臣臥底歸來，探明Flutter與我們View城的主要區別在於編程範式和視圖邏輯單元不同”

將軍：“先講編程範式如何不同？”

Android/Flutter 編程範式

將軍，我們Android現在視圖開發是命令式的，我們的每一個View都直接聽從將軍(Developer)的指揮，例如：想要變更界面某個文案，便要指明具體TextView調用他的setText方法命令文字發生變更；

而Flutter的視圖開發是聲明式的，對方的將軍要做的是維護一套數據集,以及設定好一套布軍計劃（WidgetTree），並且爲Widget“綁定”數據集中的某個數據，根據這個數據來渲染。例如當需要變更文案時，便改變數據集中的數據，然後直接觸發WidgetTree的重新渲染。這樣Flutter的將軍不再需要關注每一個士兵，大部分的精力都用來維護核心數據即可。

如果每一次操作都消耗一點將軍的精力值，又剛好有同一個數據“綁定”到了多個View或Widget上。命令式的編程需要做的事情是命令N個View發生變更，消耗N點精力值；

聲明式編程需要做的事情是變更數據+觸發WidgetTree重繪,消耗2點精力值；對精力的解放，也是Flutter可以快速招攬到那麼多將軍的原因之一。

將軍：”但每次數據變更，都會觸發WidgetTree的重繪，消耗的資源未免也太大了吧，我現在雖然多消耗些精力，但不會存在大量對象創建的情況“。

Widget、Element、RenderObject概念

謀士：這也是馬上要講的第二點不同。因爲WidgetTree會大量的重繪，所以Widget必然是廉價的。

Flutter UI有三大元素：Widget、Element、RenderObject。對應這三者也有三個owner負責管理他們，分別是WidgetOwner(將軍&Developer)、BuildOwner、PipelineOwner。

Widget，Widget 並不是真正的士兵，它只是將軍手中的棋子，是一些廉價的純對象，持有一些渲染需要的配置信息，棋子在不斷被替換着。
RenderObject，RenderObject 是真正和我們作戰的士兵，在概念上和我們Android的View一樣，渲染引擎會根據RenderObject來進行真正的繪製，它是相對穩定且昂貴的。
Element，使得不斷變化Widget轉變爲相對穩定的RenderObject的功臣是Element。

WidgetOwner（Developer) 在不斷改變着布軍計劃，然後向BuildOwner發送着一張又一張計劃表（WidgetTree），首次的計劃表（WidgetTree）會生成一個與之對應的ElementTree，並生成對應的RenderObjectTree。

後續BuildOwner每次收到新的計劃表就與上一次的進行對比，在ElementTree上只更新變化的部分，Element有可能僅是update一下，也有可能會被替換，Element被替換之後，與之對應的RenderObject也就被替換了。

可以看到WidgetTree全部被替換了，但ElementTree和RenderObjectTree只替換了變化的部分。

差點忘了講 PipelineOwner， PipelineOwner類似於Android中的ViewRootImpl,管理着真正需要繪製的View，最後PipelineOwner會對RenderObjectTree中發生變化節點的進行flush操作，最後交給底層引擎渲染。

將軍：“我大概明白了，看來保證聲明式編程性能穩定的核心在於這個Element和BuildOwner。但我看這裏還有兩個問題，RenderObject好像少了一個節點？你畫圖畫錯了嗎？還有能給我講下他是怎麼把Widget和RenderObject鏈接起來，以及發生變化時，BuildOwner是如何做到元素Diff的嗎？”

Widget、Element、RenderObject之間的關係

首先，每一個Widget家族的老長輩Widget賦予了所有的Widget子類三個關鍵的能力：保證自身唯一以及定位的Key, 創建Element的 createElement, 和 canUpdate。 canUpdate 的作用後面講。

Widget子類裏還有一批特別優秀強壯的，是在紙面上代表着有渲染能力的RenderObjectWidget,它還有一個創建 RenderObject的 createRenderObject 方法。

從這裏你也看出來了，Widget、Element、RenderObject的創建關係並不是線性傳遞的，Element和RenderObject都是Widget創建出來的，也並不是每一個Widget都有與之對應的RenderObjectWidget。這也解釋上面圖中RenderObjectTree看起來和前面的WidgetTree缺少了一些節點。

Widget、Element、RenderObject 的第一次創建與關聯

講第一次創建，一定要從第一個被創建出來的士兵說起。我們都知道Android的ViewTree:

-PhoneWindow
    - DecorView
        - TitleView
        - ContentView

已經預先有這麼多View了，相比Android的ViewTree，Flutter的WidgetTree則要簡單的多，只有最底層的root widget。

- RenderObjectToWidgetAdapter<RenderBox>
    - MyApp (自定義)
    - MyMaterialApp （自定義）

簡單介紹一下RenderObjectToWidgetAdapter，不要被他的adapter名字迷惑了，RenderObjectToWidgetAdapter其實是一個RenderObjectWidget，他就是第一個優秀且強壯的Widget。

這個時候就不得不搬出代碼來看了,runApp源碼：

void runApp(Widget app) {
  WidgetsFlutterBinding.ensureInitialized()
    ..attachRootWidget(app)
    ..scheduleWarmUpFrame();
}

WidgetsFlutterBinding ”迷信“了一系列的Binding，這些Binding持有了我們上面說的一些owner，比如BuildOwner，PipelineOwner，所以隨着WidgetsFlutterBinding的初始化，其他的Binding也被初始化了，此時Flutter 的國家引擎開始轉動了！

void attachRootWidget(Widget rootWidget) {
    _renderViewElement = RenderObjectToWidgetAdapter<RenderBox>(
      container: renderView,
      debugShortDescription: '[root]',
      child: rootWidget
    ).attachToRenderTree(buildOwner, renderViewElement);
  }

我們最需要關注的是attachRootWidget(app)這個方法,這個方法很神聖，很多的第一次就在這個方法裏實現了！！（將軍：“很神聖？你是不叛變了？”），app 是我們傳入的自定義Widget，內部會創建RenderObjectToWidgetAdapter，並將app做爲它的child的。

緊接着又執行了attachToRenderTree,這個方法,這個方法也很神聖，創建了第一個Element和RenderObject

RenderObjectToWidgetElement<T> attachToRenderTree(BuildOwner owner, [RenderObjectToWidgetElement<T> element]) {
    if (element == null) {
      owner.lockState(() {
        element = createElement();  //創建rootElement
        element.assignOwner(owner); //綁定BuildOwner
      });
      owner.buildScope(element, () { //子widget的初始化從這裏開始
        element.mount(null, null);  // 初始化子Widget前，先執行rootElement的mount方法
      });
    } else {
      ...
    }
    return element;
  }

我們解釋一下上面的圖片，Root的創建比較簡單：

1.attachRootWidget(app) 方法創建了Root[Widget]（也就是 RenderObjectToWidgetAdapter）
2.緊接着調用attachToRenderTree方法創建了 Root[Element]
3.Root[Element]嘗試調用mount方法將自己掛載到父Element上，因爲自己就是root了，所以沒有父Element，掛空了
4.mount的過程中會調用Widget的createRenderObject,創建了 Root[RenderObject]

它的child，也就是我們傳入的app是怎麼掛載父控件上的呢？

5.我們將app作爲參數傳給了Root[Widget]（也就是 RenderObjectToWidgetAdapter），app[Widget]也就成了爲root[Widget]的child[Widget]
6.調用owner.buildScope，開始執行子Tree的創建以及掛載，敲黑板！！！這中間的流程和WidgetTree的刷新流程是一模一樣的，詳細流程我們後面講！
7.調用createElement方法創建出Child[Element]
8.調用Element的mount方法,將自己掛載到Root[Element]上，形成一棵樹
9.掛載的同時，調用widget.createRenderObject,創建Child[RenderObject]
10.創建完成後，調用attachRenderObject,完成和Root[RenderObject]的鏈接

就這樣，WidgetTree、ElementTree、RenderObject創建完成，並有各自的鏈接關係。

將軍：“我想看一下這個mount和attachRenderObject的過程,看下到底是怎麼掛上去的”

abstract class Element：

void mount(Element parent, dynamic newSlot) {
    _parent = parent; //持有父Element的引用
    _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; //每個Element的buildOwner，都來自父類的BuildOwner
    ...
  }

我們先看一下Element的掛載，就是讓_parent持有父Element的引用，很簡單對不對~

因爲RootElement 是沒有父Element的，所以參數傳了null：element.mount(null, null);

還有兩個值得注意的地方：

節點的深度_depth 也是在這個時候計算的，深度對刷新很重要！先記下！
每個Element的buildOwner，都來自父類的BuildOwner，這樣可以保證一個ElementTree,只由一個BuildOwner來維護。

abstract class RenderObjectElement:

@override
  void attachRenderObject(dynamic newSlot) {
    ...
    _ancestorRenderObjectElement = _findAncestorRenderObjectElement();
    _ancestorRenderObjectElement?.insertChildRenderObject(renderObject, newSlot);
    ...
  }

RenderObject與父RenderObject的掛載稍微複雜了點。通過代碼我們可以看到需要先查詢一下自己的AncestorRenderObject,這是爲什麼呢？

還記得之前我們講過，每一個Widget都有一個對應的Element，但Element不一定會有對應的RenderObject。所以你的父Element並不一有RenderObject，這個時候就需要向上查找。

RenderObjectElement _findAncestorRenderObjectElement() {
    Element ancestor = _parent;
    while (ancestor != null && ancestor is! RenderObjectElement)
      ancestor = ancestor._parent;
    return ancestor;
  }

通過代碼我們也可以看到，find方法在向上遍歷Element，直到找到RenderObjectElement，RenderObjectElement肯定是有對應的RenderObject了，這個時候在進行RenderObject子父間的掛載。

Flutter的刷新流程：Element的複用

通過前面的瞭解，我們知道了雖然createRenderObject方法的實現是在Widget當中，但持有RenderObject引用的卻是Element。忘記啦？那我們再看看代碼：

abstract class RenderObjectElement extends Element {
    ...

  @override
  RenderObjectWidget get widget => super.widget;

  @override
  RenderObject get renderObject => _renderObject;
  RenderObject _renderObject;
}

Element同時持有兩者，可以說，element就是Widget 和 RenderObject的中間商，它也確實在賺差價……

這個時候Root Widget，Root Element，Root RenderObject都已經創建完成並且三者鏈接成功。將軍您看還有什麼問題嗎？

將軍：“Flutter內部還有中間商賺差價呢？真腐敗！誒你說說他是怎麼賺差價的啊？說不定我也可以學學~”

Flutter如果想要刷新界面，需要在StatefulWidget裏調用setState()方法，setState()幹啥了呢？

@protected
void setState(VoidCallback fn) {
    ...
    _element.markNeedsBuild();
}

將軍我們實際演練一下，假設Flutter派出了這麼一個WidgetTree:

刷新第1步：Element標記自身爲dirty，並通知buildOwner處理

當對方想改變下方Text Widget的文案時，會在StatefulWidget內部調用setState((){_title="ttt"}) ，之後該widget對應的element將自身標記爲dirty狀態,並調用owner.scheduleBuildFor(this);通知buildOwner進行處理。

後續StatefulWidget的build方法一定會被執行，執行後，會創建新的子Widget出來，原來的子Widget便被拋棄掉了（將軍：“好好的一個對象就這麼被浪費了，哎……現在的年輕人~”）。

原來的子Widget肯定是沒救了，但他們的Element大概率還是有救的。

刷新第2步：buildOwner將element添加到集合_dirtyElements中，並通知ui.window安排新的一幀

buildOwner會將所有dirty的Element添加到_dirtyElements當中，等待下一幀繪製時集中處理。

還會調用ui.window.scheduleFrame();通知底層渲染引擎安排新的一幀處理。

刷新第3步：底層引擎最終回調到Dart層，並執行buildOwner的buildScope方法

這裏很重要，所以用代碼講更清晰！

void buildScope(Element context, [VoidCallback callback]){
    ...
}

buildScope!! 還記的嗎？前面講Root創建的時候，我們就看到了Child的初次創建也是調用的buildScope方法!Tree的首幀創建和刷新是一套邏輯！

buildScope需要傳入一個Element的參數，這個方法通過字面意思我們應該能理解，大概就是對這個Element以下（包含）的範圍rebuild。

void buildScope(Element context, [VoidCallback callback]) {
    ...
    try {
        ...
        //1.排序
      _dirtyElements.sort(Element._sort);
        ...
      int dirtyCount = _dirtyElements.length;
      int index = 0;
      while (index < dirtyCount) {
        try {
            //2.遍歷rebuild
          _dirtyElements[index].rebuild();
        } catch (e, stack) {
        }
        index += 1;
      }
    } finally {
      for (Element element in _dirtyElements) {
        element._inDirtyList = false;
      }
      //3.清空
      _dirtyElements.clear();
        ...
    }
  }

3.1步：按照Element的深度從小到大，對_dirtyElements進行排序

爲啥要排序呢？因爲父Widget的build方法必然會觸發子Widget的build，如果先build了子Widget，後面再build父Widget時，子Widget又要被build一次。所以這樣排序之後，可以避免子Widget的重複build。

3.2步：遍歷執行_dirtyElements當中element的rebuild方法

值得一提的是，遍歷執行的過程中，也有可能會有新的element被加入到_dirtyElements集合中，此時會根據dirtyElements集合的長度判斷是否有新的元素進來了，如果有，就重新排序。

element的rebuild方法最終會調用performRebuild(),而performRebuild()不同的Element有不同的實現

3.3步：遍歷結束之後，清空dirtyElements集合

刷新第4步：執行performRebuild()

performRebuild()不同的Element有不同的實現，我們暫時只看最常用的兩個Element：

ComponentElement，是StatefulWidget和StatelessElement的父類
RenderObjectElement，是有渲染功能的Element的父類

ComponentElement的performRebuild()

void performRebuild() {
    Widget built;
    try {
      built = build();
    } 
    ...
    try {
      _child = updateChild(_child, built, slot);
    } 
    ...
  }

執行element的build();，以StatefulElement的build方法爲例：Widget build() => state.build(this);。就是執行了我們複寫的StatefulWidget的state的build方法啦~

執行build方法build出來的是啥呢? 當然就是這個StatefulWidget的子Widget了。重點來了！敲黑板！！（將軍：“又給我敲黑板？？”）Element就是在這個地方賺差價的！

Element updateChild(Element child, Widget newWidget, dynamic newSlot) {
    ...
        //1
    if (newWidget == null) {
      if (child != null)
        deactivateChild(child);
      return null;
    }

    if (child != null) {
        //2
      if (child.widget == newWidget) {
        if (child.slot != newSlot)
          updateSlotForChild(child, newSlot);
        return child;
      }
      //3
      if (Widget.canUpdate(child.widget, newWidget)) {
        if (child.slot != newSlot)
          updateSlotForChild(child, newSlot);
        child.update(newWidget);
        return child;
      }
      deactivateChild(child);
    }
    //4
    return inflateWidget(newWidget, newSlot);
  }

參數child 是上一次Element掛載的child Element, newWidget 是剛剛build出來的。updateChild有四種可能的情況：

1.如果剛build出來的widget等於null，說明這個控件被刪除了，child Element可以被刪除了。

2.如果child的widget和新build出來的一樣（Widget複用了），就看下位置一樣不，不一樣就更新下，一樣就直接return了。Element還是舊的Element
3.看下Widget是否可以update，Widget.canUpdate的邏輯是判斷key值和運行時類型是否相等。如果滿足條件的話，就更新，並返回。

中間商的差價哪來的呢？只要新build出來的Widget和上一次的類型和Key值相同，Element就會被複用！由此也就保證了雖然Widget在不停的新建，但只要不發生大的變化，那Element是相對穩定的，也就保證了RenderObject是穩定的！

4.如果上述三個條件都沒有滿足的話，就調用 inflateWidget() 創建新的Element

這裏再看下inflateWidget()方法：

Element inflateWidget(Widget newWidget, dynamic newSlot) {
    final Key key = newWidget.key;
    if (key is GlobalKey) {
      final Element newChild = _retakeInactiveElement(key, newWidget);
      if (newChild != null) {
        newChild._activateWithParent(this, newSlot);
        final Element updatedChild = updateChild(newChild, newWidget, newSlot);
        return updatedChild;
      }
    }
    final Element newChild = newWidget.createElement();
    newChild.mount(this, newSlot);
    return newChild;
  }

首先會嘗試通過GlobalKey去查找可複用的Element，複用失敗就調用Widget的方法創建新的Element，然後調用mount方法，將自己掛載到父Element上去，mount之前我們也講過，會在這個方法裏創建新的RenderObject。

RenderObjectElement的performRebuild()

@override
  void performRebuild() {
    widget.updateRenderObject(this, renderObject);
    _dirty = false;
  }

與ComponentElement的不同之處在於，沒有去build，而是調用了updateRenderObject方法更新RenderObject。

不同Widget也有不同的updateRenderObject實現，我們看一下最常用的RichText，也就是Text。

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
      ..textScaleFactor = textScaleFactor
      ..maxLines = maxLines
      ..locale = locale ?? Localizations.localeOf(context, nullOk: true);
  }

一些看起來比較熟悉的賦值操作，像不像Android的view呀？要不怎麼說RenderObject實際相當於Android裏的View呢。

到這裏你基本就明白了Element是如何在中間應對Widget的多變，保障RenderObject的相對不變了吧~

Flutter的刷新流程：PipelineOwner對RenderObject的管理

在底層引擎最終回到Dart層，最終會執行WidgetsBinding 的drawFrame ()

WidgetsBinding

void drawFrame() {
    try {
      if (renderViewElement != null)
        buildOwner.buildScope(renderViewElement);
      super.drawFrame();
      buildOwner.finalizeTree();
    } finally {
    }
    ...
}

buildOwner.buildScope(renderViewElement);就是我們上面講過的。

下面看一下super.drawFrame(); 主要是PipelineOwner對RenderObject的管理,我們簡單介紹，詳細的放在下期介紹。

@protected
  void drawFrame() {
    assert(renderView != null);
    pipelineOwner.flushLayout();  //佈局需要被佈局的RenderObject
    pipelineOwner.flushCompositingBits(); // 判斷layer是否變化
    pipelineOwner.flushPaint();  //繪製需要被繪製的RenderObject
    renderView.compositeFrame(); // this sends the bits to the GPU 將畫好的layer傳給engine繪製
    pipelineOwner.flushSemantics(); // this also sends the semantics to the OS. 一些語義場景需要
  }

Flutter的刷新流程：清理

drawFrame方法在最後執行了buildOwner.finalizeTree();

void finalizeTree() {
    Timeline.startSync('Finalize tree', arguments: timelineWhitelistArguments);
    try {
      lockState(() {
        _inactiveElements._unmountAll(); // this unregisters the GlobalKeys
      });
     ...
    } catch (e, stack) {
      _debugReportException('while finalizing the widget tree', e, stack);
    } finally {
      Timeline.finishSync();
    }
  }

在做最後的清理工作。

將軍：“_inactiveElements”又是個啥？之前咋沒見過？

還記的前面講Element賺差價的updateChild方法嗎？所有沒用的element都調用了deactivateChild方法進行回收：

  void deactivateChild(Element child) {
    child._parent = null;
    child.detachRenderObject();
    owner._inactiveElements.add(child); // this eventually calls child.deactivate()
  }

也就在這裏將被廢棄的element添加到了_inactiveElements當中。

另外在廢棄element之後，調用inflateWidget創建新的element時，還調用了_retakeInactiveElement嘗試通過GlobalKey複用element，此時的複用池也是在_inactiveElements當中。

從這裏也能瞭解到，如果你沒有在一幀裏通過GlobeKey完成Element的複用，_inactiveElements在最後將被清空，就沒辦法在複用了。

結尾

將軍，現在您對Flutter的繪製流程有了初步的瞭解了嗎？

將軍：“有些瞭解了，但你講了這麼多，對比起來我們Android，聽起來Flutter這一套繪製流程沒啥缺點？ ”

當然有了，我們現在也只瞭解了Flutter的冰山一角，很多東西還沒有發現。

但就只說動態向ViewTree中插入組件這一條，Flutter就沒有我們靈活。因爲Flutter是聲明式的，想要在運行中隨時向WidgetTree插入一個Widget，目前還沒有成熟接口。

但相信隨着Flutter開發者對Flutter內部原理越來越熟悉，這種問題很快就會被解決的。

紛爭再起：Flutter-UI繪製解析

故事

Android/Flutter 編程範式

Widget、Element、RenderObject概念

Widget、Element、RenderObject之間的關係

Widget、Element、RenderObject 的第一次創建與關聯

Flutter的刷新流程：Element的複用

刷新第1步：Element標記自身爲dirty，並通知buildOwner處理

刷新第2步：buildOwner將element添加到集合_dirtyElements中，並通知ui.window安排新的一幀

刷新第3步：底層引擎最終回調到Dart層，並執行buildOwner的buildScope方法

3.1步：按照Element的深度從小到大，對_dirtyElements進行排序

3.2步：遍歷執行_dirtyElements當中element的rebuild方法

3.3步：遍歷結束之後，清空dirtyElements集合

刷新第4步：執行performRebuild()

ComponentElement的performRebuild()

RenderObjectElement的performRebuild()

Flutter的刷新流程：PipelineOwner對RenderObject的管理

Flutter的刷新流程：清理

結尾

Web 性能優化：圖片優化讓網站大小減少 62%

紛爭再起：Flutter-UI繪製解析

Android啓動流程、app啓動原理

Android指紋識別API講解，一種更快更好的用戶體驗

Android Gradle 自定義Task 詳解

Mac下配置sublime實現LaTeX

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結