【轉(zhuǎn)】聊聊移動端跨平臺開發(fā)的各種技術(shù)

介紹

最近出現(xiàn)的 React Native 再次讓跨平臺移動端開發(fā)這個話題火起來了，曾經(jīng)大家以為在手機上可以像桌面那樣通過 Web 技術(shù)來實現(xiàn)跨平臺開發(fā)瓮下，卻大多因為性能或功能問題而放棄觅丰，不得不針對不同平臺開發(fā)多個版本饵溅。

但這并沒有阻止人們對跨平臺開發(fā)技術(shù)的探索，畢竟誰不想降低開發(fā)成本妇萄，一次編寫就處處運行呢蜕企？除了 React Native，這幾年還出現(xiàn)過許多其它解決方案冠句，本文我將會對這些方案進行技術(shù)分析糖赔，供感興趣的讀者參考。

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

Web 流：也被稱為 Hybrid 技術(shù)放典，它基于 Web 相關(guān)技術(shù)來實現(xiàn)界面及功能

代碼轉(zhuǎn)換流：將某個語言轉(zhuǎn)成 Objective-C、Java 或 C#基茵，然后使用不同平臺下的官方工具來開發(fā)

編譯流：將某個語言編譯為二進制文件奋构，生成動態(tài)庫或打包成 apk/ipa/xap 文件

虛擬機流：通過將某個語言的虛擬機移植到不同平臺上來運行

Web 流

Web 流是大家都比較了解的了，比如著名的PhoneGap/Cordova拱层，它將原生的接口封裝后暴露給 JavaScript弥臼，可以運行在系統(tǒng)自帶的 WebView 中，也可以自己內(nèi)嵌一個Chrome 內(nèi)核根灯。

作為這幾年爭論的熱點径缅，網(wǎng)上已經(jīng)有很多關(guān)于它的討論了，這里我重點聊聊大家最關(guān)心的性能問題烙肺。

Web 流最常被吐槽的就是性能慢（這里指內(nèi)嵌 HTML 的性能纳猪，不考慮網(wǎng)絡(luò)加載時間），可為什么慢呢桃笙？常見的看法是認為「DOM 很慢」氏堤，然而從瀏覽器實現(xiàn)角度來看，其實 DOM 就是將對文檔操作的 API 暴露給了 JavaScript搏明，而 JavaScript 的調(diào)用這些 API 后就進入內(nèi)部的 C++ 實現(xiàn)了鼠锈，這中間并沒有多少性能消耗，所以從理論上來說瀏覽器的 DOM 肯定比 Android 的「DOM」快星著，因為 Android 的展現(xiàn)架構(gòu)大部分功能是用 Java 寫的购笆，在實現(xiàn)相同功能的前提下，C++ 不大可能比 Java 慢（某些情況下 JIT 編譯優(yōu)化確實有可能做得更好虚循，但那只是少數(shù)情況）同欠。

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

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

早期瀏覽器實現(xiàn)比較差炕檩，沒有進行優(yōu)化

CSS 過于復(fù)雜，計算起來更耗時

DOM 提供的接口太有限捌斧，使得難以進行優(yōu)化

第一個問題是最關(guān)鍵也是最難解決的笛质，現(xiàn)在說到 Web 性能差主要說的是 Android 下比較差，在 iOS 下已經(jīng)很流暢了捞蚂，在 Android 4 之前的 WebView 甚至都沒有實現(xiàn) GPU 加速妇押，每次重繪整個頁面，有動畫的時候不卡才怪姓迅。

瀏覽器實現(xiàn)的優(yōu)化可以等 Android 4.4 慢慢普及起來敲霍，因為 4.4 以后就使用 Chrome 來渲染了。

而對于最新的瀏覽器來說丁存，渲染慢的原因就主要是第二個問題：CSS 過于復(fù)雜肩杈，因為從實現(xiàn)原理上看 Chrome 和 Android View 并沒有本質(zhì)上的差別，但 CSS 太靈活功能太多了解寝，所以計算成本很高扩然，自然就更慢了。

那是不是可以通過簡化 CSS 來解決聋伦？實際上還真有人這么嘗試了夫偶，比如Famo.us，它最大的特色就是不讓你寫 CSS觉增，只能使用固定的幾種布局方法兵拢，完全靠 JavaScript 來寫界面，所以它能有效避免寫出低效的 CSS抑片，從而提升性能卵佛。

而對于復(fù)雜的界面及手機下常見的超長的 ListView 來說，第三個問題會更突出敞斋，因為 DOM 是一個很上層的 API，使得 JavaScript 無法做到像 Native 那樣細粒度的控制內(nèi)存及線程疾牲，所以難以進行優(yōu)化植捎，則在硬件較差的機器上會比較明顯。對于這個問題阳柔，我們一年前曾經(jīng)嘗試過嵌入原生組件的方式來解決焰枢，不過這個方案需要依賴應(yīng)用端的支持，或許以后瀏覽器會自帶幾個優(yōu)化后的 Web Components 組件，使用這些組件就能很好解決性能問題济锄。

現(xiàn)階段這三個問題都不好解決暑椰，所以有人想干脆不用 HTML/CSS，自己來畫界面荐绝，比如React canvas直接畫在 Canvas 上一汽，但在我看來這只是現(xiàn)階段解決部分問題的方法，在后面的章節(jié)我會詳細介紹自己畫 UI 的各種問題低滩，這里說個歷史吧召夹，6 年前瀏覽器還比較慢的時候，Bespin就這么干過恕沫，后來這個項目被使用 DOM 的 ACE 取代了监憎，目前包括 TextMirror 和 Atom 在內(nèi)的主流編輯器都是直接使用 DOM，甚至 W3C 有人專門寫了篇文章吐槽用 Canvas 做編輯器的種種缺點婶溯，所以使用 Canvas 要謹慎鲸阔。

另外除了 Canvas廓推，還有人以為 WebGL 快叭首，就嘗試繪制到 WebGL 上，比如HTML-GL力惯，但它目前的實現(xiàn)太偷懶了跑筝，簡單來說就是先用html2canvas將 DOM 節(jié)點渲染成圖片死讹，然后將這個圖片作為貼圖放在 WebGL 中，這等于將瀏覽器中用 C++ 寫的東東在 JavaScript 里實現(xiàn)了一遍曲梗，渲染速度肯定反而更慢赞警，但倒是能用 GLSL 做特效來忽悠人。

硬件加速不等同于「快」虏两，如果你以為硬件加速一定比軟件快愧旦，那你該抽空學學計算機體系結(jié)構(gòu)了

其實除了性能問題，我認為在 Web 流更嚴重的問題是功能缺失定罢，比如 iOS 8 就新增 4000+ API笤虫，而 Web 標準需要漫長的編寫和評審過程，增加 4000 API 我這輩子是等不到了祖凫，即便是 Cordova 這樣自己封裝也忙不過來琼蚯，所以為了更好地使用系統(tǒng)新功能，寫 Native 代碼是必須的惠况。

P.S. 雖然前面提到 HTML/CSS 過于復(fù)雜導致性能問題遭庶，但其實這正是 Web 最大的優(yōu)勢所在，因為 Web 最初的目的就是顯示文檔稠屠，如果你想顯示豐富的圖文排版峦睡，雖然 iOS/Android 都有富文本組件翎苫，但比起 CSS 差太遠了，所以在很多 Native 應(yīng)用中是不可避免要嵌 Web 的榨了。

代碼轉(zhuǎn)換流

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

這種方式雖然聽起來不是很靠譜叔扼，但它卻是成本和風險都最小的事哭，因為代碼轉(zhuǎn)換后就可以用官方提供的各種工具了，和普通開發(fā)區(qū)別不大瓜富，因此不用擔心遇到各種詭異的問題鳍咱，不過需要注意生成的代碼是否可讀，不可讀的方案就別考慮了与柑。

接下來看看目前存在的幾種代碼轉(zhuǎn)換方式谤辜。

將 Java 轉(zhuǎn)成 Objective-C

j2objc能將 Java 代碼轉(zhuǎn)成 Objective-C，據(jù)說 Google 內(nèi)部就是使用它來降低跨平臺開發(fā)成本的价捧，比如 Google Inbox 項目就號稱通過它共用了 70% 的代碼丑念，效果很顯著。

可能有人會覺得奇怪结蟋，為何 Google 要專門開發(fā)一個幫助大家寫 Objective-C 的工具脯倚？還有媒體說 Google 做了件好事，其實吧嵌屎，我覺得 Google 這算盤打得不錯推正，因為基本上重要的應(yīng)用都會同時開發(fā) Android 和 iOS 版本，有了這個工具就意味著宝惰，你可以先開發(fā) Android 版本植榕，然后再開發(fā) iOS 版本。尼夺。尊残。

既然都有成功案例了，這個方案確實值得嘗試淤堵，而且關(guān)鍵是會 Java 的人多啊寝衫，可以通過它來快速移植代碼到 Objective-C 中。

將 Objective-C 轉(zhuǎn)成 Java

除了有 Java 轉(zhuǎn)成 Objective-C拐邪，還有 Objective-C 轉(zhuǎn)成 Java 的方案竞端，那就是MyAppConverter，比起前面的 j2objc庙睡，這個工具更有野心事富，它還打算將 UI 部分也包含進來，從它已轉(zhuǎn)換的列表中可以看到還有 UIKit乘陪、CoreGraphics 等組件统台，使得有些應(yīng)用可以不改代碼就能轉(zhuǎn)成功，不過這點我并不看好啡邑，對于大部分應(yīng)用來說并不現(xiàn)實贱勃。

由于目前是收費項目，我沒有嘗試過谤逼，對技術(shù)細節(jié)也不了解贵扰，所以這里不做評價。

將 Java 轉(zhuǎn)成 C#

Mono 提供了一個將 Java 代碼轉(zhuǎn)成 C# 的工具Sharpen流部，不過似乎用的人不多戚绕，Star 才 118，所以看起來不靠譜枝冀。

還有JUniversal這個工具可以將 Java 轉(zhuǎn)成 C#舞丛，但目前它并沒有發(fā)布公開版本，所以具體情況還待了解果漾，它的一個特色是自帶了簡單的跨平臺庫球切，里面包括文件處理、JSON绒障、HTTP吨凑、OAuth 組件，可以基于它來開發(fā)可復(fù)用的業(yè)務(wù)邏輯户辱。

比起轉(zhuǎn)成 Objective-C 和 Java 的工具鸵钝，轉(zhuǎn)成 C# 的這兩個工具看起來都非常不成熟，估計是用 Windows Phone 的人少焕妙。

將 Haxe 轉(zhuǎn)成其它語言

說到源碼轉(zhuǎn)換就不得不提 Haxe 這個奇特的語言蒋伦，它沒有自己的虛擬機或可執(zhí)行文件編譯器，所以只能通過轉(zhuǎn)成其它語言來運行焚鹊，目前支持轉(zhuǎn)成 Neko（字節(jié)碼）痕届、Javascript、Actionscript 3末患、PHP研叫、C++、Java璧针、C# 和 Python嚷炉，盡管有人實現(xiàn)了轉(zhuǎn)成 Swift的支持，但還是非官方的探橱，所以要想支持 iOS 開發(fā)目前只能通過 Adobe AIR 來運行申屹。

在游戲開發(fā)方面做得不錯绘证，有個跨平臺的游戲引擎OpenFL的，最終可以使用 HTML5 Canvas哗讥、OpenGL 或 Flash 來進行繪制嚷那，OpenFL 的開發(fā)體驗做得相當不錯，同一行代碼不需要修改就能編譯出不同平臺下的可執(zhí)行文件杆煞，因為是通過轉(zhuǎn)成 C++ 方式進行編譯的魏宽，所以在性能和反編譯方面都有優(yōu)勢，可惜目前似乎并不夠穩(wěn)定决乎，不然可以成為 Cocos2d-x 的有利競品队询。

在 OpenFL 基礎(chǔ)上還有個跨平臺的 UI 組件HaxeUI，但界面風格我覺得特別丑构诚，也就只能在游戲中用了蚌斩。

所以目前來看 Haxe 做跨平臺游戲開發(fā)或許可行，但 APP 開發(fā)就別指望了唤反，而基于它來共用代碼實在就更不靠譜了凳寺，因為熟悉它的開發(fā)者極少，反而增加成本彤侍。

XMLVM

除了前面提到的源碼到源碼的轉(zhuǎn)換肠缨，還有XMLVM這種與眾不同的方式，它首先將字節(jié)碼轉(zhuǎn)成一種基于 XML 的中間格式盏阶，然后再通過 XSL 來生成不同語言晒奕，目前支持生成 C、Objective-C名斟、JavaScript脑慧、C#、Python 和 Java砰盐。

雖然基于一個中間字節(jié)碼可以方便支持多語言闷袒，然而它也導致生成代碼不可讀，因為很多語言中的語法糖會在字節(jié)碼中被抹掉岩梳，這是不可逆的囊骤，以下是一個簡單示例生成的 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)

...

在我看來這個方案相當不靠譜冀值，萬一生成的代碼有問題基本沒法修改也物，也沒法調(diào)試代碼，所以不推薦列疗。

小結(jié)

雖然代碼轉(zhuǎn)換這種方式風險小滑蚯，但我覺得對于很多小 APP 來說共享不了多少代碼，因為這類應(yīng)用大多數(shù)圍繞 UI 來開發(fā)的，大部分代碼都和 UI 耦合告材，所以公共部分不多坤次。

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

編譯流

編譯流比前面的代碼轉(zhuǎn)換更進一步，它直接將某個語言編譯為普通平臺下的二進制文件灿渴，這種做法有明顯的優(yōu)缺點：

優(yōu)點

可以重用一些實現(xiàn)很復(fù)雜的代碼，比如之前用 C++ 實現(xiàn)的游戲引擎胰舆，重寫一遍成本太高

編譯后的代碼反編譯困難

或許性能會好些（具體要看實現(xiàn)）

缺點

如果這個工具本身有 Bug 或性能問題骚露，定位和修改成本會很高

編譯后體積不小，尤其是如果要支持 ARMv8 和 x86 的話

接下來我們通過區(qū)分不同語言來介紹這個流派下的各種方案缚窿。

C++ 類

C++ 是最常見的選擇棘幸，因為目前 Android、iOS 和 Windows Phone 都提供了 C++ 開發(fā)的支持倦零，它通常有三種做法：

只用 C++ 實現(xiàn)非界面部分误续，這是官方比較推崇的方案，目前有很多應(yīng)用是這么做的扫茅，比如Mailbox和Microsoft Office蹋嵌。

使用 2D 圖形庫來自己繪制界面，這種做法在桌面比較常見葫隙，因為很多界面都有個性化需求栽烂，但在移動端用得還不多。

使用 OpenGL 來繪制界面恋脚，常見于游戲中腺办。

使用 C++ 實現(xiàn)非界面部分比較常見，所以這里就不重復(fù)介紹了糟描，除了能提升性能和共用代碼怀喉，還有人使用這種方式來隱藏一些關(guān)鍵代碼（比如密鑰），如果你不知道如何構(gòu)建這樣的跨平臺項目船响，可以參考 Dropbox 開源的libmx3項目躬拢，它還內(nèi)嵌了 json 和 sqlite 庫，并通過調(diào)用系統(tǒng)庫來實現(xiàn)對簡單 HTTP灿意、EventLoop 及創(chuàng)建線程的支持估灿。

而如果要用 C++ 實現(xiàn)界面部分，在 iOS 和 Windows Phone 下可以分別使用 C++ 的超集 Objective-C++ 和C++/CX缤剧，所以還比較容易馅袁，但在 Android 下問題就比較麻煩了，主要原因是 Android 的界面絕大部分是 Java 實現(xiàn)的荒辕，所以用 C++ 開發(fā)界面最大的挑戰(zhàn)是如何支持 Android汗销，這有兩種做法：通過 JNI 調(diào)用系統(tǒng)提供的 Java 方法或者自己畫 UI犹褒。

第一種做法雖然可行，但代碼太冗余了比如一個簡單的函數(shù)調(diào)用需要寫那么多代碼：

JNIEnv*env;jclasstestClass=(*env)->FindClass(env,"com/your/package/name/Test");// get ClassjmethodIDconstructor=(*env)->GetMethodID(env,cls,"","()V");jobjecttestObject=(*env)->NewObject(env,testClass,constructor);methodIDcallFromCpp=(*env)->GetMethodID(env,testClass,"callFromCpp","()V");//get methodid(*env)->CallVoidMethod(env,testObject,callFromCpp);

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

看起來很不錯是吧？不過在 Android 5 下就悲劇了削茁，很多效果都沒出來宙枷，比如按鈕沒有漣漪效果，甚至邊框都沒了茧跋，根本原因在于它是通過Qt Quick Controls 的自定義樣式來模擬的慰丛，而不是使用系統(tǒng) UI 組件，因此它享受不到系統(tǒng)升級自動帶來的界面優(yōu)化瘾杭，只能自己再實現(xiàn)一遍诅病，工作量不小。

反而如果最開始用的是 Android 原生組件就什么都不需要做粥烁，而且還能用新的AppCompat庫來在 Android 5 以下實現(xiàn) Material Design 效果贤笆。

最后一種做法是使用 OpenGL 來繪制界面，因為 EGL+OpenGL 本身就是跨平臺讨阻，所以基于它來實現(xiàn)會很方便芥永，目前大多數(shù)跨平臺游戲底層都是這么做的。

既然可以基于 OpenGL 來開發(fā)跨平臺游戲变勇，是否能用它來實現(xiàn)界面恤左？當然是可行的，而且 Android 4 的界面就是基于 OpenGL 的搀绣，不過它并不是只用 OpenGL 的 API飞袋，那樣是不現(xiàn)實的，因為 OpenGL API 最初設(shè)計并不是為了畫 2D 圖形的链患，所以連畫個圓形都沒有直接的方法巧鸭，因此 Android 4 中是通過 Skia 將路徑轉(zhuǎn)換為位置數(shù)組或紋理，然后再交給 OpenGL 渲染的麻捻。

然而要完全實現(xiàn)一遍 Android 的 UI 架構(gòu)工作量不小纲仍，以下是其中部分相關(guān)代碼的代碼量：

路徑代碼行數(shù)

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

其中光是文字渲染就非常復(fù)雜，如果你覺得簡單贸毕，那只能說明你沒看過這個世界有多大郑叠，或許你知道中文有編碼問題、英語有連字符(hyphen)折行明棍，但你是否知道繁體中文有豎排版乡革、阿拉伯文是從右到左的、日語有平假名注音(ルビ)、印度語有元音附標文字(abugida ????)……沸版？

而相比之下如果每個平臺單獨開發(fā)界面嘁傀，看似工作量不小，但目前在各個平臺下都會有良好的官方支持视粮，相關(guān)工具和文檔都很完善细办，所以其實成本沒那么高，而且可以給用戶和系統(tǒng)風格保持一致的良好體驗蕾殴，所以我認為對于大多數(shù)應(yīng)用來說自己畫 UI 是很不劃算的笑撞。

不過也有特例，對于 UI 比較獨特的應(yīng)用來說区宇，自己畫也是有好處的娃殖，除了更靈活的控制，它還能使得不同平臺下風格統(tǒng)一议谷，這在桌面應(yīng)用中很常見，比如 Windows 下你會發(fā)現(xiàn)幾乎每個必備軟件的 UI 都不太一樣堕虹，而且好多都有換膚功能卧晓，在這種情況下很適合自己畫 UI。

Xamarin

Xamarin可以使用 C# 來開發(fā) Android 及 iOS 應(yīng)用赴捞，它是從Mono發(fā)展而來的逼裆，目前看起來商業(yè)運作得不錯，相關(guān)工具及文檔都挺健全赦政。

因為它在 iOS 下是以 AOT 的方式編譯為二進制文件的胜宇，所以把它歸到編譯流來討論，其實它在 Android 是內(nèi)嵌了 Mono 虛擬機來實現(xiàn)的恢着，因此需要裝一個 17M 的運行環(huán)境桐愉。

在 UI 方面，它可以通過調(diào)用系統(tǒng) API 來使用系統(tǒng)內(nèi)置的界面組件掰派，或者基于Xamarin.Forms開發(fā)定制要求不高的跨平臺 UI从诲。

對于熟悉 C# 的團隊來說，這還真是一個看起來很不錯的靡羡，但這種方案最大的問題就是相關(guān)資料不足系洛，遇到問題很可能搜不到解決方案，不過由于時間關(guān)系我并沒有仔細研究略步，推薦看看這篇文章描扯，其中談到它的優(yōu)缺點是：

優(yōu)點

開發(fā) app 所需的基本功能全部都有

有商業(yè)支持，而且這個項目對 Windows Phone 很有利趟薄，微軟會大力支持

缺點

如果深入后會發(fā)現(xiàn)功能缺失绽诚，尤其是定制 UI，因為未開源使得遇到問題時不知道如何修復(fù)

Xamarin 本身有些 Bug

相關(guān)資源太少，沒有原生平臺那么多第三方庫

Xamarin studio 比起 Xcode 和 Android Studio 在功能上還有很大差距

Objective-C 編譯為 Windows Phone

微軟知道自己的 Windows Phone 太非主流憔购，所以很懂事地推出了將Objective-C 項目編譯到 Windows Phone上運行的工具宫峦，目前這個工具的相關(guān)資料很少，鑒于 Visual Studio 支持 Clang玫鸟，所以極有可能是使用 Clang 的前端來編譯导绷，這樣最大的好處是以后支持 Swift 會很方便，因此我歸到編譯流屎飘。

而對于 Android 的支持妥曲，微軟應(yīng)該使用了虛擬機的方式，所以放到下個章節(jié)介紹钦购。

RoboVM

RoboVM可以將 Java 字節(jié)碼編譯為可在 iOS 下運行的機器碼檐盟，這有點類似GCJ，但它的具體實現(xiàn)是先使用Soot將字節(jié)碼編譯為 LLVM IR押桃，然后通過 LLVM 的編譯器編譯成不同平臺下的二進制文件葵萎。

比如簡單的new UITextField(new CGRect(44, 32, 232, 31))最后會變?nèi)缦碌臋C器碼(x86)：

callimp___jump_table__[j]org.robovm.apple.uikit.UITextField[allocator][clinit]movesi,eaxmovdword[ss:esp],ebxcallimp___jump_table__[j]org.robovm.apple.coregraphics.CGRect[allocator][clinit]movedi,eaxmovdword[ss:esp+0x4],edimovdword[ss:esp],ebxmovdword[ss:esp+0xc],0x40460000...

基于字節(jié)碼編譯的好處是可以支持各種在 JVM 上構(gòu)建的語言，比如 Scala唱凯、Kotlin羡忘、Clojure 等。

在運行環(huán)境上磕昼，它使用的 GC 和 GCJ 一樣卷雕，都是Boehm GC，這是一個保守 GC票从，會有內(nèi)存泄露問題漫雕，盡管官方說已經(jīng)優(yōu)化過了影響不大。

在 UI 的支持方面峰鄙，它和 Xamarin 挺像浸间，可以直接用 Java 調(diào)用系統(tǒng)接口來創(chuàng)建界面（最近支持 Interface Builder 了），比如上面的示例就是先馆。另外還號稱能使用JavaFX发框，這樣就能在 iOS 和 Android 上使用同一套 UI 了，不過目前看起來很不靠譜煤墙。

在我看來 RoboVM 目前最大的用途就是使用libGDX開發(fā)游戲了梅惯，盡管在功能上遠不如 Cocos2d-x（尤其是場景及對象管理），但不管怎么說用 Java 比 C++ 還是方便很多（別跟我說沒人用 Java 做游戲仿野，價值 25 億美元的Minecraft就是）铣减，不過本文主要關(guān)心的是 UI 開發(fā)，所以這方面的話題就不深入討論了脚作，

RoboVM 和 Xamarin 很像葫哗，但 RoboVM 風險會小些缔刹，因為它只需要把 iOS 支持好就行了，對優(yōu)先開發(fā) Android 版本的團隊挺適用劣针，但目前官方文檔太少了校镐，而且不清楚 RoboVM 在 iOS 上的性能和穩(wěn)定性怎樣。

Swift - Apportable/Silver

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

所以后來它又推出了Tengu這個專門針對 APP 開發(fā)的工具襟己，它的比起之前的方案更靈活些引谜，本質(zhì)上有點類似 C++ 公共庫的方案，只不過語言變成了 Swift/Objective-C擎浴，使用 Swift/Objective-C 來編譯生成跨平臺的 SO 文件员咽，提供給 Android 調(diào)用。

另一個類似的是Silver贮预，不過目前沒正式發(fā)布贝室，它不僅支持 Swift，還支持 C# 和自創(chuàng)的 Oxygene 語言（看起來像 Pascal）仿吞，在界面方面它還有個跨平臺非 UI 庫Sugar档玻，然而目前 Star 數(shù)只有 17，太非主流了茫藏，所以實在懶得研究它凡恍。

使用 Swift 編譯為 SO 給 Android 用雖然可行沮趣，但目前相關(guān)工具都不太成熟，所以不推薦使用夯到。

Go 是最近幾年很火的后端服務(wù)開發(fā)語言枣申，它語法簡單且高性能售葡，目前在國內(nèi)有不少用戶。

Go 從 1.4 版本開始支持開發(fā)Android 應(yīng)用（并將在 1.5 版本支持iOS）忠藤，不過前只能調(diào)用很少的 API挟伙，比如 OpenGL 等，所以只能用來開發(fā)游戲模孩，但我感覺并不靠譜尖阔，現(xiàn)在還有誰直接基于 OpenGL 開發(fā)游戲？大部分游戲都是基于某個框架的榨咐，而 Go 在這方面太缺乏了介却，我只看到一個桌面端Azul3D，而且非常不成熟块茁。

因為 Android 的View層完全是基于 Java 寫的齿坷，要想用 Go 來寫 UI 不可避免要調(diào)用 Java 代碼桂肌，而這方面 Go 還沒有簡便的方式，目前 Go 調(diào)用外部代碼只能使用 cgo永淌，通過 cgo 再調(diào)用 jni崎场，這需要寫很多中間代碼，所以目前 Go 1.4 采用的是類似 RPC 通訊的方式來做遂蛀，從它源碼中例子可以看出這種方式有多麻煩谭跨，性能肯定有不小的損失。

而且 cgo 的實現(xiàn)本身就對性能有損失答恶，除了各種無關(guān)函數(shù)的調(diào)用饺蚊，它還會鎖定一個 Go 的系統(tǒng)線程，這會影響其它 gorountine 的運行悬嗓，如果同時運行太多外部調(diào)用污呼，甚至會導致所有 gorountine 等待。

這個問題的根源在于 Go 的棧是可以自動擴充的包竹，這種方式有利于創(chuàng)建無數(shù) gorountine燕酷，但卻也導致了無法直接調(diào)用 C 編譯后的函數(shù)，需要進行棧切換周瞎。

所以使用 Go 開發(fā)跨平臺移動端應(yīng)用目前不靠譜苗缩。

話說 Rust 沒有 Go 的性能，它調(diào)用 C 函數(shù)是沒有性能損耗的声诸，但目前 Rust 還沒提供對 iOS/Android 的官方支持酱讶，盡管有人還是嘗試過是可行的，但現(xiàn)在還不穩(wěn)定彼乌，從 Rust 語言本身的設(shè)計來看泻肯，它挺適合取代 C++ 來做這種跨平臺公共代碼，但它的缺點是語法復(fù)雜慰照，會嚇跑很多開發(fā)者灶挟。

Xojo

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

它的定位應(yīng)該是給小朋友或業(yè)余開發(fā)者用的惕医，因為似乎看起來學習成本低，但我不這么認為噩斟，因為用得人少曹锨，反而網(wǎng)上資料會很少，所以恐怕成本會更高剃允。

因為時間關(guān)系沛简，以及對 BASIC 無愛齐鲤，我并沒有怎么研究它。

小結(jié)

從目前分析的情況看椒楣，C++ 是比較穩(wěn)妥的選擇给郊，但它對團隊成員有要求，如果大家都沒寫過 C++捧灰，可以試試 Xamrin 或 RoboVM淆九。

虛擬機流

除了編譯為不同平臺下的二進制文件，還有另一種常見做法是通過虛擬機來支持跨平臺運行毛俏，比如 JavaScript 和 Lua 都是天生的內(nèi)嵌語言炭庙，所以在這個流派中很多方案都使用了這兩個語言。

不過虛擬機流會遇到兩個問題：一個是性能損耗煌寇，另一個是虛擬機本身也會占不小的體積焕蹄。

Java 系

說到跨平臺虛擬機大家都會想到 Java，因為這個語言一開始就是為了跨平臺設(shè)計的阀溶，Sun 的 J2ME早在 1998 年就有了腻脏，在 iPhone 出來前的手機上，很多小游戲都是基于 J2ME 開發(fā)的银锻，這個項目至今還活著永品，能運行在 Raspberry Pi 上。

前面提到微軟提供了將 Objective-C 編譯在 Windows Phone 上運行的工具击纬，在對 Android 的支持上我沒找到的詳細資料鼎姐，所以就暫時認為它是虛擬機的方式，從Astoria項目的介紹上看它做得非常完善更振，不僅能支持 NDK 中的 C++症见，還實現(xiàn)了 Java 的 debug 接口，使得可以直接用 Android Studio 等 IDE 來調(diào)試殃饿，整個開發(fā)體驗和在 Android 手機上幾乎沒區(qū)別。

另外 BlackBerry 10 也是通過內(nèi)嵌虛擬機來支持直接運行 Android 應(yīng)用芋肠，不過據(jù)說比較卡乎芳。

不過前面提到 C# 和 Java 在 iOS 端的方案都是通過 AOT 的方式實現(xiàn)的，目前還沒見到有 Java 虛擬機的方案帖池，我想主要原因是 iOS 的限制奈惑，普通 app 不能調(diào)用 mmap、mprotect睡汹，所以無法使用 JIT 來優(yōu)化性能肴甸，如果 iOS 開放，或許哪天有人開發(fā)一個像微軟那樣能直接在 iOS 上運行 Android 應(yīng)用的虛擬機囚巴，就不需要跨平臺開發(fā)了原在，大家只需要學 Android 開發(fā)就夠了友扰。。庶柿。

Titanium/Hyperloop

Titanium 應(yīng)該不少人聽過村怪，它和 PhoneGap 幾乎是同時期的著名跨平臺方案，和 PhoneGap 最大的區(qū)別是：它的界面沒有使用 HTML/CSS浮庐，而是自己設(shè)計了一套基于 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.xmlHello, World</Alloy>

前面我們說過由于 CSS 的過于靈活拖累了瀏覽器的性能，那是否自己建立一套 UI 機制會更靠譜呢审残？盡管這么做對性能確實有好處，然而它又帶來了學習成本問題没宾，做簡單的界面問題不大迁酸，一旦要深入定制開發(fā)就會發(fā)現(xiàn)相關(guān)資料太少儿惫，所以還是不靠譜荣月。

Titanium 還提供了一套跨平臺的 API 來方便調(diào)用婴程，這么做是它的優(yōu)點更是缺點衙四，尤其是下面三個問題：

API 有限，因為這是由 Titanium 提供的患亿，它肯定會比官方 API 少且有延遲传蹈，Titanium 是肯定跟不過來的

相關(guān)資料及社區(qū)有限，比起 Android/iOS 差遠了步藕，遇到問題都不知道去哪找答案

缺乏第三方庫惦界，第三方庫肯定不會專門為 Titanium 提供一個版本，所以不管用什么都得自己封裝

Titanium 也意識到了這個問題咙冗，所以目前在開發(fā)下一代的解決方案Hyperloop沾歪，它可以將 JavaScript 編譯為原生代碼，這樣的好處是調(diào)用原生 API 會比較方便雾消，比如它的 iOS 是這樣寫的

@import("UIKit");@import("CoreGraphics");varview=newUIView();view.frame=CGRectMake(0,0,100,100);

這個方案和之前的說的 Xamarin 很相似瞬逊，基本上等于將 Objective-C 翻譯為 JavaScript 后的樣子，意味著你可以對著 Apple 的官方文檔開發(fā)仪或，不過如果發(fā)現(xiàn)某些 Objective-C 語法發(fā)現(xiàn)不知道對應(yīng)的 JavaScript 怎么寫時就悲劇了，只有自己摸索士骤。

但從 Github 上的提交歷史看范删，這項目都快開發(fā)兩年了，但至今仍然是試驗階段拷肌，從更新頻率來看到旦，最近一年只提交了 8 次旨巷，所以恐怕是要棄坑了，非常不靠譜添忘。

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

NativeScript

之前說到 Titanium 自定義 API 帶來的各種問題搁骑，于是就有人換了個思路斧吐，比如前段時間推出的NativeScript，它的方法說白了就是用工具來自動生成 wrapper API仲器，和系統(tǒng) API 保持一致煤率。

有了這個自動生成 wrapper 的工具，它就能方便基于系統(tǒng) API 來開發(fā)跨平臺組件乏冀，以簡單的Button為例蝶糯，源碼在cross-platform-modules/ui/button中，它在 Android 下是這樣實現(xiàn)的（TypeScript 省略了很多代碼）

exportclassButtonextendscommon.Button{private_android:android.widget.Button;private_isPressed:boolean;public_createUI(){varthat=newWeakRef(this);this._android=newandroid.widget.Button(this._context);this._android.setOnClickListener(newandroid.view.View.OnClickListener({getowner(){returnthat.get();},onClick:function(v){if(this.owner){this.owner._emit(common.knownEvents.tap);}}}));}}

而在 iOS 下是這樣實現(xiàn)的（省略了很多代碼）

exportclassButtonextendscommon.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=newstateChanged.ControlStateChangeListener(this._ios,(s:string)=>{this._goToVisualState(s);});}getios():UIButton{returnthis._ios;}}

可以看到用法和官方 SDK 中的調(diào)用方式是一樣的辆沦，只不過語言換成了 JavaScript昼捍，并且寫法看起來比較詭異罷了，風格類似前面的 Hyperloop 類似肢扯，所以也同樣會有語法轉(zhuǎn)換的問題妒茬。

這么做最大的好處就是能完整支持所有系統(tǒng) API，對于第三方庫也能很好支持鹃彻，但它目前最大缺點是生成的文件體積過大郊闯，即便什么都不做，生成的 apk 文件也有 8.4 MB蛛株，因為它將所有 API binding 都生成了团赁，而且這也導致在 Android 下首次打開速度很慢。

從底層實現(xiàn)上看谨履，NativeScript 在 Android 下內(nèi)嵌了 V8欢摄，而在 iOS 下內(nèi)嵌了自己編譯的 JavaScriptCore（這意味著沒有 JIT 優(yōu)化，具體原因前面提到了）笋粟，這樣的好處是能調(diào)用更底層的 API怀挠，也避免了不同操作系統(tǒng)版本下 JS 引擎不一致帶來的問題，但后果是生成文件的體積變大和在 iOS 下性能不如 WKWebView害捕。

WKWebView 是基于多進程實現(xiàn)的绿淋，它在 iOS 的白名單中，所以能支持 JIT尝盼。

它的使用體驗很不錯吞滞，做到了一鍵編譯運行，而且還有 MVVM 的支持，能進行數(shù)據(jù)雙向綁定裁赠。

在我看來 NativeScript 和 Titanium 都有個很大的缺點殿漠，那就是排它性太強，如果你要用這兩個方案佩捞，就得完整基于它們進行開發(fā)绞幌，不能在某些 View 下進行嘗試，也不支持直接嵌入第三方 View一忱，有沒有方案能很好地解決這兩個問題莲蜘？有，那就是我們接下來要介紹的 React Native掀潮。

React Native

關(guān)于 React Native 目前網(wǎng)上有很多討論了菇夸，知乎上也有不少回答，盡管有些回答從底層實現(xiàn)角度看并不準確仪吧，但大部分關(guān)鍵點倒是都提到了庄新。

鑒于我不喜歡重復(fù)別人說過的話，這里就聊點別的薯鼠。

React Native 的思路簡單來說就是在不同平臺下使用平臺自帶的 UI 組件择诈，這個思路并不新奇，十幾年前的SWT就是這么做的出皇。

從團隊上看羞芍，F(xiàn)acebook 的 iOS 團隊中不少成員是來自 Apple 的，比如Paper 團隊的經(jīng)理及其中不少成員都是郊艘，因為 iOS 不開源荷科，所以從 Apple 中出來的開發(fā)者還是有優(yōu)勢的，比如前 Apple 開發(fā)者搞出來的Duet就秒殺了市面上所有其他方案纱注，而且從 Facebook 在 iOS 上開源的項目看他們在 iOS 方面的經(jīng)驗和技術(shù)都不錯畏浆，所以從團隊角度看他們做出來的東西不會太差。

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

@implementationArticleComponent+(instancetype)newWithArticle:(ArticleModel*)article{return[supernewWithComponent:[CKStackLayoutComponentnewWithView:{}size:{}style:{.direction=CKStackLayoutDirectionVertical,}children:{{[HeaderComponentnewWithArticle:article]},{[MessageComponentnewWithMessage:article.message]},{[FooterComponentnewWithFooter:article.footer]},}];}@end

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

我看到有人說這是 Facebook 回歸 H5氧枣，但其實 React Native 和 Web 扯不上太多關(guān)系沐兵，我所理解的 Web 是指 W3C 定義的那些規(guī)范，比如 HTML便监、CSS扎谎、DOM，而 React Native 主要是借鑒了 CSS 中的 Flexbox 寫法，還有 navigator簿透、XMLHttpRequest 等幾個簡單的 API，更別說完全沒有 Web 的開放性解藻，所以 React Native 和 HTML 5 完全不是一回事老充。

Facebook Groups 的 iOS 版本很大一部分基于 React Native 開發(fā)，其中用到了不少內(nèi)部通過組件螟左，比如 ReactGraphQL啡浊，這里我就八卦一下它，GraphQL 這是一個結(jié)構(gòu)化數(shù)據(jù)查詢的語法胶背，就像 MongoDB 查詢語法那樣查詢 JSON 數(shù)據(jù)巷嚣，不過它并不是一種文檔型數(shù)據(jù)庫，而只是一個中間層钳吟，具體的數(shù)據(jù)源可以連其它數(shù)據(jù)庫廷粒，它想取代的應(yīng)該是 RESTful 那樣的前后端簡單 HTTP 協(xié)議，讓前端更方便的獲取數(shù)據(jù)红且，據(jù)說將會開源（看起來打算用 Node 實現(xiàn)）坝茎。

寫文章拖時間太長的問題就是這期間會發(fā)生很多事情，比如 GraphQL 在我開始寫的時候外界都不知道暇番，所以需要八卦一下嗤放，結(jié)果現(xiàn)在官方已經(jīng)宣布了，不過官方并沒提到我說的那個 Node 實現(xiàn)壁酬，它目前還在悄悄開發(fā)階段

React Native 的官方視頻中說它能做到 App 內(nèi)實時更新次酌，其實這是 Apple 明文禁止的（App Store Review Guidelines中的 2.7），要做得低調(diào)舆乔。

評論中有人提到 Apple 居然在 iOS 8.2 中改條款了岳服，可以下載執(zhí)行 JavaScript，而且 UIKit 的作者都覺得 React Native 很贊

我比較喜歡的是 React Native 中用到了Flow蜕煌，它支持定義函數(shù)參數(shù)的類型派阱，極大提升了代碼可讀性，另外還能使用 ES6 的語法斜纪，比如 class 關(guān)鍵字等贫母。

React Native 比傳統(tǒng) Objective-C 和 UIView 的學習成本低多了，熟悉 JavaScript 的開發(fā)者應(yīng)該半天內(nèi)就能寫個使用標準 UI 的界面盒刚，而且用 XML+CSS 畫界面也遠比 UIView 中用 Frame 進行手工布局更易讀（我沒用過 Storyboards腺劣，它雖然看起來直觀，但多人編輯很容易沖突）因块，感興趣可以抽空看看這個詳細的入門教程橘原，親自動手試試就能體會到了，Command + R 更新代碼感覺很神奇。

它目前已經(jīng)有組件倉庫了趾断，而且在 github 上都有 500 多倉庫了拒名，其中有 sqlite、Camera 等原生組件芋酌，隨著這些第三方組件的完善增显，基于 React Native 開發(fā)越來越不需要寫原生代碼了。

不過壞消息是 React Native 的 Android 版本還要等半年脐帝，這可以理解同云，因為在 Android 上問題要復(fù)雜得多，有 Dalvik/ART 攔在中間堵腹，使得交互起來很麻煩炸站。

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

React Native 要解決的是開發(fā)效率問題疚顷，它并沒指望完全取代 Native 開發(fā)旱易，它的 rootView 繼承自 UIView，所以可以在部分 View 是使用荡含，很方便混著咒唆，不需要重寫整個 app，而且混用的時候還需要顯示地將 API 暴露給 JavaScript

NativeScript 則像是 Titanium 那樣企圖完全使用 JavaScript 開發(fā)释液，將所有系統(tǒng) API 都暴露給了 JavaScript全释，讓 JavaScript 語言默認就擁有 Native 語言的各種能力，然后再次基礎(chǔ)上來開發(fā)

方向的不同導致這兩個產(chǎn)品將會有不同的結(jié)局误债，我認為 React Native 肯定會完勝 NativeScript浸船，因為它的使用風險要小很多，你可以隨時將部分 View 使用 React Native 來試驗寝蹈，遇到問題就改回 Native 實現(xiàn)李命，風險可控，而用 NativeScript 就不行了箫老，這導致大家在技術(shù)選型的時候不敢使用 NativeScript封字。

話說 Angular 團隊看到 React Native 后表示不淡定了，于是開始重新設(shè)計 Angular 2 的展現(xiàn)架構(gòu)耍鬓，將現(xiàn)有的 Render 層獨立出來阔籽，以便于做到像 React 那樣適應(yīng)不同的運行環(huán)境，可以運行在 NativeScript 上牲蜀。

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

游戲引擎中的腳本

游戲引擎大多都能跨平臺在辆，為了提升開發(fā)效率证薇，不少引擎還內(nèi)嵌了對腳本支持，比如：

Ejecta匆篓，它實現(xiàn)了 Canvas 及 Audio 的 API浑度，可以開發(fā)簡單的游戲，但目前還不支持 Android

CocoonJS鸦概，實現(xiàn)了 WebGL 的 API俺泣，可以運行 Three.js 寫的游戲

Unreal Engine 3，可以使用 UnrealScript 來開發(fā)完残，這個語言的語法很像 Java

Cocos2d-js，Cocos2d-x 的 JavaScript binding横漏，它內(nèi)部使用的 JS 引擎是 SpiderMonkey

Unity 3D谨设，可以使用 C# 或 JavaScript 開發(fā)游戲邏輯

Corona，使用 Lua 來開發(fā)

...

目前這種方式只有 Unity 3D 發(fā)展比較好缎浇，Cocos2d-JS 據(jù)說還行扎拣，有些小游戲在使用，Corona感覺比較非主流素跺，雖然它也支持簡單的按鈕等界面元素二蓝，但用來寫 APP 我不看好，因為不開源所以沒研究指厌，目前看來最大的好處似乎是虛擬機體積小刊愚，內(nèi)嵌版本官方號稱只有 1.4M，這是 Lua 引擎比較大的優(yōu)勢踩验。

而剩下的 3 個都基本上掛了鸥诽，Ejecta 至今還不支持 Android，CocoonJS 轉(zhuǎn)型為類似 Crosswalk 的 WebView 方案箕憾，而 Unreal Engine 4 開始不再支持 UnrealScript牡借，而是轉(zhuǎn)向了使用 C++ 開發(fā)，感興趣可以圍觀一下 Epic 創(chuàng)始人解釋為什么要這么做袭异。

當然钠龙，這些游戲引擎都不適合用來做 APP，一方面是會遇到前面提到的界面繪制問題御铃，另一方面游戲引擎的實現(xiàn)一般都要不斷重繪碴里，這肯定比普通 App 更耗電，很容易被用戶發(fā)現(xiàn)后怒刪畅买。

Adobe AIR

從我周邊了解到的情況看并闲，幾乎所有人都以為 Flash 徹底放棄移動端了，不得不說 Adobe 的宣傳真是失策谷羞，明明只是放棄移動瀏覽器端插件帝火，F(xiàn)lash 還是可以在 iOS 下運行的好不好溜徙，那就是Adobe AIR，對于熟悉 ActionScript 的團隊來說犀填，這是一種挺好的跨平臺游戲開發(fā)解決方案蠢壹，國內(nèi)游戲公司之前有用，現(xiàn)在還有沒人用我就不知道了九巡，不過考慮到很多不明真相的小朋友都以為 Flash 在移動端掛了图贸，所以后備力量肯定嚴重不足，連人都招不到冕广，其它就別想了疏日。

評論中有人指出在 iOS 下是通過編譯實現(xiàn)的，看來和 Xamarin RoboVM 很類似撒汉。

但開發(fā) APP 方面沟优，它同樣缺乏好的 UI 庫，Flex使用體驗很差睬辐，目前基本上算掛了挠阁，目前只有Feathers還算能看，不過主要是給游戲中的 UI 設(shè)計的溯饵，并不適合用來開發(fā) APP侵俗。

Dart

Dart 在 Web 基本上失敗了，于是開始轉(zhuǎn)戰(zhàn)移動開發(fā)丰刊，目前有兩個思路隘谣，一個是類似 Lua 那樣的嵌入語言來統(tǒng)一公共代碼蝠猬，但因為 Dart 虛擬機源自 V8蹂风，在一開始設(shè)計的時候就只有 JIT 而沒有解釋器灵嫌，甚至連字節(jié)碼都沒有拣宰，所以它無法在 iOS 下運行确垫，于是 Dart 團隊又做了個小巧的虛擬機Fletch括袒，它基于傳統(tǒng)的字節(jié)碼解釋執(zhí)行方式來運行毕莱，目前代碼只有 1w 多行蔑鹦，和 Lua 一樣輕量級逗概。

另一個就是最近比較熱門的Sky弟晚，這里吐槽一下國內(nèi)外的媒體，我看到的報道都是說 Google 想要用 Dart 取代 Android 下的 Java 開發(fā)逾苫。卿城。。這個東東確實是 Google 的 Chrome 團隊開發(fā)的铅搓，但 Google 是一個很大的公司好不好瑟押，內(nèi)部有無數(shù)小團隊，某個小團隊并不能代表個 Google星掰，如果真是 Google 高層的決定多望，它將會在 Google I/O 大會主題演講上推出來嫩舟，而不是 Dart Developer Summit 這樣非主流的技術(shù)分享。

有報道稱 Sky 只支持在線應(yīng)用怀偷，不支持離線家厌，這錯得太離譜了，人家只是為了演示它的在線更新能力椎工，你要想將代碼內(nèi)嵌到 app 里當然是可以的饭于。

Sky 的架構(gòu)如下圖所示，它參考了 Chrome维蒙，依靠一個消息系統(tǒng)來和本地環(huán)境進行通訊掰吕，使得 Dart 的代碼和平臺無關(guān)，可以運行在各種平臺上颅痊。

如果你讀過前面的文章畴栖，那你一定和我一樣非常關(guān)心一個問題：Sky 的 UI 是怎么繪制出來的？使用系統(tǒng)還是自己畫八千？一開始看 Sky 介紹視頻的時候，我還以為它底層繪制基于 Chrome燎猛，因為這個視頻的演講者是Eric Seidel恋捆，他是 WebKit 項目中非常有名的開發(fā)者，早年在 Apple 開發(fā) WebKit重绷，2008 年跳槽去了 Chrome 團隊沸停，但他在演講中并沒有提到 WebView，而且演示的時候界面非常像原生 Material Design 效果（比如點擊有漣漪效果）昭卓，所以我又覺得它是類似 React Native 那樣使用原生 UI愤钾。

然而當我下載那個應(yīng)用分析后發(fā)現(xiàn)，它既沒使用 Chrome/WebView 也沒使用原生 UI 組件候醒，難不成是自己繪制的能颁？

從 Sky SDK 的代碼上看，它其中有非常多 Web 的痕跡倒淫，比如支持標準的 CSS伙菊、很多 DOM API，但它編譯后的體積非常小敌土，libsky_shell.so只有 8.7 MB镜硕，我之前嘗試精簡過 Chrome 內(nèi)核，將 WebRTC 等周邊功能刪掉也要 22 MB返干，這么小的體積肯定要刪 Web 核心功能兴枯，比如 SVG 和部分 CSS3，所以我懷疑它實現(xiàn)了簡版的 Chrome 內(nèi)核渲染矩欠。

后來無意間看了一下 Mojo 的代碼财剖，才證實確實如此悠夯，原來前面那張圖中介紹的 Mojo 其實并不完整，Mojo 不僅僅是一個消息系統(tǒng)疗疟，它是一個簡版的 Chrome 內(nèi)核策彤！使用 cloc 統(tǒng)計代碼就暴露了：

? 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 行啊，而且一看目錄結(jié)構(gòu)就是濃濃的 Chromium 風格匣摘，至少從技術(shù)難度來說絕對秒掉前面所有方案音榜，也印證了我前面說過如果有簡化版 CSS/HTML 就能很好解決性能問題庞瘸。

這也讓我理解了為什么 Eric 在談到 Mojo 的時候語焉不詳，讓人誤以為僅僅是一個消息系統(tǒng)擦囊，他要是明確說這是一個精簡版 Chrome瞬场，那得引起多大的誤會啊贯被，沒準會有小編用「Google 宣布開發(fā)下一代瀏覽器內(nèi)核取代 Blink」這樣的標題了彤灶。

之前 Dart 決定不將 Dart VM 放到 Chrome 里幌陕，原來并不是因為被眾人反對而死心了苞轿，而是因為 fork 了一個 Chrome 自己拿來玩了搬卒。

綜合來看契邀，目前 Dart 的這兩個方案都非常不成熟失暴，Sky 雖然在技術(shù)上看很強大，但 Dart 語言目前接受度非常低欠橘，比起它所帶來的跨平臺優(yōu)點现恼，它的缺點更大叉袍，比如無法使用第三方 Native UI 庫喳逛，也無法使用第三方 Web UI 庫润文，這導致它的社區(qū)會非常難發(fā)展典蝌，命中注定非主流赠法，真可惜了這幫技術(shù)大牛砖织，但方向比努力更重要侧纯，希望他們能盡早醒悟眶熬，讓 Sky 也支持 JavaScript娜氏。

我的結(jié)論

看到這里估計不少讀者暈了，有那么多種方案绵疲，最后到底哪個最適合自己盔憨？該學哪個郁岩？這里簡單說說我的看法驯用。

如果你只會 JavaScript蝴乔，那目前最好的方案是 React Native薇正，有了它你即使不了解 Native 開發(fā)也能寫出很多中小應(yīng)用挖腰，反正多半不會火审轮，花太多精力也沒意義疾渣，等萬一火了再學 Native 開發(fā)也不遲啊榴捡。

如果你只會 Java吊圾，那可以嘗試 RoboVM 或 j2objc项乒，j2objc 雖然目前更穩(wěn)定靠譜，但它不能像 RoboVM 那樣完全用 Java 開發(fā)埃碱，所以你還得學 Objective-C 來寫界面砚殿，而 RoboVM 的缺點就是貌似還不太穩(wěn)定似炎，而且似乎除了游戲以外還沒見到比較知名的應(yīng)用使用羡藐，而它這種方案注定會比 j2objc 更容易出問題辉阶，所以你得做好踩坑的心理準備谆甜。

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

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

如果你只會 C++，可以做做游戲或非 UI 的公共部分，我不建議使用 QT 或自己畫界面斧蜕，還是學學 Native 開發(fā)吧批销。

如果你只會 Go均芽，還別指望用它開發(fā)移動端，因為目前的實現(xiàn)很低效布朦，而且這和 Go 底層的實現(xiàn)機制密切相關(guān)是趴，導致很難優(yōu)化唆途，所以預(yù)計很長一段時間內(nèi)也不會有改觀。

如果你會 Rust温赔，說明你很喜歡折騰陶贼，多半也會前面所有語言，自己做決定吧枉氮。聊替。淹辞。

當然象缀，上面都是針對個人的央星，對于團隊來說，那不用想了颓遏，肯定用 Native叁幢，然后混用內(nèi)嵌的方案，比如 Lua黍判、React Native顷帖，前面那些排它的方案（比如 Titanium）千萬別選，會死很慘震糖。

本文涉及到的技術(shù)點很多，有什么不準確的地方歡迎提出颁井，另外可以關(guān)注我的微博weibo.com/nwind進行交流雅宾。

P.S. 本文說的是移動端，很多人覺得跨平臺從來都不靠譜蜀变，但其實是有的库北，那就是 Web，這個歷史上最成功的例子杂腰，太成功以致于大家都習以為常了，大樹之下恤筛，寸草不生毒坛，它擠掉了其它方案的生存空間，十幾年前還有 B/S 和 C/S 之爭呢豪直。

分類:?Technology

好文要頂?關(guān)注我?收藏該文??