Flutter render 的那一兩件事情
前言
上回寫了 Jetpack compose 後，我很好奇，為什麼 compose 的 composable 可以像不用錢似的一直 instance。
我想起了之前稍微碰了一下的 Flutter ，原則上 Jetpack compose 和 Flutter 都是 Google 的攣生兄弟，他們兩個都是都是宣告式的語法，然後因為 Widget 和 composable 都被設定為不可異動，所以更新它們 UI 的方式好像不用錢似的每次刷新每次都是一個新的 instance 。
這令我好奇心蠢蠢欲動，於是我開始追 Code ，然後看文件，追一些文章，後來理出這篇文章，應該可以稍微解釋一下，究竟是甚麼原因，可以讓 Widget 這些東西可以不斷被重新 instance。
先來看看怎麼建立一個 App
Dart 是從 main 開始的，透過 runApp 這個 method 去把做為 app 的Widget 給建構出來 -
寫 Android 寫久了，看到 main 會莫名的覺得有點新鮮。不過 Android 沒 main 是 Android 那很不一樣的架構所致的，否則 main 應該都會作為大多數應用程式起始點，至於 Android App 那很不一樣的起始那又是另一個故事了。
可以注意到， runApp 本身是一個 top-level-functions，那他會做的事情是去初始化建構一個 WidgetsFlutterBinding ，那麼之後 Widget 的更新等等操作都會在這邊去做處理。
先不要管排程這件事情，總之這裡 runApp 要做的事情呢，就是要把傳進來的 RichText 當作是 rootWidget
要怎麼做才能成為 root widget 呢？追下去，可以注意到，這裡要利用這個 widget 去建立 element，在 attachRootWidget 的時候，這裡實作了一個叫做 RenderObjectToWidgetAdapter 的 widget，並把 RichText 作為 child 傳入，接著呼叫了一個叫做 attachToRenderTree 的地方。
只是這時的 renderViewElement 是伴隨著 WidgetsFlutterBinding 被宣告的，但還沒有被實作，所以會是 null，那會發生甚麼事情呢？
他會去呼叫 createElement()
createElement() 會實作並回傳一個叫做 RenderObjectToWidgetElement 的 Element，並把 RenderObjectToWidgetAdapter 作為 Property 傳入。
接著看下去，會發現被建立出來的 Element 呼叫了 mount ，這裡應該是安裝的意思，那來看一下 mount 具體做了甚麼事情：
可以看到這邊利用剛才作為 property 傳入的 RenderObjectToWidgetAdapter 呼叫 createRenderObject，並且把 Element 當成 Property 傳入他的 constructor 之中。
看到這邊會發現，三個在 Flutter render 系統的大名鼎鼎的 Widget 、Element、RenderObject 都出現了，他們之間的關係真的不是普通的亂，但還沒完呢。
呼叫了 RenderObjectToWidgetAdapter 的 createRenderObject 拿到的會是甚麼？是隨著 WidgetsFlutterBinding 一同產生一個叫做 renderView 的 RenderObject。
這個 container 正是 RenderObjectWidgetAdapter 在實作產生 RenderObjectToWidgetElement 傳入的 renderView，這個怎麼來的待會解釋。
做完上面這些行為後，RenderObjectToWidgetElement 會在尾巴呼叫一個叫做 _rebuild 的 private method。
可以看到這時的會做一個 update child 的動作。
這時只要知道 widget.child 是誰呢？先來看看 widget 是誰？沒錯，就是 RenderObjectToWidgetAdapter ，那 RenderObjectToWidgetAdapter 的 child 是誰？一卡檸檬，正是 RichText。
可以發現會進到 inflateWidget
裏頭會用 RichText 這個 Widget 呼叫 createElement ，建立一個 MultiChildRenderObjectElement ，同時會把自己當成 property 傳進去 MultiChildRenderObjectElement 裏頭。
接著會用 MultiChildRenderObjectElement 做 mount ，這裡只要知道 this 就是 RenderView，作為 parent 傳入這個 method。
很有趣，似乎又繞回了 RenderObjectElement (RenderObjectElement 是 RenderObjectToWidgetElement 的繼承類別，但這邊先別管這個)，那可以注意到這裡利用 widget 。也就是 RichText 建立了一個 RenderObject 叫做 RenderParagraph ，記得是由 MultiChildRenderObjectElement 拿著 RenderObject，而非 widget。
接著來到 attachRenderObject
這邊會找一個 Ancestor (祖先) 的 RenderObjectEelement ，還記得傳進來的 parent 是誰嗎？沒錯，正是 RenderObjectToWidgetElement。
RenderObjectToWidgetElement 的 RenderObject 是誰呢？正是 WidgetsFlutterBinding 的 renderView 。 此時終於把 RichText 的 RenderObject 和 WidgetsFlutterBinding 的 RenderObject renderView 綁在一起了。
簡單的整理一下我們上面得到的資訊，
- 塞了一個 Widget 給 runApp
- 產生一個 WidgetsFlutterBinding (如果現存為 null 的話) 附帶一個 renderView ，他正是 WidgetsFlutterBinding 的 RenderObject
- 產生 RenderObjectToWidgetAdapter 。
- 利用 RenderObjectToWidgetAdapter 產生 RenderObjectToWidgetElement 並將 RenderObjectToWidgetAdapter 作為 RenderObjectToWidgetElement 的 property。
- RenderObjectToWidgetElement 會產生當初 runApp 傳入的 Widget 的 Element 。
- 利用 Widget 產生出來的 Element 透過 Widget 產生 RenderObject。
- 利用 RenderObjectToWidgetElement 將 Widget 的 RenderObject 變成 WidgetsFlutterBinding 的 renderView 的 child ，並將其作為 root widget。
好，知道這些，我們可以了解到 RenderObject 是透過 Element 利用 Widget 產生出來的，而 Element 則是由 Widget 產生出來的。
在做完綁定後，接著的 scheduleWarmUpFrame 就會開始把 widget 提供的資訊 render 畫面了。
那 RenderObject 是啥玩意阿？
說到 RenderObject ，那可以來看看 RenderView 是幹嘛的。
在 runApp 時，建立了 WidgetsFlutterBinding ，那這個 WidgetsFlutterBinding 同時含有一個叫做 RenderBinding 的 mixin
那麼 RenderBinding 就在生成的過程中同時產生了 RenderView。
那顯然 RenderView 會負責把他的 Child 給畫到畫面上。
那會怎麼畫取決於 Child 是甚麼樣的 RenderObject：
RenderObject 在呼叫 PainWithContext 後會呼叫到 paint ，以 RichText 來說，他的 RenderObject 是 RenderParagraph ，那他的 paint 大概是這樣：
有玩過 Android View 人對上面的 canvas 阿，drawRect 等等應該都不陌生。
可見 RenderView 就是 runApp 時所產生，算是一個 App 裡原初的 RenderObject。
像是 Column ，他的 RenderObject 叫做 RenderFlex ，RenderFlex 的 paint 會呼叫 defaultPaint ，那 defaultPaint 就會開始去呼叫他的 child 並繪製他。
講到這裡，如果對 View Tree 有概念的話，腦海應該浮現了一個樹狀圖。
我以這個簡單的 MaterialApp 來舉例：
MaterialApp 是 StatefulWidget ，StatefulWidget 和 StatelessWidget 跟 RichText 比較不一樣，它們並不需要建立 RenderObject ，主要是因為他們要 Render 的對象是它們提供出來的 Widget ，這邊不深究(雖然待會會提及一點 State 的部分)，所以這個簡單的 App 的 RenderObject tree 只要看 _MyHomePageState build 的部分。
假如 RichText 是一個 Android 的 View ，那麼在 Android 裏頭，會用 findViewById 去把它弄成一個 field 然後放到 control flow (Activity, fragment) 去操作。
又回到了最初的問題了，這樣我建立一個 Widget 豈不是每次都要重新建一個 RenderObject 然後去 layout 接著 draw 。
StatefullWidget 呼叫一次 setState 成本不是嚇死人了？
好，請聽我娓娓道來。
到目前為止，RenderObject 看起來跟用 Native 的 View 很像，雖然可能還是沒有很懂為啥需要有個 Widget 和 Element。那回到最初的問題：為什麼 Flutter 的 Widget 可以像是不用錢一樣的，每次都給一個新的 instance 呢？上面的敘述只是稍微弄清了 Widget、Element、RenderObject 三者的關係，那具體到底怎麼辦到的呢？
PS: 嚴格說起來還是要點花費，只是成本相對低很多
來理解三者的關係吧
這邊簡單弄一個可以 set State 的 App
我在按下 TextButton 後，會觸發 setState ，經歷了很長一段在這邊不談的程式碼後，接著會在會重新呼叫到 build(BuildContext)，然後拿去跟
updateChild 的時候呢，就會比對這個 Widget 是不是一樣(主要是比對 widget 的類型還有 key，而 key 絕大部分時候都是 null)？是不是能夠更新？或者是需要插入另一個新的 Widget 呢？
樹一層一層被遞迴來到了 RichText 的 Element 後，會呼叫 Widget 的 updateRenderObject
在這裡就決定了，甚麼東西需要重畫，甚麼東西不用(雖然把全部的 Property 全 assign 了一次了，但是每一個 property 都有判斷值相不相同，所以原則上這邊需要重畫的只有 text)。
有意思的地方來了，還記得前面說過，這邊的 Widget 是誰拿著的？那這邊的 RenderObject 又是誰拿著的。
沒錯，都是 Element 。
簡單來說，runApp 完後，大致上的局勢是這樣的。
在 setState 的時候， MyHomePage’s 的 StatefulElement 會得到一個新的 Widget。
那麼 Element 會往下丟給它的 Child。
這邊確定一樣後，就繼續往下丟給它的 Child。
這邊會問能否 update ，原則上兩個類型一樣就會 update 了，所以會送給 Element 的 RenderObject ，而 RenderObject 再比對有沒有 Property 不同，再去決定甚麼東西要重畫。
TextButton 也差不多，只是很顯然 TextButton 在此時沒有東西要重畫。
回過頭來改一下 Code ：
我如果按了一下按鈕，會把原本的 TextButton 給取代為另一個新的 RichText 。
一開始 MyHomePage 得到新的一個 Column ，他把他往下給他的 Child — 原本的 Column：
對於 Column 的 Element 來說，他會發現，喔喔，我的 child 被換掉了，那舊的 child 我不要了，把 Element 連同 RenderObject 一起丟了，我需要重新 layout 來放新的 child。
這裡先略過做完更新原有 RichText 的步驟。新的 child 得產生新的 Element 。
新的 Element 需要新的 RenderObject ，於是就走了 inflateWidget 的流程，產生新的 RenderObject ，接著把 RichText 給畫出來了。
結語
說了這麼多，大概可以說明一下 ，Widget、Element、RenderObject 是甚麼了？
RenderObject 就是負責繪圖。說碰到它很昂貴有點沉重，基本上畫面有變就會動到他，它至少會去比對 Property 有沒有不一樣、要不要重繪。所以實際上還是很常碰到 RenderObject ，但在理論上在寫 Flutter 的時候不太容易直接碰到它就是了。
Element 可以當作是當前 Widget 還有 RenderObject 的狀態持有者。雖然官方文件說它是 Widget 的 instantiation，但它並不是 Widget widget = new Element(); 這種關係。Widget 的 instantiation 需要有一個 RenderObject 和自身 Widget 的設定，Element 負責這事情，所以 Element 是 widget 的 instantiation。那麼Flutter 是跨平台的框架，但是主力是在兩個手機雙平台上，雙平台基本上不可避免生命週期的東西，那 Element 他持有 Widget 和 RenderObject 的狀態，應該也可以猜到它會負責生命週期的東西，但不是這篇的重點，這邊就不贅述了。
Widget 理論上會是 Flutter 開發者最常碰到的東西。那他其實除了負責持有 RenderObject 應該要怎麼 layout 怎麼 render 的資訊外。此外他還會持有怎麼產生自己的 element ，且根據 element 而定(像 Statefulwidget，他是會另外產生 Widget ，所以他並不需要產生 RenderObject)，他也會需要知道怎麼建立屬於他的 RenderObject 以及怎麼 updateRenderObject，那這些事情都是由它產生的 Element 或是做為他的 parent 的 Element 去做的，包括產生自己的 Element ，instance widget 本身並不會做這些事情，所以，產生一個新的 widget instance 是很廉價，因為產生他只會生成資料不會直接生成 Element 和 RenderObject，昂貴與否得看你怎麼去變動你的 layout widget 那些。
知道這些後，就知道為什麼 Widget 可以像不用錢似的不斷重新 instance ，因為本質上他就是一個設定檔、或者說藍圖的存在。小生我對於 Web 前端並不太熟，但這個模式跟 DOM 好像類似就是了。
如果有任何問題，或是看到寫錯字，請不要吝嗇對我發問或對我糾正，您的回覆和迴響會是我寫文章最大的動力。
