Flutter 是怎麼運轉的？
與用於構建移動應用程式的其他大多數框架不同，Flutter 是重寫了一整套包括底層渲染邏輯和上層開發語言的完整解決方案。這樣不僅可以保證檢視渲染在 Android 和 iOS 上的高度一致性（即高保真），在程式碼執行效率和渲染效能上也可以媲美原生 App 的體驗（即高效能）。
這，就是 Flutter 和其他跨平臺方案的本質區別：
- React Native 之類的框架，只是通過 JavaScript 虛擬機器擴充套件呼叫系統元件，由 Android 和 iOS 系統進行元件的渲染；
- Flutter 則是自己完成了元件渲染的閉環。
那麼，Flutter 是怎麼完成元件渲染的呢？這需要從影像顯示的基本原理說起。
在計算機系統中，影像的顯示需要 CPU、GPU 和顯示器一起配合完成：CPU 負責影像資料計算，GPU 負責影像資料渲染，而顯示器則負責最終影像顯示。
CPU 把計算好的、需要顯示的內容交給 GPU，由 GPU 完成渲染後放入幀緩衝區，隨後視訊控制器根據垂直同步訊號（VSync）以每秒 60 次的速度，從幀緩衝區讀取幀資料交由顯示器完成影像顯示。
作業系統在呈現影像時遵循了這種機制，而 Flutter 作為跨平臺開發框架也採用了這種底層方案。下面有一張更為詳盡的示意圖來解釋 Flutter 的繪製原理。
圖 1 Flutter 繪製原理
可以看到，Flutter 關注如何儘可能快地在兩個硬體時鐘的 VSync 訊號之間計算併合成檢視資料，然後通過 Skia 交給 GPU 渲染：UI 執行緒使用 Dart 來構建檢視結構資料，這些資料會在 GPU 執行緒進行圖層合成，隨後交給 Skia 引擎加工成 GPU 資料，而這些資料會通過 OpenGL 最終提供給 GPU 渲染。
在進一步學習 Flutter 之前，我們有必要了解下構建 Flutter 的關鍵技術，即 Skia 和 Dart。
Skia 是什麼？
要想了解 Flutter，你必須先了解它的底層影像渲染引擎 Skia。因為，Flutter 只關心如何向 GPU 提供檢視資料，而 Skia 就是它向 GPU 提供檢視資料的好幫手。
Skia 是一款用 C++ 開發的、效能彪悍的 2D 影像繪製引擎，其前身是一個向量繪圖軟體。2005 年被 Google 公司收購後，因為其出色的繪製表現被廣泛應用在 Chrome 和 Android 等核心產品上。Skia 在圖形轉換、文字渲染、點陣圖渲染方面都表現卓越，並提供了開發者友好的 API。
目前，Skia 已然是 Android 官方的影像渲染引擎了，因此 Flutter Android SDK 無需內嵌 Skia 引擎就可以獲得天然的 Skia 支援；而對於 iOS 平臺來說，由於 Skia 是跨平臺的，因此它作為 Flutter iOS 渲染引擎被嵌入到 Flutter 的 iOS SDK 中，替代了 iOS 閉源的 Core Graphics/Core Animation/Core Text，這也正是 Flutter iOS SDK 打包的 App 包體積比 Android 要大一些的原因。
底層渲染能力統一了，上層開發介面和功能體驗也就隨即統一了，開發者再也不用操心平臺相關的渲染特性了。也就是說，Skia 保證了同一套程式碼呼叫在 Android 和 iOS 平臺上的渲染效果是完全一致的。
為什麼是 Dart？
Dart 因為同時支援 AOT 和 JIT，所以具有執行速度快、執行效能好的特點外，Flutter 為什麼選擇了 Dart，而不是前端應用的準官方語言 JavaScript 呢？這個問題很有意思，但也很有爭議。
Google 公司給出的原因很簡單也很直接：Dart 語言開發組就在隔壁，對於 Flutter 需要的一些語言新特性，能夠快速在語法層面落地實現；而如果選擇了 JavaScript，就必須經過各種委員會和瀏覽器提供商漫長的決議。
Flutter 的原理
在瞭解了 Flutter 的基本運作機制後，我們再來深入瞭解一下 Flutter 的實現原理。
首先，我們來看一下 Flutter 的架構圖。我希望通過這張圖以及對應的解讀，你能在開始學習的時候就建立起對 Flutter 的整體印象，能夠從框架設計和實現原理的高度去理解 Flutter 區別其他跨平臺解決方案的關鍵所在，為後面的學習打好基礎，而不是直接一上來就陷入語言和框架的功能細節“泥潭”而無法自拔。
圖 2 Flutter 架構圖
備註：此圖引自Flutter System Overview
Flutter 架構採用分層設計，從下到上分為三層，依次為：Embedder、Engine、Framework。
- Embedder 是作業系統適配層，實現了渲染 Surface 設定，執行緒設定，以及平臺外掛等平臺相關特性的適配。從這裡我們可以看到，Flutter 平臺相關特性並不多，這就使得從框架層面保持跨端一致性的成本相對較低。
- Engine 層主要包含 Skia、Dart 和 Text，實現了 Flutter 的渲染引擎、文字排版、事件處理和 Dart 執行時等功能。Skia 和 Text 為上層介面提供了呼叫底層渲染和排版的能力，Dart 則為 Flutter 提供了執行時呼叫 Dart 和渲染引擎的能力。而 Engine 層的作用，則是將它們組合起來，從它們生成的資料中實現檢視渲染。
- Framework 層則是一個用 Dart 實現的 UI SDK，包含了動畫、圖形繪製和手勢識別等功能。為了在繪製控制元件等固定樣式的圖形時提供更直觀、更方便的介面，Flutter 還基於這些基礎能力，根據 Material 和 Cupertino 兩種視覺設計風格封裝了一套 UI 元件庫。我們在開發 Flutter 的時候，可以直接使用這些元件庫。
接下來，我以介面渲染過程為例，和你介紹 Flutter 是如何工作的。
頁面中的各介面元素（Widget）以樹的形式組織，即控制元件樹。Flutter 通過控制元件樹中的每個控制元件建立不同型別的渲染物件，組成渲染物件樹。而渲染物件樹在 Flutter 的展示過程分為四個階段：佈局、繪製、合成和渲染。
佈局
Flutter 採用深度優先機制遍歷渲染物件樹，決定渲染物件樹中各渲染物件在螢幕上的位置和尺寸。在佈局過程中，渲染物件樹中的每個渲染物件都會接收父物件的佈局約束引數，決定自己的大小，然後父物件按照控制元件邏輯決定各個子物件的位置，完成佈局過程。
圖 3 Flutter 佈局過程
為了防止因子節點發生變化而導致整個控制元件樹重新佈局，Flutter 加入了一個機制——佈局邊界（Relayout Boundary），可以在某些節點自動或手動地設定佈局邊界，當邊界內的任何物件發生重新佈局時，不會影響邊界外的物件，反之亦然。
圖 4 Flutter 佈局邊界
繪製
佈局完成後，渲染物件樹中的每個節點都有了明確的尺寸和位置。Flutter 會把所有的渲染物件繪製到不同的圖層上。與佈局過程一樣，繪製過程也是深度優先遍歷，而且總是先繪製自身，再繪製子節點。
以下圖為例：節點 1 在繪製完自身後，會再繪製節點 2，然後繪製它的子節點 3、4 和 5，最後繪製節點 6。
圖 5 Flutter 繪製示例
可以看到，由於一些其他原因（比如，檢視手動合併）導致 2 的子節點 5 與它的兄弟節點 6 處於了同一層，這樣會導致當節點 2 需要重繪的時候，與其無關的節點 6 也會被重繪，帶來效能損耗。
為了解決這一問題，Flutter 提出了與佈局邊界對應的機制——重繪邊界（Repaint Boundary）。在重繪邊界內，Flutter 會強制切換新的圖層，這樣就可以避免邊界內外的互相影響，避免無關內容置於同一圖層引起不必要的重繪。
圖 6 Flutter 重繪邊界
重繪邊界的一個典型場景是 Scrollview。ScrollView 滾動的時候需要重新整理檢視內容，從而觸發內容重繪。而當滾動內容重繪時，一般情況下其他內容是不需要重繪的，這時候重繪邊界就派上用場了。
合成和渲染
終端裝置的頁面越來越複雜，因此 Flutter 的渲染樹層級通常很多，直接交付給渲染引擎進行多圖層渲染，可能會出現大量渲染內容的重複繪製，所以還需要先進行一次圖層合成，即將所有的圖層根據大小、層級、透明度等規則計算出最終的顯示效果，將相同的圖層歸類合併，簡化渲染樹，提高渲染效率。
合併完成後，Flutter 會將幾何圖層資料交由 Skia 引擎加工成二維影像資料，最終交由 GPU 進行渲染，完成介面的展示。這部分內容，我已經在前面的內容中介紹過，這裡就不再贅述了。
接下來，我們再看看學習 Flutter，都需要學習哪些知識。