移動客戶端跨平臺開發(fā)方案探索

本文是 Piasy 原創(chuàng)，發(fā)表于 https://blog.piasy.com，請閱讀原文支持原創(chuàng) https://blog.piasy.com/2017/12/16/Mobile-Client-Cross-Platform-Development/

跨平臺開發(fā)想必很多朋友都聽說過，甚至實踐過，這里我就不過多介紹相關的背景了，Java 的 Slogan 完美詮釋了這一愿景：Write once, run anywhere！

提到這個話題，大家首先想到的可能是 React Native，不過本文并不是 RN 教程。本文旨在探索我關注到的幾種比較靠譜的移動客戶端跨平臺開發(fā)方案，當然 RN 是其中必不可少的一部分。

完美的跨平臺開發(fā)方案自然是一行平臺相關的代碼都沒有，但這個要求稍顯苛刻，很多時候退一步海闊天空，在移動客戶端跨平臺開發(fā)這個場景下也是這樣。所以我們的目標應該是盡可能地減少平臺相關代碼的開發(fā)，最大程度復用核心邏輯代碼。

此外，客戶端的開發(fā)可以分為兩部分：業(yè)務邏輯與界面交互。由于不同的平臺（Android、iOS、Web）GUI 系統(tǒng)差異較大，通常來說界面交互共享代碼更加困難。這對于 APP 開發(fā)確實是個不小的問題，但對于 SDK 開發(fā)來說卻影響較小。

可選方案

接下來我們先看看有哪些可選方案：

React Native (Javascript)
Flutter (Dart)
J2ObjC + GWT (Java)
Djinni + WebAssembly (C++)

其實如果要把小程序列入其中，也未嘗不可，畢竟能在不同平臺的微信和支付寶里運行，也堪稱跨平臺了。

注：上述各項技術的基本概念本文不會過多介紹，請大家自行查閱官方文檔。

2017.12.22 更新：之前誤以為 Weex 是和小程序一樣的技術，但它是和 RN 對標的呀，實在汗顏，日后再做補充……

React Native

RN 由 Facebook 開源，F(xiàn)acebook 內部很多項目在用，工業(yè)界也有不少公司和團隊都在使用。這樣的項目，坑肯定有，但一定不會沒人填。

RN 的主要優(yōu)勢有兩大部分，一是 React 本身的優(yōu)勢，二是將「React」「Native 化」之后跨平臺的優(yōu)勢。這里我主要總結下 React 本身的優(yōu)勢（或者說特性）：

組件化：組件根據(jù)狀態(tài)（state）和屬性（props）確定 UI，各種組件組成 view tree；
單向數(shù)據(jù)流：props 只允許自頂向下傳遞，父組件設置子組件的 props；交互事件則自底向上拋出，父組件收到子組件內的交互事件后更新 state，觸發(fā)整個 view tree 的更新（重新設置子組件的 props）；
Virtual DOM：view tree 和實際 DOM tree 獨立，通過計算差量，每次刷新界面只更新變化的 DOM 元素，提高效率；
JSX 語法、render 函數(shù)讓代碼更易于理解和維護；

我覺得下面這幅圖形象地表達了 React 的設計精髓：building large applications with data that changes over time。

image

內部原理：

寫的是 JS 代碼，實際運行的也是 JS 代碼，在 JavaScriptCore VM 中運行（而不是 WebView）；
JS 代碼里的 View 實際會使用 native View（在 RN 的上下文中，native 指的是原生），映射關系是可以控制的；
- 有一個 native View 市場，可以發(fā)現(xiàn)輪子、發(fā)布輪子；
支持 JS 代碼和 native 代碼互相調用，三大特點：異步，批量，序列化；
- 實際上 native 化靠的正是 JS 和 native 互相調用（RN 內部實現(xiàn)）；
- 雙向調用都是異步的；
- 跨邊界調用實際上是消息收發(fā)和處理，由于跨邊界存在開銷，所以批量處理減小開銷；
- 不跨邊界共享可變對象，而是跨邊界交換可序列化的消息；
跨邊界調用通過 bridge 層實現(xiàn)；
- 把 native 模塊對象注冊到 bridge，之前 JS 代碼里面的函數(shù)調用就可以執(zhí)行了（JS 是動態(tài)語言，運行時有函數(shù)/屬性，就能訪問）；
- 跨邊界調用實際上是消息收發(fā)和處理，例如 JS 調用 native 的一個函數(shù)，就往一個特殊的隊列里放入一條消息，bridge 取出消息后，利用反射，調用 native 函數(shù)，反之亦然；
- bridge 可以替換 JS runtime，這樣就變得很靈活了，例如可以在單獨的 WebKit 進程中運行，可以在 Chrome 里面調試 RN APP；
- 下圖形象地展示了跨邊界調用的過程：
image

總結：RN 利用 JavascriptCore VM 在 iOS/Android 系統(tǒng)上執(zhí)行 JS 代碼，實現(xiàn)了業(yè)務邏輯跨平臺；通過 JS 和 native 互調完成 UI native 化，實現(xiàn)了界面交互跨平臺。雖然 JS VM 解釋執(zhí)行、跨邊界調用存在一定的性能開銷，但大部分情況下它們都不會成為瓶頸，如果開發(fā)任務大多集中在界面交互、非計算密集的業(yè)務邏輯上，RN 是不錯的選擇。

Flutter

Flutter 由 Google 開源，項目年齡比 RN 短大半年，目前仍處于 alpha 狀態(tài)，沒有正式發(fā)布版（RN 雖然更新頻繁，而且還處于 0.x 版本，但好歹也算發(fā)布了）。

優(yōu)勢：

自帶 beautiful UI；
UI 代碼的編寫，借鑒了 React 的思想：組件化，聲明式，集中的 build 函數(shù)（React 的 render）……
利用 Flutter 自己的 GUI 引擎，高效實現(xiàn)所有的 2D GUI 開發(fā)；
相機（拍照）、傳感器、GPS、網絡、持久化，都可以在 Flutter 里使用（利用 Dart 和 native 互調）；
Dart package 市場，也可以發(fā)現(xiàn)輪子、發(fā)布輪子；

內部原理：

架構圖：

image

核心引擎部分是純 C++ 代碼，iOS/Android 都直接支持，Dart 代碼則會預編譯為機器碼，在各個系統(tǒng)里直接執(zhí)行，沒有解釋器 賺差價；
UI 部分 Flutter 不使用任何系統(tǒng) OEM 控件，只用在自己的 GUI 體系內打造的控件，因為 Google 信不過 OEM，F(xiàn)lutter 自己完全實現(xiàn)了一套跨平臺的 GUI 系統(tǒng)，包括圖層組合渲染、觸摸事件、手勢、動畫、控件……這個 GUI 系統(tǒng)承載于一個 FlutterView（Android 繼承自 SurfaceView，iOS 繼承自 UIView）；
支持 Dart 和 native 代碼雙向通訊（和 RN 一樣，這里的 native 指的是原生）：通過 Channel 實現(xiàn)完全異步的消息收發(fā)；
- Channel 是 Flutter 里 Dart 和 native 通訊的通道，類似于一個網絡連接，通過名字進行區(qū)分，是全雙工的通道，創(chuàng)建 Channel 時使用相同的名字即可互相收發(fā)消息；
- MethodChannel/FlutterMethodChannel 是專門用來實現(xiàn)類似 RPC 的通道；
- BasicMessageChannel/FlutterBasicMessageChannel 可以用來實現(xiàn)普通的消息收發(fā)，全雙工使用示例（Dart 端，Android 端，iOS 端）
- EventChannel/FlutterEventChannel 用來實現(xiàn)雙向 Event 通訊（看起來和 MessageChannel 功能重疊）；

總結：Flutter 利用 Dart 代碼可以預編譯為機器碼這一特性，實現(xiàn)了業(yè)務邏輯的跨平臺；通過自己實現(xiàn)一套跨平臺的 GUI 系統(tǒng)，實現(xiàn)了界面交互的跨平臺。由于最終執(zhí)行的代碼都是機器碼（C++，Dart），而且跨平臺的實現(xiàn)基本不涉及 Dart 代碼與 native 代碼互相調用，所以 Flutter 的效率肯定是有保障的。在涉及到動畫、手勢等強交互 UI 特性時，F(xiàn)lutter 的性能應該比 RN 要高不少。Flutter 還自帶了一套 Material Design 的跨平臺控件庫，簡直良心。

Web 端呢？Dart 可是能運行在瀏覽器里的呢！

Dart runs fast in every modern browser, on the command line, on servers, and on mobile.

不過遺憾的是，雖然 Dart 代碼可以在瀏覽器運行，但卻無法和 Flutter APP 共用 UI，Flutter 團隊也不打算開發(fā) Web 支持。

J2ObjC + GWT

J2ObjC 和 GWT 都由 Google 開源，分別用來把 Java 代碼編譯為 ObjC 代碼和 JS 代碼，用來在 Android、iOS、Web 端共用業(yè)務邏輯代碼，界面交互代碼則需要單獨開發(fā)。

這個特性簡直就是 SDK 開發(fā)者的福音，事實上這也正是我在最近兩個月在公司項目中實踐的方案。這套跨平臺方案沒有什么炫酷的技術，直接把代碼編譯為各個平臺開發(fā)語言的代碼，簡單粗暴但行之有效。

這里我簡單總結下我在實踐中感受到的一些要點：

利用 interface 隔離 UI 操作；
利用 interface 隔離其他 SDK 調用；
JSON 解析作為一個特殊的 SDK，除了要隔離，還有別的坑：ObjC 中可能需要手動實現(xiàn)序列化與反序列化，我們項目使用的 MJExtension 就是如此；
支持 try-catch，會被翻譯為 ObjC 的異常機制；
循環(huán)引用問題：Java 內存回收做得比 ObjC 好，即便有循環(huán)引用，但如果整體不被其他對象引用，也可以回收，但 ObjC 就不行，所以要么代碼里得顯式設置 null 切斷循環(huán)引用，要么就得用 WeakReference（@Weak 注解會被翻譯為 __unsafe_unretained，用起來還是有些擔心的）；
J2ObjC 的靜態(tài)庫 libjre_emu.a 有好幾百兆，如果發(fā)布的 SDK 是靜態(tài)庫，那讓開發(fā)者用戶也攜帶這個 .a 就會比較惱人；

Djinni + WebAssembly

Djinni 由 Dropbox 開源，它的核心思想是用 C++ 開發(fā)業(yè)務邏輯，利用 JNI、Objective-C++ 實現(xiàn) C++ 和 Java、ObjC 的互相調用。

那這是 JNI 和 Objective-C++ 實現(xiàn)的跨平臺呀，和 Djinni 有啥關系呢？做過 NDK 開發(fā)的朋友肯定知道，要實現(xiàn) C++ 調用 Java 非常麻煩，boilerplate code 很多，Djinni 的發(fā)力點就在于減少 boilerplate code，聲明跨邊界的數(shù)據(jù)結構和接口，自動生成 C++、Java、ObjC 跨邊界調用相關的代碼，讓我們可以聚焦于真正的業(yè)務邏輯開發(fā)中。

Djinni 生成代碼的思路和 J2ObjC 編譯代碼的思路異曲同工，也都是簡單粗暴的辦法。接觸到 Djinni 是半年前，最近趁著總結這篇文章的機會，簡單實踐了一把，還談不上有太深的感悟，唯一一點是 Djinni 生成的 record 在跨邊界時，是 immutable 的，因為很難保證跨邊界狀態(tài)維護，設計接口時需要考慮這一點。

這個方案是在 Dropbox 內部大量實踐后再開源的，而且生成的代碼并不多，穩(wěn)定性不存在太多的風險，靠譜程度還是很高的。如果 SDK 的業(yè)務邏輯想在 C/C++ 代碼中實現(xiàn)，那這套方案就是良策了。

理論上來說，我們的 C++ 代碼也是可以編譯為可以被 WebAssembly 加載的代碼的，那在 Web 端使用應該也是可行的，當然，一層 JS wrapper 必不可少。

Demo time

光說不練假把式，demo 自然是需要的。但逼近年關，公司項目太忙，只來得及做完后兩種方案實現(xiàn) Android iOS 跨平臺的 demo，剩下的部分，只能來年再補了。

畢竟「done is better then perfect」

JavaUniverse: A demo project that showcase how to use Java to conquer the universe, with the help of J2ObjC and GWT :)
CppUniverse: A demo project that showcase how to use C++ to conquer the universe, with the help of Djinni and WebAssembly :)