本文原文由“戀貓月亮”原創釋出，原題為《移動端跨平臺開發的深度解析》，本次重新整理後，為了優化閱讀體驗，內容略有改動，感謝原作者的無私分享。

1、前言

跨平臺一直是老生常談的話題，cordova、ionic、react-native、weex、kotlin-native、flutter等跨平臺框架的百花齊放，頗有一股推倒原生開發者的勢頭。

為什麼我們需要跨平臺開發？ 本質上，跨平臺開發是為了增加程式碼複用，減少開發者對多個平臺差異適配的工作量，降低開發成本，提高業務專注的同時，提供比web更好的體驗。嗯～通俗了說就是：省錢、偷懶。

目前移動端跨平臺開發中，備受關注的方案大致歸納為以下幾種情況：

1）react native、weex均使用JavaScript作為程式語言，目前JavaScript在跨平臺開發中，可謂佔據半壁江山，大有“一統天下”的趨勢；

2）kotlin-native開始支援 iOS 和 Web 開發，（kotlin已經成為android的一級語言）也想嘗試“一統天下”；

3）flutter是Google跨平臺移動UI框架，Dart作為谷歌的親兒子，毫無疑問Dart成為flutter的程式語言。作為巨頭新生兒，在flutter官網也可以看出，flutter同樣“心懷天下”（可支援Web端、Android端、iOS端等）。

本篇主要以react-native、weex、flutter，深入聊聊當前最火的這3種跨平臺移動開發方案的實現原理、現狀與未來。至於為什麼只講它們，因為對比ionic、phoneGap，它們更於 “naive” (˶ ⁻̫ ˵)。看完本篇，相信你會對於當下跨平臺移動開發的現狀、實現原理、框架的選擇等有更深入的理解。

（本文同步釋出於：http://www.52im.net/thread-1870-1-1.html）

2、React Native的原理與特性介紹

React Native技術關鍵詞：

1）Facebook 出品；

2）JavaScript語言；

3）JSCore引擎；

4）React設計模式；

5）原生渲染。

2.1 理念架構

“Learn once, write anywhere” ，代表著 Facebook對 react native 的定義：學習 react ，同時掌握 web 與 app 兩種開發技能。 react native 用了 react 的設計模式，但UI渲染、動畫效果、網路請求等均由原生端實現。開發者編寫的js程式碼，通過 react native 的中間層轉化為原生控制元件和操作，比ionic等跨平臺應用，大大提高了的使用者體驗。

總結起來其實就是：React Native是利用 JS 來呼叫 Native 端的元件，從而實現相應的功能。

如下圖所示，react native 的跨平臺是實現主要由三層構成，其中 C++ 實現的動態連結庫(.so)，作為中間適配層橋接，實現了js端與原生端的雙向通訊互動。這裡最主要是封裝了 JavaScriptCore 執行js的解析，而 react native 執行在JavaScriptCore中，所以不存在瀏覽器相容的問題。

其中在IOS上直接使用內建的javascriptcore， 在Android 則使用webkit.org官方開源的jsc.so。

2.2 實現原理

和前端開發不同：react native 所有的標籤都不是真實控制元件，JS程式碼中所寫控制元件的作用，類似 Map 中的 key 值。JS端通過這個 key 組合的 Dom ，最後Native端會解析這個 Dom ，得到對應的Native控制元件渲染，如 Android 中 標籤對應 ViewGroup 控制元件。

在 react native 中，JS端是執行在獨立的執行緒中（稱為JS Thread ）。JS Thread 作為單執行緒邏輯，不可能處理耗時的操作。那麼如 fetch 、圖片載入 、 資料持久化 等操作，在 Android 中實際對應的是 okhttp 、Fresco 、SharedPreferences等。而跨執行緒通訊，也意味著 Js Thread 和原生之間互動與通訊是非同步的。

可以看出，react native 跨平臺的關鍵在於C++層，開發人員大部分時候，只專注於JS 端的程式碼實現。 在原生端提供的各種 Native Module 模組（如網路請求，ViewGroup控制元件），和 JS 端提供的各種 JS Module（如JS EventEmiter模組），都會在C++實現的so中儲存起來，雙方的通訊通過C++中的儲存的對映，最終實現兩端的互動。通訊的資料和指令，在中間層會被轉為String字串傳輸，雙向的呼叫流程如下圖。

2.3 打包載入

最終：JS程式碼會被打包成一個 bundle 檔案，自動新增到 App 的資源目錄下。react native 的打包指令碼目錄為/node_modules/react-native/local-cli，打包最後會通過 metro 模組壓縮 bundle 檔案。而bundle檔案只會打包js程式碼，自然不會包含圖片等靜態資源，所以打包後的靜態資源，其實是被拷貝到對應的平臺資原始檔夾中。

其中圖片等存在資源的對映規則，比如放在 react native 專案根目錄下的 img/pic/logo.png 的資源，編譯時，會被重新命名後，根據大小 merged 到對應的是drawable目錄下，修改名稱為img_pic_logo.png。

打包Android和IOS，肯定需要相應的平臺專案存在，在 react-native init 時建立的專案，就已經包含了 android 和 ios 的模版工程，打包完的工程會載入bundle檔案，然後啟動專案，如下圖。這裡就不展開了，有興趣的可以看QQ空間移動開發團隊分享的《React Native For Android 架構初探》。

3、WEEX的原理與特性介紹

WEEX技術關鍵詞：

1）Alibaba 出品；

2）JavaScript語言；

3）JS V8引擎；

4）Vue設計模式；

5）原生渲染。

3.1 理念架構

“Write once, run everywhere”：weex的定義就像是：寫個 vue 前端，順便幫你編譯成效能還不錯的 apk 和 ipa（當然，現實有時很骨感）。基於 Vue 設計模式，支援 web、android、ios 三端，原生端同樣通過中間層轉化，將控制元件和操作轉化為原生邏輯來提高使用者體驗。

在 weex 中，主要包括三大部分：JS Bridge、Render、Dom，分別對應WXBridgeManager、WXRenderManager、WXDomManager，三部分通過WXSDKManager統一管理。其中 JS Bridge 和 Dom 都執行在獨立的 HandlerThread 中，而 Render 執行在 UI 執行緒。

JS Bridge 主要用來和 JS 端實現進行雙向通訊，比如把 JS 端的 dom 結構傳遞給 Dom 執行緒。Dom 主要是用於負責 dom 的解析、對映、新增等等的操作，最後通知UI執行緒更新。而 Render 負責在UI執行緒中對 dom 實現渲染。

3.2 實現原理

和 react native一樣——weex 所有的標籤也不是真實控制元件，JS 程式碼中所生成存的 dom，最後都是由 Native 端解析，再得到對應的Native控制元件渲染，如 Android 中 標籤對應 WXTextView 控制元件。

weex 中檔案預設為 .vue ，而 vue 檔案是被無法直接執行的，所以 vue 會被編譯成 .js 格式的檔案，Weex SDK會負責載入渲染這個js檔案。Weex可以做到跨三端的原理在於：在開發過程中，程式碼模式、編譯過程、模板元件、資料繫結、生命週期等上層語法是一致的。不同的是在 JS Framework 層的最後，web 平臺和 Native 平臺，對 Virtual DOM 執行的解析方法是有區別的。

實際上，在 Native 中對 bundle 檔案的載入大致經歷以下階段：

1）weex 接收到 js 檔案以後，JS Framework 根據檔案為 Vue 模式，會呼叫weex-vue-framework 中提供的 createInstance方法建立例項。(也可能是Rax模式)；

2）createInstance 中會執行 Js Entry 程式碼裡 new Vue() 建立一個元件，通過其 render 函式建立出 Virtual DOM 節點；

3）由JS V8 引擎上解析 Virtual DOM ，得到 Json 資料傳送至 Dom 線，這裡輸出 Json 也是方便跨端的資料傳輸；

4）Dom 執行緒解析 Json 資料，得到對應的 WxDomObject，然後建立對應的WxComponent 提交 Render；

5）Render在原生端最終處理處理渲染任務，並回撥裡JS方法。

得益於上層的統一性，只是通過 weex-vue-framework 判斷是由Vue.js 生成真實的 Dom ，還是通過 Native Api 渲染元件，weex 一定程度上上，用JS 實現了  vue 一統天下的效果。

weex 在原生渲染 Render 時，在接收到渲染指令後，會逐步將資料渲染成原生元件。Render 通過解析渲染資料的描述，然後分發給不同的模組。

比如：控制元件渲染屬於 dom 模組中，頁面跳轉屬於navigator模組等。模組的渲染過程並非一個執行完，再執行另一個的流程，而是類似流式的過程。如上一個 的元件還沒渲染好，下一個

的渲染又發了過來。這樣當一個元件的巢狀元件很多時，或者可以看到這個大元件內的UI，一個一個渲染出來的過程。

weex 比起react native，主要是在JS V8的引擎上，多了 JS Framework 承當了重要的職責，使得上層具備統一性，可以支援跨三個平臺。

總的來說JS Framework主要負責的是：

1）管理Weex的生命週期；

2）解析JS Bundle，轉為Virtual DOM，再通過所在平臺不同的API方法構建頁面；

3）進行雙向的資料互動和響應。

3.3 打包

weex 作為 react-native 之後出現的跨平臺實現方案，自然可以站在前人的肩膀上優化問題，比如：Bundle檔案過大問題。

Bundle檔案的大小，很大程度上影響了框架的效能，而 weex 選擇將 JS Framework 整合到 WeexSDK 中，一定程度減少了JS Bundle的體積，使得 bundle 裡面只保留業務程式碼。

打包時，weex 是通過 webpack 打包出 bundle 檔案的。bundle 檔案的打包和 entry.js 檔案的配置數量有關，預設情況下之後一個 entry 檔案，自然也就只有一個bundle檔案。

在 weex 專案的 webpack.common.conf.js 中可以看到，其實打包也是區分了 webConfig 和 weexConfig 的不同打包方式。如下圖，其中weexEntry 就是 weex 打包配置的地方，可以看到本來已經有 index 和 entry.js 存在了。如果有需要，可配置上你需要的打包頁面，具體這裡就不詳細展開了。有興趣可看《Weex原理之帶你去蹲坑》。

4、Flutter的原理與特性介紹

Flutter技術關鍵詞：

1）Google 出品；

2）Dart語言；

3）Flutter Engine引擎；

4）響應式設計模式；

5）原生渲染。

Flutter 是谷歌2018年釋出的跨平臺移動UI框架。相較於本人已經在專案中使用過 react native 和 Weex，Flutter目前僅僅是簡單執行過Demo，畢竟還是beta 階段，這裡更多的聊一下它的實現機制和效果。

與 react native 和 weex 的通過 Javascript 開發不同，Flutter 的程式語言是Drat，所以執行時並不需要 Javascript 引擎，但實際效果最終也通過原生渲染。

如上圖，Flutter 主要分為 Framework 和 Engine，我們基於Framework 開發App，執行在 Engine 上。Engine 是 Flutter 的獨立虛擬機器，由它適配和提供跨平臺支援，目前猜測 Flutter 應用程式在 Android 上，是直接執行 Engine 上 所以在是不需要Dalvik虛擬機器（這是比kotlin更徹底，拋棄JVM的糾纏？）

如下圖，得益於 Engine 層，Flutter 甚至不使用移動平臺的原生控制元件， 而是使用自己 Engine 來繪製 Widget （Flutter的顯示單元），而 Dart 程式碼都是通過 AOT 編譯為平臺的原生程式碼，所以 Flutter 可以 直接與平臺通訊，不需要JS引擎的橋接。同時 Flutter 唯一要求系統提供的是 canvas，以實現UI的繪製。咦？這麼想來，支援web端也沒問題吧！

在Flutter中，大多數東西都是widget，而widget是不可變的，僅支援一幀，並且在每一幀上不會直接更新，要更新而必須使用Widget的狀態。無狀態和有狀態 widget 的核心特性是相同的，每一幀它們都會重新構建，有一個State物件，它可以跨幀儲存狀態資料並恢復它。

Flutter 上 Android 自帶了 Skia，Skia是一個 2D的繪圖引擎庫，跨平臺，所以可以被嵌入到 Flutter的 iOS SDK中，也使得 Flutter Android SDK要比 iOS SDK小很多。

熱門話題：為什麼Flutter會選擇 Dart作為開發語言？

八卦訊息認為：“是因為 Drat 專案組就在 Flutter 隔壁而被選上”。

實際上真實的原因是：早期的Flutter團隊評估了十多種語言，並選擇了Dart，因為它符合他們構建使用者介面的方式。

Dart之所以成為Flutter不可或缺的一部分，根本原因還是因為其具有以下特性：

1）Dart是AOT（Ahead Of Time）編譯的，編譯成快速、可預測的原生程式碼，使Flutter幾乎都可以使用Dart編寫。這不僅使Flutter變得更快，而且幾乎所有的東西（包括所有的小部件）都可以定製；

2）Dart也可以JIT（Just In Time）編譯，開發週期異常快，工作流顛覆常規（包括Flutter流行的亞秒級有狀態熱過載）；

3）Dart可以更輕鬆地建立以60fps執行的流暢動畫和轉場。Dart可以在沒有鎖的情況下進行物件分配和垃圾回收。就像JavaScript一樣，Dart避免了搶佔式排程和共享記憶體（因而也不需要鎖）。由於Flutter應用程式被編譯為原生程式碼，因此它們不需要在領域之間建立緩慢的橋樑（例如，JavaScript到原生程式碼）。它的啟動速度也快得多；

4）Dart使Flutter不需要單獨的宣告式佈局語言，如JSX或XML，或單獨的視覺化介面構建器，因為Dart的宣告式程式設計佈局易於閱讀和視覺化。所有的佈局使用一種語言，聚集在一處，Flutter很容易提供高階工具，使佈局更簡單；

5）開發人員發現Dart特別容易學習，因為它具有靜態和動態語言使用者都熟悉的特性。

並非所有這些功能都是Dart獨有的，但它們的組合卻恰到好處，使Dart在實現Flutter方面獨一無二。因此，沒有Dart，很難想象Flutter像現在這樣強大。

有關此話題的詳細文章請見《為什麼Flutter會選擇 Dart ？》。

5、React Native、weex、Flutter 3種方案橫向對比

這算是互相傷害的環節了吧。(///▽///)

5.1 最終程式大小

以Android平臺為例，上面Apk大小是通過 react-native init、weex create 和 flutter 建立出的工程後，直接不新增任何程式碼，打包出來的 release 簽名 apk 大小。從下圖可以看出，其中大比例都是在so庫。

5.2 社群支援

react native 作為 Facebook 主力開源專案之一，至今已有各類豐富的第三方庫，甚至如 realm、lottie 等開源專案也有 react native 相關的版本，社群實際無需質疑。當然，因為並完全正統開發平臺，第三庫的健壯性和相容性有時候總是良莠不齊。

weex 其實有種生錯在國內的感覺。其實 weex 的設計和理念都很優秀，效能也不錯，但是對比 react native 的第三方支援，就顯得有點後媽養的。2016年開源至今，社群和各類文件都顯得有點疲弱，作為跨平臺開發人員，大多時候肯定不會希望，需要頻繁的自己增加原生功能支援，因為這樣的工作一多，反而會與跨平臺開發的理念背道而馳，帶來開發成本被維護難度增加。

Flutter 目前還處理beta階段，但是谷歌的號召力一直很可觀，這一點無需質疑。

5.3 效能區別

理論上 flutter 的效能應該是最好的，但是目前實際體驗中，卻並沒有感受出來太大的差距，和 react native（0.5.0之後）、weex 在效能上個人體驗差異不是很大。當然，這裡並沒有實測渲染的毫秒時間和幀率資料。

5.4 其他區別

Weex的多頁面實現問題：

weex 在 native 端是不支援 的，這一點和 react-native 不同在與，如果在 native 需要實現頁面跳轉，使用 vue-router 將會慘不忍睹：返回後頁面不做特別處理時，是會空白一片。參考官方Demo playground，native 端 的採用 weex.requireModule(`navigator`) 跳轉 Activity 是才正確實現。

同時，weex中 navigator 跳轉的設計，也導致了多頁面的頁面間通訊的差異。weex在多頁面下的資料通訊，是通過url實現的，比如file://assets/dist/SecondPage.js?params=0，而vuex和vue-router在跨頁面是無法共用的；而 react native 在跨 Actvity 使用時，因為是同一個bundle檔案，只要 manager 相同，那麼 router 和 store 時可以照樣使用的，資料通訊方式也和當個 Actvity 沒區別。

專案模板：

weex 和 react native 模板程式碼模式也不同。weex 的模板是從 cordova 模式修改過來的，根據platform需求，用命令新增固定模組，而在 .gitignore 對 platforms 資料夾是忽略跟蹤。 react native 在專案建立時模版就存在了，特別是新增第三方外掛原生端支援時，會直接修改模板程式碼，git程式碼中也會新增跟蹤修改。

6、未來趨勢展望

我們選擇框架的時候，很多時候會關注框架的成熟度和生命力不是麼(◐‿◑)。

6.1 React Native

“Airbnb 宣佈放棄使用 React Native，迴歸使用原生技術” : Airbnb 作為 react native 平臺上最大的支持者之一，其開源的lottie 同樣是支援原生和 react native。

Airbnb 在宣佈放棄的文中，也對 react native 的表示了很大量的肯定，而使得他們放棄的理由，其實主要還是集中於專案龐大之後的維護困難，第三方庫的良莠不齊，相容上需要耗費更多的精力導致放棄。

ps： Lottie庫Airbnb出的是一個能夠幫助解析AE匯出的包含動畫資訊的json檔案。這很好的解決了一個矛盾，設計師可以更專注的設計出各種炫酷的動畫效果，而開發只需要將其加入支援即可。

Facebook 正在重構 React Native，將重寫大量底層。在經歷了開源協議風波後，可以看出 Facebook 對於 react native 還是很看重的。

這些底層重構優化的地方，主要集中於：

1）首先：改變執行緒模型。UI 更新不再需要在三個不同的執行緒上執行，而是可以在任意執行緒上同步呼叫 JavaScript 進行優先更新，同時將低優先順序工作推出主執行緒，以便保持對 UI 的響應；

2）其次：將非同步渲染功能引入 React Native 中，允許執行多個渲染並簡化非同步資料處理；

3）最後：簡化橋接，讓它更快、更輕量。原生和 JavaScript 之間的直接呼叫效率更高，並且可以更輕鬆地構建除錯工具，如跨語言堆疊跟蹤。

其他React Native相關文章：

從Android到React Native開發（一、入門）

從Android到React Native開發（二、通訊與模組實現）

從Android到React Native開發（三、自定義原生控制元件支援）

從Android到React Native開發（四、打包流程和釋出為Maven庫）

6.2 Weex

沒有死！阿里公開Weex技術架構，還開源了一大波元件。 2018年初的新聞可以看出，weex 的遭遇有點類似曾經的 Duddo（Dubbo因為內部競爭被阿里一度放棄維護），這波詐屍後 weex 被託管到了Apache，而github的 weexteam 如今也還保持著更新，希望後續能有多好的發展，拭目以待吧。

6.3 Flutter

Flutter 是 Google 跨平臺移動UI框架，Dart作為谷歌的親兒子在 Flutter 中使用，並且谷歌新作業系統 Fuchsia 支援 Dart，使用 Flutter 作為操作UI框架。這些集合到一起難免讓你懷疑 Android 是否要被谷歌拋棄的想法。

或者如今先 Android 等平臺上推廣 Flutter 與 Dart，就是為了以後跟好的過渡到新系統上，畢竟開發者是作業系統的生命源泉之一。而 Java 與 JVM 或者可以被谷歌完全拋開。當然，目前看起來 Flutter 貌似還缺少一些語法糖，巢狀下來的程式碼有點不忍直視，或者到正式版之後，我們更能感受出它的美麗吧。

（原文連結：https://www.jianshu.com/p/7e0bd4708ba7，內容有改動）

附錄：更多移動端開發精華文章

《通俗易懂，理解行動網路的“弱”和“慢”》

《史上最全移動弱網路優化方法總結》

《從客戶端的角度來談談移動端IM的訊息可靠性和送達機制》

《現代移動端網路短連線的優化手段總結：請求速度、弱網適應、安全保障》

《騰訊技術分享：社交網路圖片的頻寬壓縮技術演進之路》

《QQ音樂團隊分享：Android中的圖片壓縮技術詳解（上篇）》

《QQ音樂團隊分享：Android中的圖片壓縮技術詳解（下篇）》

《騰訊原創分享(一)：如何大幅提升行動網路下手機QQ的圖片傳輸速度和成功率》

《騰訊原創分享(二)：如何大幅壓縮行動網路下APP的流量消耗（上篇）》

《騰訊原創分享(三)：如何大幅壓縮行動網路下APP的流量消耗（下篇）》

《基於社交網路的Yelp是如何實現海量使用者圖片的無失真壓縮的？》

《騰訊技術分享：騰訊是如何大幅降低頻寬和網路流量的(圖片壓縮篇)》

《騰訊技術分享：騰訊是如何大幅降低頻寬和網路流量的(音視訊技術篇)》

《為什麼說即時通訊社交APP創業就是一個坑？》

《字元編碼那點事：快速理解ASCII、Unicode、GBK和UTF-8》

《全面掌握移動端主流圖片格式的特點、效能、調優等》

《最火移動端跨平臺方案盤點：React Native、weex、Flutter》

>> 更多同類文章 ……

（本文同步釋出於：http://www.52im.net/thread-1870-1-1.html）