聊聊移動端跨平臺開發的各種技術

介紹

最近出現的 React Native 再次讓跨平臺移動端開發這個話題火起來了，曾經大家以為在手機上可以像桌面那樣通過 Web 技術來實現跨平臺開發，卻大多因為效能或功能問題而放棄，不得不針對不同平臺開發多個版本。

但這並沒有阻止人們對跨平臺開發技術的探索，畢竟誰不想降低開發成本，一次編寫就處處執行呢？除了 React Native，這幾年還出現過許多其它解決方案，本文我將會對這些方案進行技術分析，供感興趣的讀者參考。

為了方便討論，我將它們分為了以下 4 大流派：

• Web 流：也被稱為 Hybrid 技術，它基於 Web 相關技術來實現介面及功能
• 程式碼轉換流：將某個語言轉成 Objective-C、Java 或 C#，然後使用不同平臺下的官方工具來開發
• 編譯流：將某個語言編譯為二進位制檔案，生成動態庫或打包成 apk/ipa/xap 檔案
• 虛擬機器流：通過將某個語言的虛擬機器移植到不同平臺上來執行

Web 流

Web 流是大家都比較瞭解的了，比如著名的 PhoneGap/Cordova，它將原生的介面封裝後暴露給 JavaScript，可以執行在系統自帶的 WebView 中，也可以自己內嵌一個 Chrome 核心 。

作為這幾年爭論的熱點，網上已經有很多關於它的討論了，這裡我重點聊聊大家最關心的效能問題。

Web 流最常被吐槽的就是效能慢（這裡指內嵌 HTML 的效能，不考慮網路載入時間），可為什麼慢呢？常見的看法是認為「DOM 很慢」，然而從瀏覽器實現角度來看，其實 DOM 就是將對文件操作的 API 暴露給了 JavaScript，而 JavaScript 的呼叫這些 API 後就進入內部的 C++ 實現了，這中間並沒有多少效能消耗，所以從理論上來說瀏覽器的 DOM 肯定比 Android 的「DOM」快，因為 Android 的展現架構大部分功能是用 Java 寫的，在實現相同功能的前提下，C++ 不大可能比 Java 慢（某些情況下 JIT 編譯優化確實有可能做得更好，但那只是少數情況）。

所以從字面意思上看「DOM 很慢」的說法是錯誤的，這個看法之所以很普遍，可能是因為大部分人對瀏覽器實現不瞭解，只知道瀏覽器有 DOM，所以不管什麼問題都只能抱怨它了。

那麼問題在哪呢？在我看來有三方面的問題：

• 早期瀏覽器實現比較差，沒有進行優化
• CSS 過於複雜，計算起來更耗時
• DOM 提供的介面太有限，使得難以進行優化

第一個問題是最關鍵也是最難解決的，現在說到 Web 效能差主要說的是 Android 下比較差，在 iOS 下已經很流暢了，在 Android 4 之前的 WebView 甚至都沒有實現 GPU 加速，每次重繪整個頁面，有動畫的時候不卡才怪。

瀏覽器實現的優化可以等 Android 4.4 慢慢普及起來，因為 4.4 以後就使用 Chrome 來渲染了。

而對於最新的瀏覽器來說，渲染慢的原因就主要是第二個問題：CSS 過於複雜，因為從實現原理上看 Chrome 和 Android View 並沒有本質上的差別，但 CSS 太靈活功能太多了，所以計算成本很高，自然就更慢了。

那是不是可以通過簡化 CSS 來解決？實際上還真有人這麼嘗試了，比如 Famo.us，它最大的特色就是不讓你寫 CSS，只能使用固定的幾種佈局方法，完全靠 JavaScript 來寫介面，所以它能有效避免寫出低效的 CSS，從而提升效能。

而對於複雜的介面及手機下常見的超長的 ListView 來說，第三個問題會更突出，因為 DOM 是一個很上層的 API，使得 JavaScript 無法做到像 Native 那樣細粒度的控制記憶體及執行緒，所以難以進行優化，則在硬體較差的機器上會比較明顯。對於這個問題，我們一年前曾經嘗試過嵌入原生元件的方式來解決，不過這個方案需要依賴應用端的支援，或許以後瀏覽器會自帶幾個優化後的 Web Components 元件，使用這些元件就能很好解決效能問題。

現階段這三個問題都不好解決，所以有人想幹脆不用 HTML/CSS，自己來畫介面，比如 React canvas 直接畫在 Canvas 上，但在我看來這只是現階段解決部分問題的方法，在後面的章節我會詳細介紹自己畫 UI 的各種問題，這裡說個歷史吧，6 年前瀏覽器還比較慢的時候，Bespin 就這麼幹過，後來這個專案被使用 DOM 的 ACE 取代了，目前包括 TextMirror 和 Atom 在內的主流編輯器都是直接使用 DOM，甚至 W3C 有人專門寫了篇文章吐槽用 Canvas 做編輯器的種種缺點，所以使用 Canvas 要謹慎。

另外除了 Canvas，還有人以為 WebGL 快，就嘗試繪製到 WebGL 上，比如 HTML-GL，但它目前的實現太偷懶了，簡單來說就是先用 html2canvas 將 DOM 節點渲染成圖片，然後將這個圖片作為貼圖放在 WebGL 中，這等於將瀏覽器中用 C++ 寫的東東在 JavaScript 裡實現了一遍，渲染速度肯定反而更慢，但倒是能用 GLSL 做特效來忽悠人。

硬體加速不等同於「快」，如果你以為硬體加速一定比軟體快，那你該抽空學學計算機體系結構了

其實除了效能問題，我認為在 Web 流更嚴重的問題是功能缺失，比如 iOS 8 就新增 4000+ API，而 Web 標準需要漫長的編寫和評審過程，根本趕不上，即便是 Cordova 這樣自己封裝也忙不過來，所以為了更好地使用系統新功能，寫 Native 程式碼是必須的。

程式碼轉換流

前面提到寫 Native 程式碼是必須的，但不同平臺下的官方語言不一樣，這會導致同樣的邏輯要寫兩次以上，於是就有人想到了通過程式碼轉換的方式來減少工作量，比如將 Java 轉成 Objective-C。

這種方式雖然聽起來不是很靠譜，但它卻是成本和風險都最小的，因為程式碼轉換後就可以用官方提供的各種工具了，和普通開發區別不大，因此不用擔心遇到各種詭異的問題，不過需要注意生成的程式碼是否可讀，不可讀的方案就別考慮了。

接下來看看目前存在的幾種程式碼轉換方式。

將 Java 轉成 Objective-C

j2objc 能將 Java 程式碼轉成 Objective-C，據說 Google 內部就是使用它來降低跨平臺開發成本的，比如 Google Inbox 專案就號稱通過它共用了 70% 的程式碼，效果很顯著。

可能有人會覺得奇怪，為何 Google 要專門開發一個幫助大家寫 Objective-C 的工具？還有媒體說 Google 做了件好事，其實吧，我覺得 Google 這算盤打得不錯，因為基本上重要的應用都會同時開發 Android 和 iOS 版本，有了這個工具就意味著，你可以先開發 Android 版本，然後再開發 iOS 版本。。。

既然都有成功案例了，這個方案確實值得嘗試，而且關鍵是會 Java 的人多啊，可以通過它來快速移植程式碼到 Objective-C 中。

將 Objective-C 轉成 Java

除了有 Java 轉成 Objective-C，還有 Objective-C 轉成 Java 的方案，那就是 MyAppConverter，比起前面的 j2objc，這個工具更有野心，它還打算將 UI 部分也包含進來，從它已轉換的列表中可以看到還有 UIKit、CoreGraphics 等元件，使得有些應用可以不改程式碼就能轉成功，不過這點我並不看好，對於大部分應用來說並不現實。

由於目前是收費專案，我沒有嘗試過，對技術細節也不瞭解，所以這裡不做評價。

將 Java 轉成 C#

Mono 提供了一個將 Java 程式碼轉成 C# 的工具 Sharpen，不過似乎用的人不多，Star 才 118，所以看起來不靠譜。

還有 JUniversal 這個工具可以將 Java 轉成 C#，但目前它並沒有釋出公開版本，所以具體情況還待了解，它的一個特色是自帶了簡單的跨平臺庫，裡面包括檔案處理、JSON、HTTP、OAuth 元件，可以基於它來開發可複用的業務邏輯。

比起轉成 Objective-C 和 Java 的工具，轉成 C# 的這兩個工具看起來都非常不成熟，估計是用 Windows Phone 的人少。

將 Haxe 轉成其它語言

說到原始碼轉換就不得不提 Haxe 這個奇特的語言，它沒有自己的虛擬機器或可執行檔案編譯器，所以只能通過轉成其它語言來執行，目前支援轉成 Neko（位元組碼）、Javascript、Actionscript 3、PHP、C++、Java、C# 和 Python，儘管有人實現了轉成 Swift 的支援，但還是非官方的，所以要想支援 iOS 開發目前只能通過 Adobe AIR 來執行。

在遊戲開發方面做得不錯，有個跨平臺的遊戲引擎 OpenFL 的，最終可以使用 HTML5 Canvas、OpenGL 或 Flash 來進行繪製，OpenFL 的開發體驗做得相當不錯，同一行程式碼不需要修改就能編譯出不同平臺下的可執行檔案，因為是通過轉成 C++ 方式進行編譯的，所以在效能和反編譯方面都有優勢，可惜目前似乎並不夠穩定，不然可以成為 Cocos2d-x 的有利競品。

在 OpenFL 基礎上還有個跨平臺的 UI 元件 HaxeUI，但介面風格我覺得特別醜，也就只能在遊戲中用了。

所以目前來看 Haxe 做跨平臺遊戲開發或許可行，但 APP 開發就別指望了，而基於它來共用程式碼實在就更不靠譜了，因為熟悉它的開發者極少，反而增加成本。

XMLVM

除了前面提到的原始碼到原始碼的轉換，還有 XMLVM 這種與眾不同的方式，它首先將位元組碼轉成一種基於 XML 的中間格式，然後再通過 XSL 來生成不同語言，目前支援生成 C、Objective-C、JavaScript、C#、Python 和 Java。

雖然基於一箇中間位元組碼可以方便支援多語言，然而它也導致生成程式碼不可讀，因為很多語言中的語法糖會在位元組碼中被抹掉，這是不可逆的，以下是一個簡單示例生成的 Objective-C 程式碼，看起來就像彙編：

XMLVM_ENTER_METHOD("org.xmlvm.tutorial.ios.helloworld.portrait.HelloWorld", "didFinishLaunchingWithOptions", "?")
XMLVMElem _r0;
XMLVMElem _r1;
XMLVMElem _r2;
XMLVMElem _r3;
XMLVMElem _r4;
XMLVMElem _r5;
XMLVMElem _r6;
XMLVMElem _r7;
_r5.o = me;
_r6.o = n1;
_r7.o = n2;
_r4.i = 0;
_r0.o = org_xmlvm_iphone_UIScreen_mainScreen__();
XMLVM_CHECK_NPE(0)
_r0.o = org_xmlvm_iphone_UIScreen_getApplicationFrame__(_r0.o);
_r1.o = __NEW_org_xmlvm_iphone_UIWindow();
XMLVM_CHECK_NPE(1)
...

在我看來這個方案相當不靠譜，萬一生成的程式碼有問題基本沒法修改，也沒法除錯程式碼，所以不推薦。

小結

雖然程式碼轉換這種方式風險小，但我覺得對於很多小 APP 來說共享不了多少程式碼，因為這類應用大多數圍繞 UI 來開發的，大部分程式碼都和 UI 耦合，所以公共部分不多。

在目前的所有具體方案中，只有 j2objc 可以嘗試，其它都不成熟。

編譯流

編譯流比前面的程式碼轉換更進一步，它直接將某個語言編譯為普通平臺下的二進位制檔案，這種做法有明顯的優缺點：

優點

• 可以重用一些實現很複雜的程式碼，比如之前用 C++ 實現的遊戲引擎，重寫一遍成本太高
• 編譯後的程式碼反編譯困難
• 或許效能會好些（具體要看實現）

缺點

• 如果這個工具本身有 Bug 或效能問題，定位和修改成本會很高
• 編譯後體積不小，尤其是如果要支援 ARMv8 和 x86 的話
• 接下來我們通過區分不同語言來介紹這個流派下的各種方案。

C++ 類

C++ 是最常見的選擇，因為目前 Android、iOS 和 Windows Phone 都提供了 C++ 開發的支援，它通常有三種做法：

• 只用 C++ 實現非介面部分，這是官方比較推崇的方案，目前有很多應用是這麼做的，比如 Mailbox 和 Microsoft Office。
• 使用 2D 圖形庫來自己繪製介面，這種做法在桌面比較常見，因為很多介面都有個性化需求，但在移動端用得還不多。
• 使用 OpenGL 來繪製介面，常見於遊戲中。

使用 C++ 實現非介面部分比較常見，所以這裡就不重複介紹了，除了能提升效能和共用程式碼，還有人使用這種方式來隱藏一些關鍵程式碼（比如金鑰），如果你不知道如何構建這樣的跨平臺專案，可以參考 Dropbox 開源的 libmx3 專案，它還內嵌了 json 和 sqlite 庫，並通過呼叫系統庫來實現對簡單 HTTP、EventLoop 及建立執行緒的支援。

而如果要用 C++ 實現介面部分，在 iOS 和 Windows Phone 下可以分別使用 C++ 的超集 Objective-C++ 和 C++/CX，所以還比較容易，但在 Android 下問題就比較麻煩了，主要原因是 Android 的介面絕大部分是 Java 實現的，所以用 C++ 開發介面最大的挑戰是如何支援 Android，這有兩種做法：通過 JNI 呼叫系統提供的 Java 方法或者自己畫 UI。

第一種做法雖然可行，但程式碼太冗餘了比如一個簡單的函式呼叫需要寫那麼多程式碼：

JNIEnv* env;
jclass testClass = (*env)->FindClass(env, "com/your/package/name/Test"); // get Class
jmethodID constructor = (*env)->GetMethodID(env, cls, "<init>", "()V");
jobject testObject = (*env)->NewObject(env, testClass, constructor);
methodID callFromCpp = (*env)->GetMethodID(env, testClass, "callFromCpp", "()V"); //get methodid
(*env)->CallVoidMethod(env, testObject, callFromCpp);

那自己畫 UI 是否會更方便點？比如 JUCE 和 QT 就是自己畫的，我們來看看 QT 的效果：

看起來很不錯是吧？不過在 Android 5 下就悲劇了，很多效果都沒出來，比如按鈕沒有漣漪效果，甚至邊框都沒了，根本原因在於它是通過 Qt Quick Controls 的自定義樣式來模擬的，而不是使用系統 UI 元件，因此它享受不到系統升級自動帶來的介面優化，只能自己再實現一遍，工作量不小。

反而如果最開始用的是 Android 原生元件就什麼都不需要做，而且還能用新的 AppCompat 庫來在 Android 5 以下實現 Material Design 效果。

最後一種做法是使用 OpenGL 來繪製介面，因為 EGL+OpenGL 本身就是跨平臺，所以基於它來實現會很方便，目前大多數跨平臺遊戲底層都是這麼做的。

既然可以基於 OpenGL 來開發跨平臺遊戲，是否能用它來實現介面？當然是可行的，而且 Android 4 的介面就是基於 OpenGL 的，不過它並不是只用 OpenGL 的 API，那樣是不現實的，因為 OpenGL API 最初設計並不是為了畫 2D 圖形的，所以連畫個圓形都沒有直接的方法，因此 Android 4 中是通過 Skia 將路徑轉換為位置陣列或紋理，然後再交給 OpenGL 渲染的。

然而要完全實現一遍 Android 的 UI 架構工作量不小，以下是其中部分相關程式碼的程式碼量：

路徑 程式碼行數

frameworks/base/core/java/android/widget/ 65622

frameworks/base/core/java/android/view/ 49150

frameworks/base/libs/hwui/ 16375

frameworks/base/graphics/java/android/graphics/ 18197

其中光是文字渲染就非常複雜，如果你覺得簡單，那隻能說明你沒看過這個世界有多大，或許你知道中文有編碼問題、英語有連字元(hyphen)折行，但你是否知道繁體中文有豎排版、阿拉伯文是從右到左的、日語有平假名注音(ルビ)、印度語有母音附標文字(abugida አቡጊዳ)……？

而相比之下如果每個平臺單獨開發介面，看似工作量不小，但目前在各個平臺下都會有良好的官方支援，相關工具和文件都很完善，所以其實成本沒那麼高，而且可以給使用者和系統風格保持一致的良好體驗，所以我認為對於大多數應用來說自己畫 UI 是很不划算的。

不過也有特例，對於 UI 比較獨特的應用來說，自己畫也是有好處的，除了更靈活的控制，它還能使得不同平臺下風格統一，這在桌面應用中很常見，比如 Windows 下你會發現幾乎每個必備軟體的 UI 都不太一樣，而且好多都有換膚功能，在這種情況下很適合自己畫 UI。

Xamarin

Xamarin 可以使用 C# 來開發 Android 及 iOS 應用，它是從 Mono 發展而來的，目前看起來商業運作得不錯，相關工具及文件都挺健全。

因為它在 iOS 下是以 AOT 的方式編譯為二進位制檔案的，所以把它歸到編譯流來討論，其實它在 Android 是內嵌了 Mono 虛擬機器 來實現的，因此需要裝一個 17M 的執行環境。

在 UI 方面，它可以通過呼叫系統 API 來使用系統內建的介面元件，或者基於 Xamarin.Forms 開發定製要求不高的跨平臺 UI。

對於熟悉 C# 的團隊來說，這還真是一個看起來很不錯的，但這種方案最大的問題就是相關資料不足，遇到問題很可能搜不到解決方案，不過由於時間關係我並沒有仔細研究，推薦看看這篇文章，其中談到它的優缺點是：

優點

• 開發 app 所需的基本功能全部都有
• 有商業支援，而且這個專案對 Windows Phone 很有利，微軟會大力支援

缺點

• 如果深入後會發現功能缺失，尤其是定製 UI，因為未開源使得遇到問題時不知道如何修復
• Xamarin 本身有些 Bug
• 相關資源太少，沒有原生平臺那麼多第三方庫
• Xamarin studio 比起 Xcode 和 Android Studio 在功能上還有很大差距

Objective-C 編譯為 Windows Phone

微軟知道自己的 Windows Phone 太非主流，所以很懂事地推出了將 Objective-C 專案編譯到 Windows Phone 上執行的工具，目前這個工具的相關資料很少，鑑於 Visual Studio 支援 Clang，所以極有可能是使用 Clang 的前端來編譯，因此我歸到編譯流。

而對於 Android 的支援，微軟應該使用了虛擬機器的方式，所以放到下個章節介紹。

RoboVM

RoboVM 可以將 Java 位元組碼編譯為可在 iOS 下執行的機器碼，這有點類似 GCJ，但它的具體實現是先使用 Soot 將位元組碼編譯為 LLVM IR，然後通過 LLVM 的編譯器編譯成不同平臺下的二進位制檔案。

比如簡單的 new UITextField(new CGRect(44, 32, 232, 31)) 最後會變如下的機器碼(x86)：

call imp___jump_table__[j]org.robovm.apple.uikit.UITextField[allocator][clinit]
mov esi, eax
mov dword [ss:esp], ebx
call imp___jump_table__[j]org.robovm.apple.coregraphics.CGRect[allocator][clinit]
mov edi, eax
mov dword [ss:esp+0x4], edi
mov dword [ss:esp], ebx
mov dword [ss:esp+0xc], 0x40460000
...

基於位元組碼編譯的好處是可以支援各種在 JVM 上構建的語言，比如 Scala、Kotlin、Clojure 等。

在執行環境上，它使用的 GC 和 GCJ 一樣，都是 Boehm GC，這是一個保守 GC，會有記憶體洩露問題，儘管官方說已經優化過了影響不大。

在 UI 的支援方面，它和 Xamarin 挺像，可以直接用 Java 呼叫系統介面來建立介面（最近支援 Interface Builder 了），比如上面的示例就是。另外還號稱能使用 JavaFX，這樣就能在 iOS 和 Android 上使用同一套 UI 了，不過目前看起來很不靠譜。

在我看來 RoboVM 目前最大的用途就是使用 libGDX 開發遊戲了，儘管在功能上遠不如 Cocos2d-x（尤其是場景及物件管理），但不管怎麼說用 Java 比 C++ 還是方便很多（別跟我說沒人用 Java 做遊戲，價值 25 億美元的 Minecraft 就是），不過本文主要關心的是 UI 開發，所以這方面的話題就不深入討論了，

RoboVM 和 Xamarin 很像，但 RoboVM 風險會小些，因為它只需要把 iOS 支援好就行了，對優先開發 Android 版本的團隊挺適用，但目前官方文件太少了，而且不清楚 RoboVM 在 iOS 上的效能和穩定性怎樣。

Swift – Apportable/Silver

apportable 可以直接將 Swift/Objective-C 編譯為機器碼，但它官網的成功案例全部都是遊戲，所以用這個來做 APP 感覺很不靠譜。

所以後來它又推出了 Tengu 這個專門針對 APP 開發的工具，它的比起之前的方案更靈活些，本質上有點類似 C++ 公共庫的方案，只不過語言變成了 Swift/Objective-C，使用 Swift/Objective-C 來編譯生成跨平臺的 SO 檔案，提供給 Android 呼叫。

另一個類似的是 Silver，不過目前沒正式釋出，它不僅支援 Swift，還支援 C# 和自創的 Oxygene 語言（看起來像 Pascal），在介面方面它還有個跨平臺非 UI 庫 Sugar，然而目前 Star 數只有 17，太非主流了，所以實在懶得研究它。

使用 Swift 編譯為 SO 給 Android 用雖然可行，但目前相關工具都不太成熟，所以不推薦使用。

Go

Go 是最近幾年很火的後端服務開發語言，它語法簡單且高效能，目前在國內有不少使用者。

Go 從 1.4 版本開始支援開發 Android 應用（並將在 1.5 版本支援 iOS），不過前只能呼叫很少 的 API，比如 OpenGL 等，所以只能用來開發遊戲，但我感覺並不靠譜，現在還有誰直接基於 OpenGL 開發遊戲？大部分遊戲都是基於某個框架的，而 Go 在這方面太缺乏了，我只看到一個桌面端 Azul3D，而且非常不成熟。

因為 Android 的 View 層完全是基於 Java 寫的，要想用 Go 來寫 UI 不可避免要呼叫 Java 程式碼，而這方面 Go 還沒有簡便的方式，目前 Go 呼叫外部程式碼只能使用 cgo，通過 cgo 再呼叫 jni，這需要寫很多中間程式碼，所以目前 Go 1.4 採用的是類似 RPC 通訊的方式來做，從它原始碼中例子可以看出這種方式有多麻煩，效能肯定有不小的損失。

而且 cgo 的實現本身就對效能有損失，除了各種無關函式的呼叫，它還會鎖定一個 Go 的系統執行緒，這會影響其它 gorountine 的執行，如果同時執行太多外部呼叫，甚至會導致所有 gorountine 等待。

這個問題的根源在於 Go 的棧是可以自動擴充的，這種方式有利於建立無數 gorountine，但卻也導致了無法直接呼叫 C 編譯後的函式，需要進行棧切換。

所以使用 Go 開發跨平臺移動端應用目前不靠譜。

話說 Rust 沒有 Go 的效能，它呼叫 C 函式是沒有效能損耗的，但目前 Rust 還沒提供對 iOS/Android 的官方支援，儘管有人還是嘗試過是可行的，但現在還不穩定，從 Rust 語言本身的設計來看，它挺適合取代 C++ 來做這種跨平臺公共程式碼，但它的缺點是語法複雜，會嚇跑很多開發者。

Xojo

我之前一直以為 BASIC 掛了，沒想到還有這麼一個特例，Xojo 使用的就是 BASIC，它有看起來很強大的 IDE，讓人感覺像是在用 VisualBasic。

它的定位應該是給小朋友或業餘開發者用的，因為似乎看起來學習成本低，但我不這麼認為，因為用得人少，反而網上資料會很少，所以恐怕成本會更高。

因為時間關係，以及對 BASIC 無愛，我並沒有怎麼研究它。

小結

從目前分析的情況看，C++ 是比較穩妥的選擇，但它對團隊成員有要求，如果大家都沒寫過 C++，可以試試 Xamrin 或 RoboVM。

虛擬機器流

除了編譯為不同平臺下的二進位制檔案，還有另一種常見做法是通過虛擬機器來支援跨平臺執行，比如 JavaScript 和 Lua 都是天生的內嵌語言，所以在這個流派中很多方案都使用了這兩個語言。

不過虛擬機器流會遇到兩個問題：一個是效能損耗，另一個是虛擬機器本身也會佔不小的體積。

Java 系

說到跨平臺虛擬機器大家都會想到 Java，因為這個語言一開始就是為了跨平臺設計的，Sun 的 J2ME 早在 1998 年就有了，在 iPhone 出來前的手機上，很多小遊戲都是基於 J2ME 開發的，這個專案至今還活著，能執行在 Raspberry Pi 上。

前面提到微軟提供了將 Objective-C 編譯在 Windows Phone 上執行的工具，在對 Android 的支援上我沒找到的詳細資料，所以就暫時認為它是虛擬機器的方式，從 Astoria 專案的介紹上看它做得非常完善，不僅能支援 NDK 中的 C++，還實現了 Java 的 debug 介面，使得可以直接用 Android Studio 等 IDE 來除錯，整個開發體驗和在 Android 手機上幾乎沒區別。

另外 BlackBerry 10 也是通過內嵌虛擬機器來支援直接執行 Android 應用，不過據說比較卡。

不過前面提到 C# 和 Java 在 iOS 端的方案都是通過 AOT 的方式實現的，目前還沒見到有 Java 虛擬機器的方案，我想主要原因是 iOS 的限制，普通 app 不能呼叫 mmap、mprotect，所以無法使用 JIT 來優化效能，如果 iOS 開放，或許哪天有人開發一個像微軟那樣能直接在 iOS 上執行 Android 應用的虛擬機器，就不需要跨平臺開發了，大家只需要學 Android 開發就夠了。。。

Titanium/Hyperloop

Titanium 應該不少人聽過，它和 PhoneGap 幾乎是同時期的著名跨平臺方案，和 PhoneGap 最大的區別是：它的介面沒有使用 HTML/CSS，而是自己設計了一套基於 XML 的 UI 框架 Alloy，程式碼類似下面這個樣子：

app/styles/index.tss
".container": {
 backgroundColor:"white"
},
// This is applied to all Labels in the view
"Label": {
 width: Ti.UI.SIZE,
 height: Ti.UI.SIZE,
 color: "#000", // black
 transform: Alloy.Globals.rotateLeft // value is defined in the alloy.js file
},
// This is only applied to an element with the id attribute assigned to "label"
"#label": {
 color: "#999" /* gray */
}
app/views/index.xml
<Alloy>
 <Window class="container">
 <Label id="label" onClick="doClick">Hello, World</Label>
 </Window>
<span style="color: #333333; font-style: normal;">&lt;/Alloy&gt;</span>

前面我們說過由於 CSS 的過於靈活拖累了瀏覽器的效能，那是否自己建立一套 UI 機制會更靠譜呢？儘管這麼做對效能確實有好處，然而它又帶來了學習成本問題，做簡單的介面問題不大，一旦要深入定製開發就會發現相關資料太少，所以還是不靠譜。

Titanium 還提供了一套跨平臺的 API 來方便呼叫，這麼做是它的優點更是缺點，尤其是下面三個問題：

1. API 有限，因為這是由 Titanium 提供的，它肯定會比官方 API 少且有延遲，Titanium 是肯定跟不過來的
2. 相關資料及社群有限，比起 Android/iOS 差遠了，遇到問題都不知道去哪找答案
3. 缺乏第三方庫，第三方庫肯定不會專門為 Titanium 提供一個版本，所以不管用什麼都得自己封裝

Titanium 也意識到了這個問題，所以目前在開發下一代的解決方案 Hyperloop，它可以將 JavaScript 編譯為原生程式碼，這樣的好處是呼叫原生 API 會比較方便，比如它的 iOS 是這樣寫的

@import("UIKit");
@import("CoreGraphics");
var view = new UIView();
view.frame = CGRectMake(0, 0, 100, 100);

這個方案和之前的說的 Xamarin 很相似，基本上等於將 Objective-C 翻譯為 JavaScript 後的樣子，意味著你可以對著 Apple 的官方文件開發，不過如果發現某些 Objective-C 語法發現不知道對應的 JavaScript 怎麼寫時就悲劇了，只有自己摸索。

但從 Github 上的提交歷史看，這專案都快開發兩年了，但至今仍然是試驗階段，從更新頻率來看，最近一年只提交了 8 次，所以恐怕是要棄坑了，非常不靠譜。

因此我認為 Titanium/Hyperloop 都非常不靠譜，不推薦使用。

NativeScript

之前說到 Titanium 自定義 API 帶來的各種問題，於是就有人換了個思路，比如前段時間推出的 NativeScript，它的方法說白了就是用工具來自動生成 wrapper API，和系統 API 保持一致。

有了這個自動生成 wrapper 的工具，它就能方便基於系統 API 來開發跨平臺元件，以簡單的 Button 為例，原始碼在 cross-platform-modules/ui/button 中，它在 Android 下是這樣實現的（TypeScript 省略了很多程式碼）

export class Button extends common.Button {
 private _android: android.widget.Button;
 private _isPressed: boolean;
public _createUI() {
 var that = new WeakRef(this);
 this._android = new android.widget.Button(this._context);
 this._android.setOnClickListener(new android.view.View.OnClickListener({
 get owner() {
 return that.get();
 },
 onClick: function (v) {
 if (this.owner) {
 this.owner._emit(common.knownEvents.tap);
 }
 }
 }));
 }
}

而在 iOS 下是這樣實現的（省略了很多程式碼）

export class Button extends common.Button {
 private _ios: UIButton;
 private _tapHandler: NSObject;
 private _stateChangedHandler: stateChanged.ControlStateChangeListener;
constructor() {
 super();
 this._ios = UIButton.buttonWithType(UIButtonType.UIButtonTypeSystem);
this._tapHandler = TapHandlerImpl.new().initWithOwner(this);
 this._ios.addTargetActionForControlEvents(this._tapHandler, "tap", UIControlEvents.UIControlEventTouchUpInside);
this._stateChangedHandler = new stateChanged.ControlStateChangeListener(this._ios, (s: string) => {
 this._goToVisualState(s);
 });
 }
get ios(): UIButton {
 return this._ios;
 }
}

可以看到用法和官方 SDK 中的呼叫方式是一樣的，只不過語言換成了 JavaScript，並且寫法看起來比較詭異罷了，風格類似前面的 Hyperloop 類似，所以也同樣會有語法轉換的問題。

這麼做最大的好處就是能完整支援所有系統 API，對於第三方庫也能很好支援，但它目前最大缺點是生成的檔案體積過大，即便什麼都不做，生成的 apk 檔案也有 8.4 MB，因為它將所有 API binding 都生成了，而且這也導致在 Android 下首次開啟速度很慢。

從底層實現上看，NativeScript 在 Android 下內嵌了 V8，而在 iOS 下內嵌了自己編譯的 JavaScriptCore（這意味著沒有 JIT 優化，具體原因前面提到了），這樣的好處是能呼叫更底層的 API，也避免了不同作業系統版本下 JS 引擎不一致帶來的問題，但後果是生成檔案的體積變大和在 iOS 下效能不如 WKWebView。

WKWebView 是基於多程式實現的，它在 iOS 的白名單中，所以能支援 JIT。

它的使用體驗很不錯，做到了一鍵編譯執行，而且還有 MVVM 的支援，能進行資料雙向繫結。

在我看來 NativeScript 和 Titanium 都有個很大的缺點，那就是排它性太強，如果你要用這兩個方案，就得完整基於它們進行開發，不能在某些 View 下進行嘗試，也不支援直接嵌入第三方 View，有沒有方案能很好地解決這兩個問題？有，那就是我們接下來要介紹的 React Native。

React Native

關於 React Native 目前網上有很多討論了，知乎上也有不少回答，儘管有些回答從底層實現角度看並不準確，但大部分關鍵點倒是都提到了。

鑑於我不喜歡重複別人說過的話，這裡就聊點別的。

React Native 的思路簡單來說就是在不同平臺下使用平臺自帶的 UI 元件，這個思路並不新奇，十幾年前的 SWT 就是這麼做的。

從團隊上看，Facebook 的 iOS 團隊中不少成員是來自 Apple 的，比如 Paper 團隊的經理及其中不少成員都是，因為 iOS 不開源，所以從 Apple 中出來的開發者還是有優勢的，比如前 Apple 開發者搞出來的 Duet 就秒殺了市面上所有其他方案，而且從 Facebook 在 iOS 上開源的專案看他們在 iOS 方面的經驗和技術都不錯，所以從團隊角度看他們做出來的東西不會太差。

在做 React Native 方案的同時，其實 Facebook 還在做一個 Objective-C++ 上類似 React 的框架 ComponentKit，以下是它的程式碼示例：

@implementation ArticleComponent
+ (instancetype)newWithArticle:(ArticleModel *)article
{
 return [super newWithComponent:
 [CKStackLayoutComponent
 newWithView:{}
 size:{}
 style:{
 .direction = CKStackLayoutDirectionVertical,
 }
 children:{
 {[HeaderComponent newWithArticle:article]},
 {[MessageComponent newWithMessage:article.message]},
 {[FooterComponent newWithFooter:article.footer]},
 }];
}
@end

它的可讀性比 JSX 中的 XML 差了不少，而且隨著大家逐步接受 Swift，這種基於 Objective-C++ 的方案恐怕沒幾年就過時了，所以 Facebook 押寶 React 是比較正確的。

我看到有人說這是 Facebook 迴歸 H5，但其實 React Native 和 Web 扯不上太多關係，我所理解的 Web 是指 W3C 定義的那些規範，比如 HTML、CSS、DOM，而 React Native 主要是借鑑了 CSS 中的 Flexbox 寫法，還有 navigator、XMLHttpRequest 等幾個簡單的 API，更別說完全沒有 Web 的開放性，所以 React Native 和 HTML 5 完全不是一回事。

Facebook Groups 的 iOS 版本很大一部分基於 React Native 開發，其中用到了不少內部通過元件，比如 ReactGraphQL，這裡我就八卦一下它，GraphQL 這是一個結構化資料查詢的語法，就像 MongoDB 查詢語法那樣查詢 JSON 資料，不過它並不是一種文件型資料庫，而只是一箇中間層，具體的資料來源可以連其它資料庫，它想取代的應該是 RESTful 那樣的前後端簡單 HTTP 協議，讓前端更方便的獲取資料，據說將會開源（看起來打算用 Node 實現）。

寫文章拖時間太長的問題就是這期間會發生很多事情，比如 GraphQL 在我開始寫的時候外界都不知道，所以需要八卦一下，結果現在官方已經宣佈了，不過官方並沒提到我說的那個 Node 實現，它目前還在悄悄開發階段

React Native 的官方視訊中說它能做到 App 內實時更新，其實這是 Apple 明文禁止的（App Store Review Guidelines 中的 2.7），要做得低調。

我比較喜歡的是 React Native 中用到了 Flow，它支援定義函式引數的型別，極大提升了程式碼可讀性，另外還能使用 ES6 的語法，比如 class 關鍵字等。

React Native 比傳統 Objective-C 和 UIView 的學習成本低多了，熟悉 JavaScript 的開發者應該半天內就能寫個使用標準 UI 的介面，而且用 XML+CSS 畫介面也遠比 UIView 中用 Frame 進行手工佈局更易讀（我沒用過 Storyboards，它雖然看起來直觀，但多人編輯很容易衝突），感興趣可以抽空看看這個詳細的入門教程，親自動手試試就能體會到了，Command + R 更新程式碼感覺很神奇。

它目前已經有元件倉庫了，而且在 github 上都有 500 多倉庫了，其中有 sqlite、Camera 等原生元件，隨著這些第三方元件的完善，基於 React Native 開發越來越不需要寫原生程式碼了。

不過壞訊息是 React Native 的 Android 版本還要等半年，這可以理解，因為在 Android 上問題要複雜得多，有 Dalvik/ART 攔在中間，使得互動起來很麻煩。

NativeScript 和 React Native 在側重點上有很大的不同，使得這兩個產品目前走向了不同的方向：

• React Native 要解決的是開發效率問題，它並沒指望完全取代 Native 開發，它的 rootView 繼承自 UIView，所以可以在部分 View 是使用，很方便混著，不需要重寫整個 app，而且混用的時候還需要顯示地將 API 暴露給 JavaScript
• NativeScript 則像是Titanium 那樣企圖完全使用 JavaScript 開發，將所有系統 API 都暴露給了 JavaScript，讓 JavaScript 語言預設就擁有 Native 語言的各種能力，然後再次基礎上來開發

方向的不同導致這兩個產品將會有不同的結局，我認為 React Native 肯定會完勝 NativeScript，因為它的使用風險要小很多，你可以隨時將部分 View 使用 React Native 來試驗，遇到問題就改回 Native 實現，風險可控，而用 NativeScript 就不行了，這導致大家在技術選型的時候不敢使用 NativeScript。

話說 Angular 團隊看到 React Native 後表示不淡定了，於是開始重新設計 Angular 2 的展現架構，將現有的 Render 層獨立出來，以便於做到像 React 那樣適應不同的執行環境，可以執行在 NativeScript 上。

綜合來看，我覺得 React Native 很值得嘗試，而且風險也不高。

遊戲引擎中的指令碼

遊戲引擎大多都能跨平臺，為了提升開發效率，不少引擎還內嵌了對指令碼支援，比如：

• Ejecta，它實現了 Canvas 及 Audio 的 API，可以開發簡單的遊戲，但目前還不支援 Android
• CocoonJS，實現了 WebGL 的 API，可以執行 Three.js 寫的遊戲
• Unreal Engine 3，可以使用 UnrealScript 來開發，這個語言的語法很像 Java
• Cocos2d-js，Cocos2d-x 的 JavaScript binding，它內部使用的 JS 引擎是 SpiderMonkey
• Unity 3D，可以使用 C# 或 JavaScript 開發遊戲邏輯
• Corona，使用 Lua 來開發

…

目前這種方式只有 Unity 3D 發展比較好，Cocos2d-JS 據說還行，有些小遊戲在使用，Corona 感覺比較非主流，雖然它也支援簡單的按鈕等介面元素，但用來寫 APP 我不看好，因為不開源所以沒研究，目前看來最大的好處似乎是虛擬機器體積小，內嵌版本官方號稱只有 1.4M，這是 Lua 引擎比較大的優勢。

而剩下的 3 個都基本上掛了，Ejecta 至今還不支援 Android，CocoonJS 轉型為類似 Crosswalk 的 WebView 方案，而 Unreal Engine 4 開始不再支援 UnrealScript，而是轉向了使用 C++ 開發，感興趣可以圍觀一下 Epic 創始人解釋為什麼要這麼做。

當然，這些遊戲引擎都不適合用來做 APP，一方面是會遇到前面提到的介面繪製問題，另一方面遊戲引擎的實現一般都要不斷重繪，這肯定比普通 App 更耗電，很容易被使用者發現後怒刪。

Adobe AIR

儘管 Flash 放棄了移動端下的瀏覽器外掛版本，但 Adobe AIR 還沒掛，對於熟悉 ActionScript 的團隊來說，這是一種挺好的跨平臺遊戲開發解決方案，國內遊戲公司之前有用，現在還有沒人用我就不知道了。

但開發 APP 方面，它同樣缺乏好的 UI 庫，Flex 使用體驗很差，目前基本上算掛了，目前只有 Feathers 還算能看，不過主要是給遊戲中的 UI 設計的，並不適合用來開發 APP。

Dart

Dart 在 Web 基本上失敗了，於是開始轉戰移動開發，目前有兩個思路，一個是類似 Lua 那樣的嵌入語言來統一公共程式碼，但因為 Dart 虛擬機器源自 V8，在一開始設計的時候就只有 JIT 而沒有直譯器，甚至連位元組碼都沒有，所以它無法在 iOS 下執行，於是 Dart 團隊又做了個小巧的虛擬機器 Fletch，它基於傳統的位元組碼解釋執行方式來執行，目前程式碼只有 1w 多行，和 Lua 一樣輕量級。

另一個就是最近比較熱門的 Sky，這裡吐槽一下國內外的媒體，我看到的報導都是說 Google 想要用 Dart 取代 Android 下的 Java 開發。。。這個東東確實是 Google 的 Chrome 團隊開發的，但 Google 是一個很大的公司好不好，內部有無數小團隊，某個小團隊並不能代表個 Google，如果真是 Google 高層的決定，它將會在 Google I/O 大會主題演講上推出來，而不是 Dart Developer Summit 這樣非主流的技術分享。

有報導稱 Sky 只支援線上應用，不支援離線，這錯得太離譜了，人家只是為了演示它的線上更新能力，你要想將程式碼內嵌到 app 裡當然是可以的。

Sky 的架構如下圖所示，它參考了 Chrome，依靠一個訊息系統來和本地環境進行通訊，使得 Dart 的程式碼和平臺無關，可以執行在各種平臺上。

如果你讀過前面的文章，那你一定和我一樣非常關心一個問題：Sky 的 UI 是怎麼繪製出來的？使用系統還是自己畫？一開始看 Sky 介紹視訊的時候，我還以為它底層繪製基於 Chrome，因為這個視訊的演講者是 Eric Seidel，他是 WebKit 專案中非常有名的開發者，早年在 Apple 開發 WebKit，2008 年跳槽去了 Chrome 團隊，但他在演講中並沒有提到 WebView，而且演示的時候介面非常像原生 Material Design 效果（比如點選有漣漪效果），所以我又覺得它是類似 React Native 那樣使用原生 UI。

然而當我下載那個應用分析後發現，它既沒使用 Chrome/WebView 也沒使用原生 UI 元件，難不成是自己繪製的？

從 Sky SDK 的程式碼上看，它其中有非常多 Web 的痕跡，比如支援標準的 CSS、很多 DOM API，但它編譯後的體積非常小，libsky_shell.so 只有 8.7 MB，我之前嘗試精簡過 Chrome 核心，將 WebRTC 等周邊功能刪掉也要 22 MB，這麼小的體積肯定要刪 Web 核心功能，比如 SVG 和部分 CSS3，所以我懷疑它實現了簡版的 Chrome 核心渲染。

後來無意間看了一下 Mojo 的程式碼，才證實確實如此，原來前面那張圖中介紹的 Mojo 其實並不完整，Mojo 不僅僅是一個訊息系統，它是一個簡版的 Chrome 核心！使用 cloc 統計程式碼就暴露了：

12508 text files.
 11973 unique files.
 2299 files ignored.
-----------------------------------------------------
Language files blank comment code
-----------------------------------------------------
C++ 3485 129830 107745 689089
C/C++ Header 3569 92435 125742 417655
C 266 37462 63659 269220
...

C++ 不包含註釋的程式碼部分就有近 70w 行啊，而且一看目錄結構就是濃濃的 Chromium 風格，至少從技術難度來說絕對秒掉前面所有方案，也印證了我前面說過如果有簡化版 CSS/HTML 就能很好解決效能問題。

這也讓我理解了為什麼 Eric 在談到 Mojo 的時候語焉不詳，讓人誤以為僅僅是一個訊息系統，他要是明確說這是一個精簡版 Chrome，那得引起多大的誤會啊，沒準會有小編用「Google 宣佈開發下一代瀏覽器核心取代 Blink」這樣的標題了。

之前 Dart 決定不將 Dart VM 放到 Chrome 裡，原來並不是因為被眾人反對而死心了，而是因為 fork 了一個 Chrome 自己拿來玩了。

綜合來看，目前 Dart 的這兩個方案都非常不成熟，Sky 雖然在技術上看很強大，但 Dart 語言目前接受度非常低，比起它所帶來的跨平臺優點，它的缺點更大，比如無法使用第三方 Native UI 庫，也無法使用第三方 Web UI 庫，這導致它的社群會非常難發展，命中註定非主流，真可惜了這幫技術大牛，但方向比努力更重要，希望他們能儘早醒悟，讓 Sky 也支援 JavaScript。

結論及參考

看到這裡估計不少讀者暈了，有那麼多種方案，最後到底哪個最適合自己？該學哪個？這裡簡單說說我的看法。

如果你只會 JavaScript，那目前最好的方案是 React Native，有了它你即使不瞭解 Native 開發也能寫出很多中小應用，等萬一火了再學 Native 開發也不遲啊。

如果你只會 Java，那可以嘗試 RoboVM 或 j2objc，j2objc 雖然目前更穩定靠譜，但它不能像 RoboVM 那樣完全用 Java 開發，所以你還得學 Objective-C 來寫介面，而 RoboVM 的缺點就是貌似還不太穩定，而且似乎除了遊戲以外還沒見到比較知名的應用使用，而它這種方案註定會比 j2objc 更容易出問題，所以你得做好踩坑的心理準備。

如果你只會 C#，那唯一的選擇就是 Xamarin 了。

如果你只會 Objective-C，很杯具目前沒有比較靠譜的方案，我建議你還是學學 Java 吧，多學一門語言沒啥壞處。

如果你只會 C++，可以做做遊戲或非 UI 的公共部分，我不建議使用 QT 或自己畫介面，還是學學 Native 開發吧。

如果你只會 Go，還別指望用它開發移動端，因為目前的實現很低效，而且這和 Go 底層的實現機制密切相關，導致很難優化，所以預計很長一段時間內也不會有改觀。

如果你會 Rust，說明你很喜歡折騰，多半也會前面所有語言，自己做決定吧。。。