次分享的主題主要涉及：移動端跨平臺開發的發展、Flutter Widget 的實現原理 、 Flutter 的實戰技巧 、Flutter Web的現狀 四個方面，而整體主題將圍繞 Widget 為中心展開。
一、移動端跨平臺開發的發展
按照慣例，我們先介紹歷史進程，隨著用戶終端種類的百花齊放，如今跨平臺開發已然成為移動領域的熱門話題之一，移動端跨平臺開發技術的發展，也代表著開發者對於性能、複用、高效上不斷的追求。
移動端的跨平臺開發主要有三個階段，這些階段的代表框架主要有：Cordova、React Native 、Flutter 等，如下圖所示，是移動端的跨平臺發展歷程：
Cordova
Cordova 作為早期跨平臺領域應用最廣泛的框架，為前端人員所熟知，其主要原理就是：
將 web 代碼打包到本地，利用平臺的 WebView 進行加載，通過內部約定好的 JS 通訊協議，加載和調用具備平臺原生能力的插架。
Cordova 讓前端開發人員可以快速的構建移動應用，獲取平臺入口，對早期 web 上欠缺的如攝像機、本地緩存、文件讀寫等能力進行快速支持。
早期的移動開發市場除了 Android 和 iOS 之外，還有 WindowPhone、黑莓等，Cordova 簡單又實用的理念，使得它成為早期熱門的跨平臺框架，至今仍在更新的 ionic 框架，也是在其基礎上進行了封裝發展。
React Native
Cordova 雖然實用方便，但是由於 WebView 的性能瓶頸，開發者開始追求更高性能，且具備平臺特色的跨平臺能力，這時候由 Facebook 開源的 React Native框架開始引領新潮流。
React Native 讓 JS 代碼運行在框架內置的 JS 引擎（JavaScriptCore）上，利用 JS 引擎實現了跨平臺能力，同時又將 JS 控件，對應解析為平臺原生控件進行渲染，從而實現性能的優化與提升。
由於 React 框架的盛行， React Native 也開始成為 React 開發人員，將自身能力拓展到應用開發的最佳選擇之一。同時 React Native 也是應用開發人員，接觸前端的不錯嘗試。
後來阿里開源的 Weex 框架設計相似，利用了 V8 引擎實現跨平臺，不過使用了 Vue 的設計理念，而 Weex 因為種種原因，最終還是沒能大面積推廣開來。
Flutter
事實上 JS Bridge 同樣存在性能等限制，Facebook 也在著力優化這一問題，比如 HermesJS 、底層大規模重構等 ，而 JS -> 平臺控件映射，也導致了框架和平臺耦合過多，在版本兼容和系統升級等問題上讓框架維護越發困難。
這時候谷歌開源了 Flutter ，它另闢蹊徑，只要求平臺提供一個 Surface 和一個 Canvas ，剩下的 Flutter 說：“你可以躺下了，我們來自己動”。
Flutter 的跨平臺思路快速讓他成為“新貴”，連跨平臺界的老大哥 “JS” 語言都“視而不見”，大膽的選擇 Dart 也讓 Flutter 在前期的推廣中飽受爭議。
短短兩年，不算 PR ，Flutter 的 issue 已經有近 1.8 萬的 closed 和 8000+ open , 這代表了它的熱度，也代表著它需要面對的問題和挑戰。不支持 Release 模式下的熱更新，也讓用戶更多徘徊於 React Native 不願嘗試。
不過有一點可以確定的，那就是 Flutter 的版本號上是徹底戰勝了 React Naitve 。
總結起來，我們可以看到，移動端跨平臺的發展，從單純的套殼打包，到提供高性能的跨平臺控件封裝，再到現在的控件與平臺脫離的發展。 整個發展歷程，就是對 性能、複用、高效 的不斷追求。
題外話，為什麼要學習跨平臺？
1、開發成本
我直接學 Java/Kotlin 、Object-C/Switf 、JavaScript/CSS 去寫各平臺的代碼可以嗎？
當然可以，這樣的性能肯定最有保證，但是跨平臺的主要優勢在於代碼邏輯的複用，減少各平臺同一邏輯，因人而異的開發成本。
2、學習機會
一般情況下，各平臺開發者容易侷限在自己的領域開發，而作為應用開發者，跨平臺是接觸另一平臺或領域的過渡機會。
下面開始今天的主題 Flutter ，Flutter 整體涉及的內容很多，由於篇幅問題，本篇我們的主題整體都圍繞一個 Widget 展開。Flutter 作為跨平臺 UI 框架，Widget 是其靈魂設定之一。
二、Flutter Widget 的實現原理
Flutter 是 UI 框架，Flutter 內一切皆 Widget ，每個 Widget 狀態都代表了一幀，Widget 是不可變的。 那麼 Widget 是怎麼工作的呢？
如下圖可以看到，是一個簡單的 Flutter Widget 頁面代碼，頁面包含了一個標題和容易，那在頁面 build 時，它是怎麼表繪製出來的呢？同時它是如何保證性能？而Widget 又是怎麼樣的一個概念？後面我們將逐步揭曉。
首先看上圖代碼，其實如圖的代碼並不是真正的 View 級別代碼，它們更像是配置文件。
而要知道 Widget 是如何工作的，這就涉及到 Flutter 的三大金剛：Widget 、 Element 、RenderObject 。 事實上，這三大金剛才能組成了 Flutter Framework 的基礎渲染閉環。
如上圖所示，當一個 Widget 被“加載“的時候，它並不是馬上被繪製出來，而是會對應先創建出它的 Element ，然後通過 Element 將 Widget 的配置信息轉化為 RenderObject 實現繪製。
所以，在 Flutter 中大部分時候我們寫的是 Widget ，但是 Widget 的角色反而更像是“配置文件” ，真正觸發工作的其實是 RenderObject。
小結一下這裡的關係就是：
- Widget 是配置文件。
- Element 是橋樑和倉庫。
- RenderObject 是解析後的繪製和佈局。
對應詳細的解釋就是：
- 所以我們寫的 Widget，它需要轉化為相應的 RenderObject 去工作；
- Element 持有 Widget 和 RenderObject ，作為兩者的橋樑，並保存著一些狀態參數，我們在 Flutter 框架中常見到的 BuildContext ，其實就是 Element 的抽象 ；
- 最後框架會將 Widget 的配置信息，轉化到 RenderObject 內，告訴 Canvas 應該在哪個 Rect 內，繪製多大 Size 的數據。
所以 Widget 和我們以前的佈局概念不一樣，因為 Widget 是不可變的（immutable），且只有一幀，且不是真正工作的對象，每次畫面變化，都會導致一些 Widget 重新 build 。
那到這裡，我們可能就會關心性能的問題，Flutter 是如何保證性能呢？
1.1、Widget 的輕量級
其實就是迴歸到了 Widget 的定位，作為“配置文件”，Widget 的變化，是否也會導致 Element 和 RenderObject 也會重新創建？
答案是不一定會，Widget 只是一個 “配置文件” 的作用，是非常輕量級的，它的存在，只是起到對 RenderObject 的數據進行配置的作用。
但是 RenderObject 就不一樣了，它涉及到了 layout、paint 等真實 的繪製操作，可以認為是一個真正的 “View” ，如果頻繁創建就會導性能出現問題。
所以在 Flutter 中，會有一系列的判斷，來處理 Widget 到 RenderObject 轉化的性能問題 ，這部分操作通常是在 Element 中進行的 ，例如 updateChild時，會有如下圖所示的判斷：
- 當 element.child.widget == widget.build() 時，就不會觸發 update 操作；
- 在 update 時，canUpdate(element.child.widget, newWidget)返回 true， Element 才會被更新；（這裡代碼中的 slot 一般為 Element 對象，有時候會傳空）
- 其他還有利用 isRelayoutBoundary 、 isRepaintBoundary 等參數，來實現局部的更新判斷，比如：當執行 markNeedsPaint() 觸發繪製時，會通過 isRepaintBoundary 是否為 true ， 往上確定了更新區域，通過 requestVisualUpdate 方法觸發更新往下繪製。
通過 isRepaintBoundary 參數， 對應的 RenderObject 可以組成一個 Layer 。
所以這就可以解答一些初學者的疑問，嵌套那麼多 Widget ，性能會不會有問題？
這也體現出 Flutter 在佈局上和其他框架不同的地方，你寫的 Widget 只是配置文件，堆疊嵌套了一堆控件，對最終的 RenderObject 而言，可能只是多幾個 Offset 和 Size 計算而已。
結合上面的理解，可以知道 Widget 大部分時候，其實只是輕量級的配置，對於性能問題，你更需要關心的是 Clip 、Overlay 、透明合成等行為，因為它們會需要產生 saveLayer 的操作，因為 saveLayer 會清空GPU繪製的緩存。
最後總結個面試點：
- 同一個 Widget 可以同時描述多個渲染樹中的節點，作為配置文件是可以複用的。Widget 和 RenderObject 一般情況是一對多的關係。 （ 前提是在 Widget 存在 RenderObject 的情況。）
- Element 是 Widget 的某個固定實例，與 RenderObject 一一對應。（前提是在 Element 存在 RenderObject 的情況。）
- RenderObject 內 isRepaintBoundary 標示使得它們組成了一個個 Layer 區域。
當 isRepaintBoundary 為 true 時，該區域就是一個可更新繪製區域，而當這個區域形成時，就會新創建一個 Layer 。 但不是每個 RenderObject 都會有 Layer ， 因為這受 isRepaintBoundary 的影響。
注意，Flutter 中常見的 BuildContext ，其實就是 Element 的抽象，通過 BuildContext ，我們一般情況就可以對應獲得 Element ，也就是拿到了“倉庫的鑰匙” ，通過 context 就可以去獲取 Element 內持有的東西，比如前面所說的 RenderObject ，還有後面我們會談到 State 等。
1.2 Widget 的分類
這裡我們將 Widget 分為如下圖所示分類：是否存在 State 、是否存在RenderObject 。
其實還可以按照 RenderBox 和 RenderSliver 分類，但是篇幅原因以後再介紹。
1.2.1 是否存在 State
Flutter 中我們常用的 Widget 有：StatelessWidget 和 StatefulWidget 。
如下圖， StatelessWidget 的代碼很簡單，因為 Widget 是不可變的，傳入的 text 決定了它顯示的內容，並且 text 也算是 final 的。
注意圖中 DemoPage 有個黃色警告，這是因為我們定義了 int i = 0 不是 final 導致的，在 StatelessWidget 中， 非 final 的變量起始容易產生誤解，因為 Widget 本事就是不可變的。
前面我們說過 Widget 都是不可變的，在這個基礎上， StatefulWidget 的 State ，幫我們實現了 Widget 的跨幀繪製 ，也就是在每次 Widget 重構時，可以通過 State 重新賦予 Widget 需要的配置信息，而這裡的 State對象，就是存在每個 Element 裡的。
同時，前面我們說過，Flutter 內的 BuildContext 其實就是 Element 的抽象，這說明我們可以通過 context 去獲取 Element 內的東西，比如 State 、RenderObject 、 Widget 。
Widget ancestorWidgetOfExactType
State ancestorStateOfType
State rootAncestorStateOfType
RenderObject ancestorRenderObjectOfType
如下圖所示，保存在 State 中的 text ，當我們點擊按鍵時，setState 時它被標誌為 "變化了" ， 它可以主動發生改變，保存變量，不再只是“只讀”狀態了。
1.2.2、容器 Widget/渲染 Widget
在 Flutter 中還有 容器 Widget 和 渲染Widget 的區別，一般情況下:
- Text、Slider 、ListTile 等都是屬於渲染 Widget ，其內部主要是 RenderObjectElement ，對應有 RenderObject 參數。
- StatelessWidget / StatefulWidget 等屬於容器 Widget ，其內部使用的是 ComponentElement ， ComponentElement 本身是不存在 RenderObject 的。
所以作為容器 Widget， 獲取它們的 RenderObject 時，獲取到的是 build後的樹結構裡，最上面渲染 Widget的 RenderObject 。
如上圖所示 findRenderObject 的實現，最終就是獲取 renderObject，在遇到 ComponentElement 時，執行的是 element.visitChildren(visit); , 遞歸直到找到 RenderObjectElement ，再返回它的 renderObject。
獲取 RenderObject 在 Flutter 裡很重要的，因為獲取控件的位置和大小等，都需要通過 RenderObject 獲取。
1.3、RenderObject
Flutter 中各類 RenderObject 的實現，大多都是顆粒度很細，功能很單一的存在 ：
然而接觸過 Flutter 的同學應該知道 Container 這個 Widget ，Container的功能卻不顯單一，這是為什麼呢？
如下圖，因為 Container 其實是容器 Widget ，它只是把其他“單一”的 Widget 做了二次封裝，然後通過配置參數來達到 “多功能的效果” 而已。
所以 Flutter 開發中，我們經常會根據功能定義出各類如 Continer、Scaffold 等腳手架模版，實現靈活與複用的界面開發。
迴歸到 RenderObject ，事實上 RenderObject 還屬於比較“低級”的階段，因為繪製到屏幕上我們還需要座標體系和佈局協議等，所以 大部分 Widget 的 RenderObject 會是子類 RenderBox (RenderSliver 例外) ，因為 RenderObject 本身只實現了基礎的 layout 和 paint ，而繪製到屏幕上，我們需要的座標和大小等，這些內容是在 RenderBox 中開始實現。
RenderSliver 主要是在滾動控件中繼承使用。
比如控件被繪製在 x=10,y=20 的位置，然後大小由 parent 對它進行約束顯示，RenderBox 繼承了 RenderObject，在其基礎上實現了 笛卡爾座標系和佈局協議。
這裡我們通過 Offstage 這個 Widget ，看下其 RenderBox 子類的實現邏輯， Offstage 是用於控制 child 是否顯示的作用，如下圖，可以看到 RenderOffstage 對於 offstage 標誌位的內部邏輯：
那麼 Flutter 中的佈局協議是什麼呢？
簡單來說就是 child 和 parent 之間的大小應該怎麼顯示，由誰決定顯示區域。 相信從 Android 到接觸 Flutter 的同學有這樣的疑惑， Flutter 中的 match_parent 和 wrap_content 邏輯需要怎麼設置？
就我們從一個簡單的代碼分析，如下圖所示，Row 佈局我們沒有設置任何大小，它是怎麼確定自身大小的呢？
我們翻閱源碼，可以發現其實 Flutter 中常用的 Row 、Column 等其實都是 Flex 的子類，只是對 Flex 做了簡單默認配置。
那按照我們前面的理解，看一個 Widget 的實現邏輯，就應該看它的 RenderObject ，而在 Flex 布對應的 RenderFlex 中，我們可以看到如下一段代碼：
可以看到在佈局的時候，RenderFlex 首先要求 constraints != null，Flex 佈局的上層中必須存在約束，不然肯定會報錯。
之後，在佈局時，Row 佈局的 direction 是橫向的，所以 maxMainSize 為上層佈局的最大寬度，然後根據我們配置的 mainAxisSize 的參數：
- 當 mainAxisSize 為 max 時，我們 Row 的橫向佈局就是 maxMainSize ；
- 當 mainAxisSize 為 min 時，我們 Row 的橫向佈局就是 allocatedSize ；
前面 maxMainSize 我們知道了是父佈局的最大寬度，而 allocatedSize 其實就是 child 的寬度之和。所以結果很明顯了：
對於 Row 來說， mainAxisSize 為 max 時就是 match_parent；mainAxisSize 為 min 時就是 wrap_content 。
而高度 crossSize ，其實是由 math.max(crossSize, _getCrossSize(child)); 決定，也就是 child中最高的一個作為其高度。
最後小結一個知識點：
佈局一般都是由上層往下傳遞 Constraints ，然後由下往上返回 Size。
那如何直接自定義 RenderObject 佈局？
拋開 Flutter 為我們封裝的好的，三大金剛 Widget 、Element、RednerObject 一個不少，當然， Flutter 內置了很多封裝幫我們節省代碼。
一般情況下自定義 RenderObject 佈局：
- 我們會繼承 MultiChildRenderObjectWidget 和 RenderBox 這兩個 abstract 類，實現自己的Widget 和 RenderObject 對象；
- 然後利用 MultiChildRenderObjectElement 關聯起它們；
- 除此之外，還有幾個關鍵的類：ContainerRenderObjectMixin 、 RenderBoxContainerDefaultsMixin 和 ContainerBoxParentData 等可以幫你減少代碼量。
總結起來， 對於 Flutter 而言，整個屏幕都是一塊畫布，我們通過各種 Offset 和 Rect 確定了位置，然後通過 Canvas 繪製上去，目標是整個屏幕區域，整個屏幕就是一幀，每次改變都是重新繪製。
這裡沒有介紹 RenderSliver 相關，它的輸入和輸出和 Renderbox 又不大一樣，有機會我們後面再詳細介紹。
三、Flutter 的實戰技巧
3.1、InheritedWidget
InheritedWidget 是 Flutter 的靈魂設定之一。
InheritedWidget 共享的是 Widget ，只是這個 Widget 是一個 ProxyWidget ，它自己本身並不繪製什麼，但共享這個 Widget 內保存有的數據，從而到了共享狀態的目的。
如下圖所示，是 Flutter 中常見的 Theme ，其內部就是使用了 _InheritedTheme 這個 InheritedWidget 來實現主題的全局共享的。那麼 InheritedWidget 是如何實現全局共享的呢？
其實在 Element 的內部有一個 Map<type> _inheritedWidgets; 參數，_inheritedWidgets 一般情況下是空的，只有當父控件是 InheritedWidget 或者本身是 InheritedWidget 時，它才會被初始化，而當父控件是 InheritedWidget 時，這個 Map 會被一級一級往下傳遞與合併。/<type>
所以當我們通過 context 調用 inheritFromWidgetOfExactType 時，就可以通過這個 Map 往上查找，從而找到這個上級的 InheritedWidget 。（畢竟 context is Element）
如我們的 Theme/ThemeData 、Text/DefaultTextStyle、Slider / SliderTheme 等，如下代碼所示，我們可以定義全局的 ThemeData 或者局部的 DefaultTextStyle ，從而實現全局的自定義和局部的自定義共享等。
其實，Flutter 中大部分的狀態管理控件，其狀態共享方法，也是基於 InheritedWidget 去實現的。
3.2、支持原生控件
前面我們說過， Flutter 既然不依賴於原生控件，那麼如何集成一些平臺已有的控件呢？比如 WebView 和 Map ？
我們這裡以 WebView 為例子：
在官方 WebView 控件支持出來之前 ，第三方是直接在 FlutterView 上覆蓋了一個新的原生控件，利用 Dart 中的佔位控件傳遞位置和大小。
如下圖，在 Flutter 端 push 出一個 設定好位置和大小 的 SingleChildRenderObjectWidget ，從而得到需要顯示的大小和位置，將這些信息通過 MethodChannel 傳遞到原生層，在原生層 addContentView 一個指定大小和位置的 WebView 。
這時候 WebView 和 SingleChildRenderObjectWidget 處於一樣的大小和位置，而空白部分則用 FLutter 的 Appbar 顯示。
這樣看起來就像是在 Flutter 中添加了 WebView ，但實際這脫離了 Flutter 的渲染樹，其中一個問題就是，當你跳轉 Flutter 其他頁面的時候，會被 WebView 擋住；並且打開頁面的動畫，Appbar 和 WebView 難以保持一致。
後面 官方 WebView 控件支持出來後，這時候官方是利用 PlatformView 的設計，完成了不脫離 Flutter 渲染堆棧，也能集成平臺原生控件的功能。
以 Android 為例，Android 上是利用了副屏顯示的底層邏輯，使用 VirtualDisplay 類，創建一個虛擬顯示器，需要調用 DisplayManager 的 createVirtualDisplay() 方法，將虛擬顯示器的內容渲染在一個內存的 Surface 上 ，生成一個唯一的 textureId 。
如下圖，之後渲染時將 textureId 傳遞給 Dart 層，渲染引擎會根據 textureId , 獲取到內存裡已渲染數據，繪製到 AndroidView 上進行顯示。
3.3、錯誤處理
Flutter 中比較有趣的情況是，在 Dart 中的一些錯誤，並不會導致應用閃退，而是通過如下的紅色堆棧 UI ，錯誤區域不同，可能是全屏紅，也可能局部紅，這種狀態就和傳統 APP 的“崩潰”狀態不大一樣了。
在開發過程中這樣的顯示沒太大問題，但事實發佈線上版本就不合適了，所以我們一般會選擇自定義錯誤顯示。
如下圖所示，一般我們可以通過如下處理，自定義我們的錯誤頁面，並且收集錯誤信息。
重寫 ErrorWidget 的 builder 方法，然後將信息收集到 Zone 中，返回自己的自定義錯誤顯示，最後在 Zone 內利用 onError 統一處理錯誤。
ps 圖中的 Zone 等概念這裡就不展開了，有興趣的可以去以前的文章詳細查看
四、Flutter Web
最後簡單說下 Flutter Web ，Flutter 在支持 Web 平臺上的優勢在於 Flutter UI 與平臺的耦合度很低，而 Dart 起初就是為了 Web 而生，一拍即合下 Flutter 支持 Web 並不是什麼意外。
但是 Web 平臺就繞不過 JS ，在 Web 平臺，實際上 Image 控件最後會通過 dart2js 轉化為 標籤並通過 src 賦值顯示。
同時，多了一個平臺就多了需要兼容的，目前 Flutter 的 issue 仍然不少，而 Web 支持雖然已經合併到主項目中，但是在兼容、性能等問題上還需要繼續優化，比如 Flutter Web 中 canvas.drawColor(Colors.black, BlendMode.clear);是會出現運行錯誤的，因為不支持 BlendMode.clear 。
閱讀更多 真致信息技術 的文章
