移動互聯網這十年，跨平臺技術的演進及 Flutter 的未來

作者 | 袁輝輝

移動跨平臺技術演進

1. 引言

移動互聯網發展十餘年，伴隨著 Android、iOS 等智能手機的不斷普及，移動端已逐步取代 PC 端，成為兵家必爭之地。正所謂“得移動端者得天下”，移動端已成為互聯網領域最大的流量分發入口，一大批互聯網公司正是在這大趨勢下崛起。

2. 為什麼需要跨平臺技術？

伴隨著移動互聯網的高速發展，公司間競爭越來越激烈，如何將好想法快速落地、快速試錯，成為備受關注的問題。提升研發效率、縮短研發週期，保障產品快速試錯並能快速迭代新功能，讓新產品新功能以最快的速度同時抵達 Android、iOS 等多端用戶。

眾所周知，Android 應用採用 Java 或 Kotlin 編寫，iOS 應用採用 Objective-C 或 Swift 編寫，Web 端採用 HTML /CSS/JavaScript 編寫。當需要開發支持多端的應用，每一端都需要獨立研發、測試，一直到上線，以及後續的維護工作，工作量成倍增漲，勢必延長研發週期。

為了解決多端獨立開發的問題，跨平臺技術便應運而生，各大互聯網公司為此都投入大量人力，於是出現了各種跨平臺技術框架，面對移動領域的跨平臺技術方案的層出不窮，又該如何做技術選型呢？

3. 移動端技術選型

作為移動端的跨端技術方案，所關注無外乎以下這4個方面：研發效率、動態性、多端一致性、性能體驗。

• 研發效率：最大化代碼複用，減少多端差異的適配工作量，降低開發成本，專注業務開發，實現“write once，run everywhere”的終極目標。效率提升是貫穿整個業務的生命週期線，即便業務上線後，可持續降低後續的維護成本，加快新feature的迭代速度，這是一個持續的效率收益。當然，這裡不得不說，任何一門新技術在開發啟動學習階段會有一些成本，但上手後的收益是長期的。

• 動態化：突破渠道的更新頻率，可快速迭代新功能，這一點不僅是跨平臺技術的訴求，也是Native技術必備的殺手鐧，這也是評估跨端技術的一個重要考核點。

• 多端一致性：好產品在多端UI設計上，往往是整體風格統一，所以業務方採用原生各自獨立開發完成後，還需額外花不少時間來修改UI以保證多端一致性；可見，各端獨立實現開發方式，帶來的效率滯後，不僅僅是Android和iOS各開發一份代碼的工作量，還有雙端UI的一致性對齊的工作。

• 性能體驗：一般地，跨端技術方案擁有以上多重優勢，但在性能方面比原生流暢更差些。犧牲部分體驗換來效率提升，這一點也是情理之中，試想一下，跨平臺技術方案同時兼得這4點，那麼原生技術恐怕已退出歷史舞臺，早已是跨平臺技術的天下，所以往往跨平臺技術的性能優劣便成為核心指標。

4. 跨平臺技術劃分

對研發效率和體驗的不斷追逐，移動端的跨平臺技術方框架層出不窮，然則天下武功眾多，萬變不離其宗，從其核心本質來劃分，可大致分為以下三大類：

• Web技術：主要依賴於WebView的技術，功能支持受限，性能體驗很差，比如PhoneGap、Cordova、小程序。

• 原生渲染：使用JavaScript作為編程語言，通過中間層轉化為原生控件來渲染UI界面，比如React Native、Weex。

• 自渲染技術：自行實現一套渲染框架，可通過調用skia等方式完成自渲染，而不依賴於原生控件，比如Flutter、Unity。

5. 跨平臺技術演進

跨平臺技術，一直以來是每一個有追求的開發者所追逐的夢想，同時也是守舊者的噩夢，跨平臺的多端一體化方案勢必顛覆現有的原生各端獨立開發模式，接下來列舉眾多的跨平臺技術中最為關鍵的幾個技術方案的演進階段。

從上圖可以看出，技術演進過程大致分以下三個階段：

• 第一階段，採用WebView技術繪製界面的Hybrid混合開發技術，通過JS Bridge 將系統部分能力暴露給 JS 調用，其缺點是性能較差，功能受限，擴展性差，不適合交互複雜的場景，比如Cordova。

• 第二階段，針對WebView界面性能等問題，於是繪製交還原生渲染，僅僅通過JS調用原生控件，相比WebView技術性能體驗更好，這是目前絕大部分跨平臺框架的設計思路，比如React Native、Weex。另外，最近小程序也比較火，第一和第二階段的融合，依然採用WebView作為渲染容器，通過限制Web技術棧的子集，規範化組件使用，並逐步引入原生控件代表WebView渲染，以提升性能。

• 第三階段，雖然通過橋接技術使用原生控件解決了功能受限問題，提升性能體驗，但相比原生體驗差距還是比較大，以及處理平臺差異性非常耗費人力。於是Flutter提出自帶渲染引擎的解決方案，儘可能減少不同平臺間的差異性, 同時媲美原生的高性能體驗，因此業界對 Flutter有著極高的

  關注度。

面對現有的如此多跨平臺方案，為何當下最火的跨平臺技術是Flutter，有哪些優勢呢？

RN、Weex均使用JavaScript作為編程語言，JavaScript作為前端開發語言，在跨平臺開發中可謂大放異彩，利用web技術不僅能開發出網站，也可以開發手機端web應用和移動端應用程序，似有一統三界(Android、iOS、Web)的趨勢，這就是大家常說的“大前端”時代。這些技術方案流暢度不太好，平臺一致性較差，至今還沒能大面積取代原生開發。

Flutter是以Dart語言編寫，開發體驗更接近客戶端，從大家使用反饋來看也是如此，Flutter開發環境這一套的流程對於前端開發來說並不太友好。Flutter的定位同樣是多端一體化，但是以客戶端為首，先磨平Android和iOS雙端開發體驗，再逐步向Web端滲透，從Flutter規劃的Roadmap也能看出，Flutter for web目前仍處於預覽版，Flutter客戶端方向都已經如火如荼上線了不少應用。

在此之前，大家常說“大前端”，對於Flutter技術，在筆者看來稱之為“大移動端”更貼切，Flutter的UI框架優先支持

在跨平臺技術領域，只要挑戰在，技術就不會停滯，伴隨著技術不斷演進與革新，終將走向美好。

6. Flutter技術優勢

Flutter是徹底的跨平臺方案，既沒有采用WebView，也沒有采用JS橋接原生控件，而是自行實現一套UI框架，在引擎底層通過Skia渲染到屏幕。對於UI之外所需要使用的移動設備自身提供的服務，比如相機、定位、屏幕觸摸等，則採用Platform Channels跟原生系統通信的方式來實現。

對於Flutter優勢，回到前面講到移動端技術選型的4要素，研發效率、動態性、多端一致性、性能體驗，分別對應下面這一組詞語。

• 高效率：採用dart語言編寫代碼，雖然剛開始上手需要點時間，但熟練後效率比較高。一套代碼適用多個平臺(Android、iOS、Web)，以及高效的Hot Reload能快速輔助調試；

• 動態化：2017年3月蘋果下發警告郵件，禁止JSPatch等 iOS App熱更新方案，從此iOS動態化成為一個不宜公開討論的話題。同樣地，Flutter引擎在某一個官方版本對動態化做過一些嘗試，但後續基於風險考慮移除，當然並沒有阻礙大家對技術的探索，這裡不方便展開討論；

• 高一致性：實現UI像素級的控制，Flutter渲染引擎依靠跨平臺Skia圖形庫來實現，僅依賴系統圖形繪製相關的接口，比如未來Android會支持vulkan，iOS會支持metal，這些都是通過skia封裝調用。可最大程度上保證不同平臺的體驗一致性，見下圖所示。

• 高性能：渲染性能優於現有的各種跨平臺框架，可媲美原生性能的跨平臺技術方案，Dart代碼執行效率比JS高，通過AOT編譯成平臺原生代碼，渲染採用自渲染skia方案，既不需要JS Bridge橋接，也不需要Art虛擬機參與。再從渲染原理來看看Flutter的高性能的底氣在哪裡。

圖解：

• Android原生框架，通過調用Java Framework層，再調用到skia來渲染界面；

• 其他跨平臺方案(如RN)，通過JSBridge中間層來將JS寫的APP轉換成相應的原生渲染邏輯，可見比Native代碼增加了更多邏輯，性能遜色差於原生框架；

• Flutter框架，APP通過調用Dart Framework層，再直接調用到skia來渲染界面，並沒有經過原生Framework過程，可見其渲染性能並不會弱於Native技術，這是一個性能上限很高的跨平臺技術。

當然，不得不說目前的Flutter確實不夠盡善盡美，會存在一些不夠盡善盡美之處，比如生態不夠健全，包體積問題，但其該方案的上限比較高，想象空間比較大，相信更多開發者參與進來，經過更多打磨，未來會做得更好。

7. 業界發展近況

2017年5月Google I/O大會正式對外公佈Flutter，到2018年12月發佈Flutter1.0，引發全球大量的開發者和企業開始研究Flutter。StackOverflow 2019年的全球開發者文件調查中，Flutter被評選為最受開發者歡迎的框架之一，超過了TensorFlow和Node.js。

目前，全球越來越多的公司已經在大家耳熟能詳的知名APP中使用Flutter技術並落地，尤其國內知名互聯網公司對Flutter投入度很大，社區也是非常活躍。

8. Flutter未來趨勢

目前Flutter主要在移動Android/iOS跨雙端，Flutter 的願景是成為一個多端運行的 UI 框架，能夠支持不僅僅是移動端，還包括Web、桌面、甚至嵌入式設備。在2019 Google I/O 開發者大會上推出的使用 Flutter 開發 Web 應用的框架，同年9月發佈Flutter 1.9，並將Flutter web合入Flutter主倉庫。

從架構圖看，Flutter採用同一個Dart Framework層來統一Flutter C++引擎和Web引擎，最終可以運行在Android，iOS，Browser上，從Flutter引擎代碼不難看出Flutter也是支持Fuchsia操作系統。

《 Android技術架構演進與未來 》文中已介紹過，Fuchsia是Google內部正在開發的一款新的操作系統，採用Flutter作為系統默認的UI框架，也就是說Flutter天然支持Fuchsia，這無疑讓Flutter在眾多的跨平臺方案更有優勢。

從Fuchsia技術架構來看，內核層zircon的基礎LK是專為嵌入式應用中小型系統設計的內核，代碼簡潔，適合嵌入式設備和高性能設備，比如IOT、移動可穿戴設備等，目前這些領域還沒有標準化級別的壟斷者。以及在框架層中有著語音交互、雲端以及智能化等模塊，由此筆者揣測未來Fuchsia率先應用在音控等智能嵌入式設備。

目前大家普遍比較看好的未來兩個技術就是5G和IoT時代。對於5G的需求，很大程度上是因為移動互聯網發展到“IoT時代”的階段。這個發展階段，全球上網設備的數量可能會達到500億個。隨著5G+IOT時代的到來，現在大家比較關注的Flutter包大小也同樣不再是一個問題，或許Flutter技術的生命期比客戶端更長，或許Fuchsia正在馳騁IOT疆場，你所掌握的Flutter技術棧可以無縫遷移，一次彎道超車的機會。

到此，介紹完跨平臺技術演進以及Flutter的優勢。看到這，相信你可能對Flutter技術有一定興趣，為了能讓大家快速瞭解Flutter內部原理而不枯燥，本文不放任何的源碼，通過一系列圖來幫大家從整體架構來快速理解Flutter。

Flutter引擎架構

1. Flutter技術架構

先來看看Flutter整體的技術架構，分為四層，從上之下依次是Dart APP，Dart Framework， C++ Engine，Platform。

Flutter架構最核心的便是Framework（框架）和Engine（引擎）：

• Flutter Framework層：用Dart編寫，封裝整個Flutter架構的核心功能，包括Widget、動畫、繪製、手勢等功能，有Material（Android風格UI）和Cupertino（iOS風格）的UI界面， 可構建Widget控件以及實現UI佈局。

• Flutter Engine層：用C++編寫，用於高質量移動應用的輕量級運行時環境，實現了Flutter的核心庫，包括Dart虛擬機、動畫和圖形、文字渲染、通信通道、事件通知、插件架構等。引擎渲染採用的是2D圖形渲染庫Skia，虛擬機採用的是面嚮對象語言Dart VM，並將它們託管到Flutter的嵌入層。shell實現了平臺相關的代碼，比如跟屏幕鍵盤IME和系統應用生命週期事件的交互。不同平臺有不同的shell，比如Android和iOS的shell。

2. Flutter編譯產物

看完Flutter內部架構，或許你好奇，Flutter不用Android/iOS的本地語言技術開發，Dart編寫完的代碼如何讓不同系統可以識別，最終編譯後得到的產物是什麼呢？

Flutter產物分為Dart業務代碼和Engine代碼各自生成的產物，圖中的Dart Code包含開發者編寫的業務代碼，Engine Code是引擎代碼，如果並沒有定製化引擎，則無需重新編譯引擎代碼。

一份Dart代碼，可編譯生成雙端產物，實現跨平臺的能力。經過編譯工具處理後可生成雙端產物，圖中便是release模式的編譯產物，Android產物是由vm、isolate各自的指令段和數據段以及flutter.jar組成的app.apk，iOS產物是由App.framework和Flutter.framework組成的Runner.app。

這個過程涉及frontendserver、gensnapshot、xcrun、ninja編譯工具。frontendserver前端編譯器會進行詞法分析、語法分析以及相關全局轉換等工作，將dart代碼轉換為AST(抽象語法樹)，並生成app.dill格式的dart kernel。gensnapshot經過CHA、內聯等一系列執行流的優化，根據中間代碼生成優化後的FlowGraph對象，再轉換為具體相應系統架構（arm/arm64等）的二進制指令。

3. Flutter引擎啟動

既然瞭解了Flutter的編譯產物，那你或許又好奇，Flutter這臺引擎如何發動的，怎麼跟Native銜接呢？

這裡以Android為例，熟悉Android的開發者，應該都瞭解APP啟動過程，會執行Application和Activity的onCreate方法，FlutterApplication和FlutterActivity的onCreate方法正是連接Native和Flutter的樞紐。

FlutterApplication.java的onCreate過程主要完成初始化配置、加載引擎libflutter.so、註冊JNI方法；

• FlutterActivity.java的onCreate過程，通過FlutterJNI的AttachJNI方法來初始化引擎Engine、Dart虛擬機、Isolate、taskRunner等對象。再經過層層處理最終調用main.dart中main方法，執行runApp(Widget app)來處理整個Dart業務代碼。

• Flutter引擎啟動中會創建有4個TaskRunner以及創建虛擬機，分別來看看它們的工作原理。

4. TaskRunner工作原理

Flutter引擎啟動過程，會創建UI/GPU/IO這3個線程，會為這些線程依次創建MessageLoop對象，啟動後處於epoll_wait等待狀態。對於Flutter的消息機制跟Android原生的消息機制有很多相似之處，都有消息(或者任務)、消息隊列(或任務隊列)以及Looper；有一點不同的是Android有一個Handler類，用於發送消息以及執行回調方法，相對應Flutter中有著相近功能的便是TaskRunner。

上圖是從源碼中提煉而來的任務處理流程，比官方流程圖更容易理解一些複雜流程的時序問題，後續會專門講解箇中原由。Flutter的任務隊列處理機制跟Android的消息隊列處理相通，只不過Flutter分為Task和MicroTask兩種類型，引擎和Dart虛擬機的事件以及Future都屬於Task，Dart層執行scheduleMicrotask所產生的屬於Microtask。

每次Flutter引擎在消費任務時調用FlushTasks方法，遍歷整個延遲任務隊列delayedtasks，將已到期的任務加入task隊列，然後開始處理任務。

• Step 1: 檢查task，當task隊列不為空，先執行一個task；

• Step 2: 檢查microTask，當microTask不為空，則執行microTask；不斷循環Step 2 直到microTask隊列為空，再回到執行Step 1。

可簡單理解為先處理完所有的Microtask，然後再處理Task。因為scheduleMicrotask方法的調用自身就處於一個Task，執行完當前的task，也就意味著馬上執行該Microtask。

瞭解了其工作機制，再來看看這4個Task Runner的具體工作內容。

• Platform Task Runner：運行在Android或者iOS的主線程，儘管阻塞該線程並不會影響Flutter渲染管道，平臺線程

  建議不要執行耗時操作；否則可能觸發watchdog來結束該應用。比如Android、iOS都是使用平臺線程來傳遞用戶輸入事件，一旦平臺線程被阻塞則會引起手勢事件丟失。

• UI Task Runner: 運行在ui線程，比如1.ui，用於引擎執行root isolate中的所有Dart代碼，執行渲染與處理Vsync信號，將widget轉換生成Layer Tree。除了渲染之外，還有處理Native Plugins消息、Timers、Microtasks等工作；

• GPU Task Runner：運行在gpu線程，比如1.gpu，用於將Layer Tree轉換為具體GPU指令，執行設備GPU相關的skia調用，轉換相應平臺的繪製方式，比如OpenGL, vulkan, metal等。每一幀的繪製需要UI Runner和GPU Runner配合完成，任何一個環節延遲都可能導致掉幀；

• IO Task Runner：運行在io線程，比如1.io，前3個Task Runner都不允許執行耗時操作，該Runner用於將圖片從磁盤讀取出來，解壓轉換為GPU可識別的格式後，再上傳給GPU線程。為了能訪問GPU，IO Runner跟GPU Runner的Context在同一個ShareGroup。比如ui.image通過異步調用讓IO Runner來異步加載圖片，該線程不能執行其他耗時操作，否則可能會影響圖片加載的性能。

5. Dart虛擬機工作

Flutter引擎啟動會創建Dart虛擬機以及Root Isolate。DartVM自身也擁有自己的Isolate，完全由虛擬機自己管理的，Flutter引擎也無法直接訪問。Dart的UI相關操作，是由Root Isolate通過Dart的C++調用，或者是發送消息通知的方式，將UI渲染相關的任務提交到UIRunner執行，這樣就可以跟Flutter引擎相關模塊進行交互。

何為Isolate，從字面上理解是“隔離”，isolate之間是邏輯隔離的。Isolate中的代碼也是按順序執行，因為Dart沒有共享內存的併發，沒有競爭的可能性，故不需要加鎖，也沒有死鎖風險。對於Dart程序的併發則需要依賴多個isolate來實現。

圖解：

• isolate堆是運該isolate中代碼分配的所有對象的GC管理的內存存儲；

• vm isolate是一個偽isolate，裡面包含不可變對象，比如，true，false；

• isolate堆能引用vm isolate堆中的對象，但vm isolate不能引用isolate堆；

• isolate彼此之間不能相互引用；

• 每個isolate都有一個執行dart代碼的Mutator thread，一個處理虛擬機內部任務(比如GC, JIT等)的helper thread；可見，

  isolate是擁有內存堆和控制線程，虛擬機中可以有很多isolate，但彼此之間內存不共享，無法直接訪問，只能通過dart特有的Port端口通信；isolate除了擁有一個mutator控制線程，還有一些其他輔助線程，比如後臺JIT編譯線程、GC清理/併發標記線程。

6. Widget架構概覽

Flutter引擎啟動後執行Dart業務，是通過runApp(Widget app)方法，那Widget又是什麼呢？

Widget是所有Flutter應用程序的基石，Widget可以是一個按鈕，一種字體或者顏色，一個佈局屬性等，在Flutter的UI世界可謂是“萬物皆Widget”。常見的Widget子類為StatelessWidget(無狀態)和StatefulWidget(有狀態)：

• StatelessWidget：內部沒有保存狀態，UI界面創建後不會發生改變；

• StatefulWidget：內部有保存狀態，當狀態發生改變，調用setState方法會觸發StatefulWidget的UI發生更新，對於自定義繼承自StatefulWidget的子類，必須要重寫createState方法。

三棵樹

圖解：

• Widget是為Element描述需要的配置， 負責創建Element，決定Element是否需要更新。Flutter Framework通過差分算法比對Widget樹前後的變化，決定Element的State是否改變。當重建Widget樹後並未發生改變， 則Element不會觸發重繪，則就是Widget樹的重建並不一定會觸發Element樹的重建。

• Element表示Widget配置樹的特定位置的一個實例，同時持有Widget和RenderObject，負責管理Widget配置和RenderObject渲染。Element狀態由Flutter Framework管理， 開發人員只需更改Widget即可。

• RenderObject表示渲染樹的一個對象，負責真正的渲染工作，比如測量大小、位置、繪製等都由RenderObject完成。

可見，開發者通過Widget配置，Framework通過比對Widget配置來更新Element，最後調度RenderObject Tree完成佈局排列和繪製。

7. 渲染原理

Dart的UI採用Widget來實現，最終轉換為RenderObject，那界面又是如何渲染的呢？

渲染過程，UI線程完成佈局、繪製操作，生成Layer Tree；GPU線程執行合成並光柵化後交給GPU來處理，其中幾個關鍵步驟：

• Animate: 遍歷_transientCallbacks，執行動畫回調方法；

• Build: 對於dirty的元素會執行build構造，沒有dirty元素則不會執行，對應於buildScope

• Layout: 計算渲染對象大小和位置，對應於flushLayout，這個過程可能會嵌套再調用build操作；

• Compositing bits: 更新具有髒合成位的任何渲染對象， 對應於flushCompositingBits；

• Paint: 將繪製命令記錄到Layer， 對應於flushPaint；

• Compositing: 將Compositing bits發送給GPU， 對應於compositeFrame。

GPU線程通過skia向GPU硬件繪製一幀的數據，GPU將幀信息保存到FrameBuffer裡面，然後視頻控制器會根據VSync信號從FrameBuffer取幀數據傳遞給顯示器，從而顯示出最終的畫面。

8. Platform Channels

Flutter框架提供了UI的控件支持，對於APP除了UI還有其他依賴於Native平臺的支持，比如調用Camera的功能，該怎麼辦呢？為此，Flutter通過提供Platform Channel的功能，使得Dart代碼具備與Native交互的能力。

Platform Channel用於Flutter與Native之間的消息傳遞，整個過程的消息與響應是異步執行，不會阻塞用戶界面。Flutter引擎框架已完成橋接的通道，這樣開發者只需在Native層編寫定製的Android/iOS代碼，即可在Dart代碼中直接調用，這也就是Flutter Plugin插件的一種形式。

結束語

科技不斷在進步，技術不斷髮展，移動跨平臺技術幾乎從Android、iOS誕生不久便出現，已發展快10年。時至今日，兼具跨端高效率與高性能體驗的Flutter力壓群雄，嶄露頭角，已然成為當下最熱門的移動端新技術，全球越來越多的公司在Flutter技術佈局並落地產品應用，社區也非常活躍。

筆者之前一直從事於Android操作系統底層研發工作，今年剛接觸Flutter，Flutter作為一門全新的跨平臺技術框架，不斷深究會發現這是一個小型系統，涉及到的技術很廣：

• 編譯技術如何將dart代碼轉換為AST(抽象語法樹)，如何彙編轉換為機器碼，打包成產物是什麼？

• Flutter這臺引擎如何發動的，怎麼跟Native原生系統銜接運行，如何識別產物並加載到內存？

• 引擎啟動後，TaskRunner如何分發任務，跟原生系統消息機制有什麼關係？

• Dart虛擬機如何管理內存，跟isolate又有什麼關係？

• 開發者編寫的Widget控件如何渲染到屏幕上？

• Flutter如何通過plugin支持移動設備提供的服務？

以上問題本文都已逐一回答，如果僅僅是用Flutter做業務開發，並不需要掌握這麼深度技術，不過，知其然知其所以然，能讓你遊刃有餘。本文講述跨平臺技術的過去與未來，以及從宏觀架構解讀Flutter內部原理，後續有時間將更深入的技術細節以及實戰經驗角度來跟大家揭秘更多Flutter技術。

隨著5G+IOT時代的到來，Fuchsia系統或許發力IOT新戰場，你所掌握的Flutter技術棧可以無縫遷移，這是一次彎道超車的機會。即便Fuchsia落敗，相信只要深扎Flutter系統技術的精髓，其他任何的移動端新技術都可以輕鬆快速地掌握。

最後，用一句話來結束本次分享，“有時候，你選擇一個方向，不是因為它一定會成為未來，而是它有可能成為不一樣的未來。”

【END】

閱讀更多 CSDN 的文章

關鍵字: 演進 互聯網