為避免傳統的原始碼講解方式的枯燥乏味，這一次，我嘗試換一種方式，帶著你以輕鬆的心態瞭解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內部原理越來越熟悉，這種問題很快就會被解決的。