1
移動跨平臺技術探究
◆ 為什麼需要跨平臺？
◆ 跨平臺技術是如何發展起來的？
◆ 跨平臺技術選型有哪些？
◆ Flutter有什麼獨特優勢(為什麼選擇Flutter)？
◆ 為什麼說Flutter是高性能的，體現在哪裡？
2
Flutter引擎原理剖析
先來看看Flutter的技術架構圖：
C++引擎四個核心線程
Flutter 裡四個核心線程：平臺線程、UI 線程、GPU 線程、IO 線程，它們的職責都是不一樣的：
★ 平臺線程(PlatformThread)對應著安卓和 iOS 的主線程。
★ UI線程(UI Thread)針對安卓本身的主線程，它就是一個獨立的線程。
★ GPU線程(GPU Thread)運行在 GPU 上的線程，它主要是處理 Skia 相關的任務。
★ IO線程(IO Thread)主要處理IO有關的任務，比如：圖片編解碼等。
具體引擎架構圖，如下圖示所示：
Flutter如何編譯成兩個平臺的應用程序
首先看下面的引擎代碼是公共的部分，用於把程序的源代碼編譯Android和IOS兩個平臺的應用程序。中間左側綠色部分Flutter針對Android生成的一些文件，然後最終通過引擎會編譯生成Android的APK安裝包，中間右側藍色部分是Flutter針對IOS平臺生成的一些文件，然後最終通過引擎會編譯會生成IOS平臺的安裝包。
線程通信（混合開發必須瞭解的難點）
這裡以Android為例，對照Flutter做一個講解。Flutter裡面的線程主要依賴於Dart裡面的一些API，比如我們常用的異步任務裡面，需要用到：MicroTask和Future，就是非常重要和關鍵的。
我們可以看到技術是相通的，Android裡面是一個Handler，對應一個Looper Thread，然後是一個MessageQueue，然後裡面存放的是Message。很巧妙的是Flutter也有類似的做法，Flutter有一個Looper線程，主線程複用了Native的，然後為其他三個線程創建獨立的Looper。不過與Android不同的是：Flutter用的是兩個隊列，一個是微任務隊列（MicroTaskQueue），一個是普通延遲任務隊列。Flutter會先處理為任務隊列，再去處理普通任務隊列。類比Android來講，圖中的TaskRunner類似於Handler，PostTask就是把一個消息放到一個消息隊列的過程。和Android的Handler是很類似的。所以在學新技術的時候，舉一反三，懂得變通才能學的更好。
Dart虛擬機
同一個進程裡可以有很多 Isolate，兩個 Isolate 的堆是不能共享的。Dart開發團隊早就考慮到了交互的問題，於是就設計了一個VM Isolate，它是一個用戶Isolate之間交互的橋樑，運行在 UI 線程中的。我們可以把數據放在內核態，因為這個內核態可以共享數據，然後把數據放到另一方的隊列中，另一方就可以拿到和使用這些數據了。熟悉Android的朋友們應該聽起來很熟悉，這就非常類似我們熟知的“進程間通信”。
可能這樣講還不是很清楚，具體流程是什麼樣的呢？請看下圖：
Isolate1是發送方，創建一個SendPort ，Isolate2是接收方，創建一個ReceivePort。我們創建一個 Isolate的時候，它裡面有一個 worker 線程，worker 線程裡面可以放入Task。SendPort調用send方法，發送數據到PortMap裡面，這個裡面每一個port對應一個Isolate 的 MessageHandler，這個Handler包括兩個內容：普通的消息隊列，一個是 OOB 高優先級消息，數據放入隊列順序有優先級區分。最後消息被封裝成一個 MessageTask，傳送到另一個Isolate裡面去。回想一下是不是類似於Android的消息隊列？
Platform Channels
Flutter提供了Channel是用於和Native功能做交互。Android這邊使用MethodChannel，IOS這邊使用FlutterMethdChannel。最終Flutter通過銜接兩個平臺，使用統一的規範去銜接兩個平臺，暴露出一些函數和接口，然後就可以很容易的使用Flutter去調用Native的功能了。這個依賴於開發者的水平，需要對Android或IOS比較瞭解才能更好的寫出插件出來。pub.dev上面也有很多開源庫，不過往往開發中需求總是在變更的，開源庫遠遠達滿足不了實際開發需求的功能點，所以還是需要自己掌握Platform Channels的知識點比較好。
3字節跳動在Flutter架構上的實踐
下面來看字節跳動主要做了哪些架構實踐，請看下圖：
從上圖中還是可以看到字節跳動做了很多基礎工作的，比如：容器化、混合工程、渲染、包體積、編譯優化、多端一體化等。看上去確實感覺是很多東西的。下面簡單的介紹其中比較關鍵的幾個：
容器化架構
個人感覺所謂“容器化”，就類似於原生平臺的組件化或者業務分層架構的思想。就是為普通業務打造可擴展的接口和行為準則。不過這個Flutter容器化架構要適應Android和IOS兩個平臺，然後針對不同的平臺的業務行為需要定義統一的標準和規範以及封裝了一些通用業務模塊功能(其中的某些可以看做是基礎業務的基類)，比如：圖片調用，直接去這裡面的協議層，直接調用就可以了，內部都封裝好了，直接傳參調用，這裡面有默認的適配，你也可以自定義。有了“容器化”的架構，平臺基礎API的差異性就不需要考慮了，開發者只管調用內部的功能模塊或者接口即可快速開發新需求功能。
多端一體化實踐
這個就不用多說了，就是寫一個應用可以同時運行在Android、IOS、Web上面，省去了大量的開發週期，多端一體化結合了Flutter，以及Flutter Web，然後定製化了一些內部引擎和功能模塊的架構，最終打造出了這套多端一體化的工程體系架構。
監控體系
Flutter自帶的性能監控工具顆粒度是很粗糙的，用的是物理平均，而不能反映真實的每一幀實時統計。UI線程和GPU線程的處理方式不一樣，這樣物理平均確實是不直觀的做法。
業界很多公司通用的做法是框架層去統計UI線程耗時時間，消息 post 到 UI，然後再post到GPU。但是這種做法有兩個缺陷：一個是等待時間沒有考慮進去，一個是UI 線程非常快，但是 GPU 線程非常慢，UI 線程向 GPU 線程跑消息時最多 Post 兩個消息，這時候 GPU 線程依然處理不過來，UI 線程就不會 Post 消息，但是 UI 線程體現不出來。
字節跳動採用的是“高精度無侵入性能監控方案”：引擎層提供了一套機制，可以知道繪製多少幀，統計你發了多少信號，統計 GPU 線程。另外“無侵入”體現在：框架系統會自動識別性能監控滾動會在什麼時候開始，什麼時候結束。
Flutter Turbo
這個主要是性能提升的方案，比如：消息調度、GC抑制、關閉Semantics、關閉抗鋸齒等，另外為了提高性能，內部有一個 Benchmark 跑分，有了這些方案支持，可以大大的提升應用程序額性能。
圖片透傳優化方案
我個人覺得這個方案還是挺不錯的，非常有借鑑價值，值得學習和研究一下。現有的方式 Image.network加載網絡圖片，傳入一個路徑就可以加載了，然後Dart底層引擎層做解碼操作。另外外接紋理方案也是不錯的，也是可以實現的，但是它沒有在這個基礎上進行改造，性能上還有提升空間。字節跳動的透傳方案是這樣的：使用框架加載圖片，然後生成Bitmap，然後Native和Dart VM共享Bitmap，而不是直接的數據傳過來的，然後Dart引擎再轉成Pixel buffer，這樣一來對性能有很大的提升。包體積優化
大概有這些優化：做了編譯優化；對Flutter產物的數據端做了壓縮，對Skia做了裁剪，不需要的東西刪掉了，引擎庫對一些功能三方庫也做了裁剪。
【雖說看的雲裡霧裡，感覺還是很厲害的樣子。類型一萬個：“臥槽，這麼牛逼！”】
在這次會議上的第3個主題演講中，來自字節跳動的專家還專門對包體積優化做了講解，我會在後面的文章再整理一下分享給大家。
啟動速度優化
修改了引擎代碼，對啟動速度做了優化，幾乎提升了1倍。（雖然很牛逼，但是看不到摸不著，也不知道是如何修改的，我只能說希望早點貢獻給Flutter社區，我們這些吃瓜群眾都來享一下福，沾一點光啊。）
閱讀更多 技術剛剛好 的文章
