介紹

最近出現(xiàn)的 React Native 再次讓跨平臺(tái)移動(dòng)端開(kāi)發(fā)這個(gè)話題火起來(lái)了，曾經(jīng)大家以為在手機(jī)上可以像桌面那樣通過(guò) Web 技術(shù)來(lái)實(shí)現(xiàn)跨平臺(tái)開(kāi)發(fā)悯姊，卻大多因?yàn)樾阅芑蚬δ軉?wèn)題而放棄圾浅，不得不針對(duì)不同平臺(tái)開(kāi)發(fā)多個(gè)版本捅厂。
但這并沒(méi)有阻止人們對(duì)跨平臺(tái)開(kāi)發(fā)技術(shù)的探索糊渊，畢竟誰(shuí)不想降低開(kāi)發(fā)成本，一次編寫(xiě)就處處運(yùn)行呢半哟？除了 React Native，這幾年還出現(xiàn)過(guò)許多其它解決方案签餐，本文我將會(huì)對(duì)這些方案進(jìn)行技術(shù)分析镜沽，供感興趣的讀者參考。
為了方便討論贱田，我將它們分為了以下 4 大流派：

• Web 流：也被稱(chēng)為 Hybrid 技術(shù)缅茉，它基于 Web 相關(guān)技術(shù)來(lái)實(shí)現(xiàn)界面及功能
• 代碼轉(zhuǎn)換流：將某個(gè)語(yǔ)言轉(zhuǎn)成 Objective-C、Java 或 C#男摧，然后使用不同平臺(tái)下的官方工具來(lái)開(kāi)發(fā)
• 編譯流：將某個(gè)語(yǔ)言編譯為二進(jìn)制文件蔬墩，生成動(dòng)態(tài)庫(kù)或打包成 apk/ipa/xap 文件
• 虛擬機(jī)流：通過(guò)將某個(gè)語(yǔ)言的虛擬機(jī)移植到不同平臺(tái)上來(lái)運(yùn)行

Web 流

Web 流是大家都比較了解的了，比如著名的 PhoneGap/Cordova耗拓，它將原生的接口封裝后暴露給 JavaScript拇颅，可以運(yùn)行在系統(tǒng)自帶的 WebView 中，也可以自己內(nèi)嵌一個(gè) Chrome 內(nèi)核 乔询。
作為這幾年?duì)幷摰臒狳c(diǎn)樟插，網(wǎng)上已經(jīng)有很多關(guān)于它的討論了，這里我重點(diǎn)聊聊大家最關(guān)心的性能問(wèn)題竿刁。
Web 流最常被吐槽的就是性能慢（這里指內(nèi)嵌 HTML 的性能黄锤，不考慮網(wǎng)絡(luò)加載時(shí)間），可為什么慢呢食拜？常見(jiàn)的看法是認(rèn)為「DOM 很慢」鸵熟，然而從瀏覽器實(shí)現(xiàn)角度來(lái)看，其實(shí) DOM 就是將對(duì)文檔操作的 API 暴露給了 JavaScript负甸，而 JavaScript 的調(diào)用這些 API 后就進(jìn)入內(nèi)部的 C++ 實(shí)現(xiàn)了流强，這中間并沒(méi)有多少性能消耗，所以從理論上來(lái)說(shuō)瀏覽器的 DOM 肯定比 Android 的「DOM」快呻待，因?yàn)?Android 的展現(xiàn)架構(gòu)大部分功能是用 Java 寫(xiě)的打月，在實(shí)現(xiàn)相同功能的前提下，C++ 不大可能比 Java 慢（某些情況下 JIT 編譯優(yōu)化確實(shí)有可能做得更好蚕捉，但那只是少數(shù)情況）奏篙。
所以從字面意思上看「DOM 很慢」的說(shuō)法是錯(cuò)誤的，這個(gè)看法之所以很普遍鱼冀，可能是因?yàn)榇蟛糠秩藢?duì)瀏覽器實(shí)現(xiàn)不了解报破，只知道瀏覽器有 DOM悠就，所以不管什么問(wèn)題都只能抱怨它了。
那么問(wèn)題在哪呢充易？在我看來(lái)有三方面的問(wèn)題：

• 早期瀏覽器實(shí)現(xiàn)比較差梗脾，沒(méi)有進(jìn)行優(yōu)化
• CSS 過(guò)于復(fù)雜，計(jì)算起來(lái)更耗時(shí)
• DOM 提供的接口太有限盹靴，使得難以進(jìn)行優(yōu)化

第一個(gè)問(wèn)題是最關(guān)鍵也是最難解決的炸茧，現(xiàn)在說(shuō)到 Web 性能差主要說(shuō)的是 Android 下比較差，在 iOS 下已經(jīng)很流暢了稿静，在 Android 4 之前的 WebView 甚至都沒(méi)有實(shí)現(xiàn) GPU 加速梭冠，每次重繪整個(gè)頁(yè)面，有動(dòng)畫(huà)的時(shí)候不卡才怪改备。
瀏覽器實(shí)現(xiàn)的優(yōu)化可以等 Android 4.4 慢慢普及起來(lái)控漠，因?yàn)?4.4 以后就使用 Chrome 來(lái)渲染了。
而對(duì)于最新的瀏覽器來(lái)說(shuō)悬钳，渲染慢的原因就主要是第二個(gè)問(wèn)題：CSS 過(guò)于復(fù)雜盐捷，因?yàn)閺膶?shí)現(xiàn)原理上看 Chrome 和 Android View 并沒(méi)有本質(zhì)上的差別，但 CSS 太靈活功能太多了默勾，所以計(jì)算成本很高碉渡，自然就更慢了。
那是不是可以通過(guò)簡(jiǎn)化 CSS 來(lái)解決母剥？實(shí)際上還真有人這么嘗試了滞诺，比如 Famo.us，它最大的特色就是不讓你寫(xiě) CSS环疼，只能使用固定的幾種布局方法习霹，完全靠 JavaScript 來(lái)寫(xiě)界面，所以它能有效避免寫(xiě)出低效的 CSS秦爆，從而提升性能序愚。
而對(duì)于復(fù)雜的界面及手機(jī)下常見(jiàn)的超長(zhǎng)的 ListView 來(lái)說(shuō)，第三個(gè)問(wèn)題會(huì)更突出等限，因?yàn)?DOM 是一個(gè)很上層的 API，使得 JavaScript 無(wú)法做到像 Native 那樣細(xì)粒度的控制內(nèi)存及線程芬膝，所以難以進(jìn)行優(yōu)化望门，則在硬件較差的機(jī)器上會(huì)比較明顯。對(duì)于這個(gè)問(wèn)題锰霜，我們一年前曾經(jīng)嘗試過(guò)嵌入原生組件的方式來(lái)解決筹误，不過(guò)這個(gè)方案需要依賴(lài)應(yīng)用端的支持，或許以后瀏覽器會(huì)自帶幾個(gè)優(yōu)化后的 Web Components 組件癣缅，使用這些組件就能很好解決性能問(wèn)題厨剪。
現(xiàn)階段這三個(gè)問(wèn)題都不好解決哄酝，所以有人想干脆不用 HTML/CSS，自己來(lái)畫(huà)界面祷膳，比如 React canvas 直接畫(huà)在 Canvas 上陶衅，但在我看來(lái)這只是現(xiàn)階段解決部分問(wèn)題的方法，在后面的章節(jié)我會(huì)詳細(xì)介紹自己畫(huà) UI 的各種問(wèn)題直晨，這里說(shuō)個(gè)歷史吧搀军，6 年前瀏覽器還比較慢的時(shí)候，Bespin 就這么干過(guò)勇皇，后來(lái)這個(gè)項(xiàng)目被使用 DOM 的 ACE 取代了罩句，目前包括 TextMirror 和 Atom 在內(nèi)的主流編輯器都是直接使用 DOM，甚至 W3C 有人專(zhuān)門(mén)寫(xiě)了篇文章吐槽用 Canvas 做編輯器的種種缺點(diǎn)敛摘，所以使用 Canvas 要謹(jǐn)慎门烂。
另外除了 Canvas，還有人以為 WebGL 快兄淫，就嘗試?yán)L制到 WebGL 上屯远，比如 HTML-GL，但它目前的實(shí)現(xiàn)太偷懶了拖叙，簡(jiǎn)單來(lái)說(shuō)就是先用html2canvas 將 DOM 節(jié)點(diǎn)渲染成圖片氓润，然后將這個(gè)圖片作為貼圖放在 WebGL 中，這等于將瀏覽器中用 C++ 寫(xiě)的東東在 JavaScript 里實(shí)現(xiàn)了一遍薯鳍，渲染速度肯定反而更慢咖气，但倒是能用 GLSL 做特效來(lái)忽悠人。

硬件加速不等同于「快」挖滤，如果你以為硬件加速一定比軟件快崩溪，那你該抽空學(xué)學(xué)計(jì)算機(jī)體系結(jié)構(gòu)了

其實(shí)除了性能問(wèn)題，我認(rèn)為在 Web 流更嚴(yán)重的問(wèn)題是功能缺失斩松，比如 iOS 8 就新增 4000+ API伶唯，而 Web 標(biāo)準(zhǔn)需要漫長(zhǎng)的編寫(xiě)和評(píng)審過(guò)程，增加 4000 API 我這輩子是等不到了惧盹，即便是 Cordova 這樣自己封裝也忙不過(guò)來(lái)乳幸，所以為了更好地使用系統(tǒng)新功能，寫(xiě) Native 代碼是必須的钧椰。
P.S. 雖然前面提到 HTML/CSS 過(guò)于復(fù)雜導(dǎo)致性能問(wèn)題粹断，但其實(shí)這正是 Web 最大的優(yōu)勢(shì)所在，因?yàn)?Web 最初的目的就是顯示文檔嫡霞，如果你想顯示豐富的圖文排版瓶埋，雖然 iOS/Android 都有富文本組件，但比起 CSS 差太遠(yuǎn)了，所以在很多 Native 應(yīng)用中是不可避免要嵌 Web 的养筒。

代碼轉(zhuǎn)換流

前面提到寫(xiě) Native 代碼是必須的曾撤，但不同平臺(tái)下的官方語(yǔ)言不一樣，這會(huì)導(dǎo)致同樣的邏輯要寫(xiě)兩次以上晕粪，于是就有人想到了通過(guò)代碼轉(zhuǎn)換的方式來(lái)減少工作量挤悉，比如將 Java 轉(zhuǎn)成 Objective-C。
這種方式雖然聽(tīng)起來(lái)不是很靠譜兵多，但它卻是成本和風(fēng)險(xiǎn)都最小的尖啡，因?yàn)榇a轉(zhuǎn)換后就可以用官方提供的各種工具了，和普通開(kāi)發(fā)區(qū)別不大剩膘，因此不用擔(dān)心遇到各種詭異的問(wèn)題衅斩，不過(guò)需要注意生成的代碼是否可讀，不可讀的方案就別考慮了怠褐。
接下來(lái)看看目前存在的幾種代碼轉(zhuǎn)換方式畏梆。

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

j2objc 能將 Java 代碼轉(zhuǎn)成 Objective-C，據(jù)說(shuō) Google 內(nèi)部就是使用它來(lái)降低跨平臺(tái)開(kāi)發(fā)成本的奈懒，比如 Google Inbox 項(xiàng)目就號(hào)稱(chēng)通過(guò)它共用了 70% 的代碼奠涌，效果很顯著。
可能有人會(huì)覺(jué)得奇怪磷杏，為何 Google 要專(zhuān)門(mén)開(kāi)發(fā)一個(gè)幫助大家寫(xiě) Objective-C 的工具溜畅？還有媒體說(shuō) Google 做了件好事，其實(shí)吧极祸，我覺(jué)得 Google 這算盤(pán)打得不錯(cuò)慈格，因?yàn)榛旧现匾膽?yīng)用都會(huì)同時(shí)開(kāi)發(fā) Android 和 iOS 版本，有了這個(gè)工具就意味著遥金，你可以先開(kāi)發(fā) Android 版本浴捆，然后再開(kāi)發(fā) iOS 版本。稿械。选泻。
既然都有成功案例了，這個(gè)方案確實(shí)值得嘗試美莫，而且關(guān)鍵是會(huì) Java 的人多啊页眯，可以通過(guò)它來(lái)快速移植代碼到 Objective-C 中。

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

除了有 Java 轉(zhuǎn)成 Objective-C厢呵，還有 Objective-C 轉(zhuǎn)成 Java 的方案餐茵，那就是 MyAppConverter，比起前面的 j2objc述吸，這個(gè)工具更有野心，它還打算將 UI 部分也包含進(jìn)來(lái)，從它已轉(zhuǎn)換的列表中可以看到還有 UIKit蝌矛、CoreGraphics 等組件道批，使得有些應(yīng)用可以不改代碼就能轉(zhuǎn)成功，不過(guò)這點(diǎn)我并不看好入撒，對(duì)于大部分應(yīng)用來(lái)說(shuō)并不現(xiàn)實(shí)隆豹。
由于目前是收費(fèi)項(xiàng)目，我沒(méi)有嘗試過(guò)茅逮，對(duì)技術(shù)細(xì)節(jié)也不了解璃赡，所以這里不做評(píng)價(jià)。

將 Java 轉(zhuǎn)成 C#

Mono 提供了一個(gè)將 Java 代碼轉(zhuǎn)成 C# 的工具 Sharpen献雅，不過(guò)似乎用的人不多碉考，Star 才 118，所以看起來(lái)不靠譜挺身。
還有 JUniversal 這個(gè)工具可以將 Java 轉(zhuǎn)成 C#侯谁，但目前它并沒(méi)有發(fā)布公開(kāi)版本，所以具體情況還待了解章钾，它的一個(gè)特色是自帶了簡(jiǎn)單的跨平臺(tái)庫(kù)墙贱，里面包括文件處理、JSON贱傀、HTTP惨撇、OAuth 組件，可以基于它來(lái)開(kāi)發(fā)可復(fù)用的業(yè)務(wù)邏輯府寒。
比起轉(zhuǎn)成 Objective-C 和 Java 的工具魁衙，轉(zhuǎn)成 C# 的這兩個(gè)工具看起來(lái)都非常不成熟，估計(jì)是用 Windows Phone 的人少椰棘。

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

說(shuō)到源碼轉(zhuǎn)換就不得不提 Haxe 這個(gè)奇特的語(yǔ)言纺棺，它沒(méi)有自己的虛擬機(jī)或可執(zhí)行文件編譯器，所以只能通過(guò)轉(zhuǎn)成其它語(yǔ)言來(lái)運(yùn)行邪狞，目前支持轉(zhuǎn)成 Neko（字節(jié)碼）祷蝌、Javascript、Actionscript 3帆卓、PHP巨朦、C++、Java剑令、C# 和 Python糊啡，盡管有人實(shí)現(xiàn)了轉(zhuǎn)成 Swift 的支持，但還是非官方的吁津，所以要想支持 iOS 開(kāi)發(fā)目前只能通過(guò) Adobe AIR 來(lái)運(yùn)行棚蓄。
在游戲開(kāi)發(fā)方面做得不錯(cuò)堕扶，有個(gè)跨平臺(tái)的游戲引擎 OpenFL 的，最終可以使用 HTML5 Canvas梭依、OpenGL 或 Flash 來(lái)進(jìn)行繪制稍算，OpenFL 的開(kāi)發(fā)體驗(yàn)做得相當(dāng)不錯(cuò)，同一行代碼不需要修改就能編譯出不同平臺(tái)下的可執(zhí)行文件役拴，因?yàn)槭峭ㄟ^(guò)轉(zhuǎn)成 C++ 方式進(jìn)行編譯的糊探，所以在性能和反編譯方面都有優(yōu)勢(shì)，可惜目前似乎并不夠穩(wěn)定河闰，不然可以成為 Cocos2d-x 的有利競(jìng)品科平。
在 OpenFL 基礎(chǔ)上還有個(gè)跨平臺(tái)的 UI 組件 HaxeUI，但界面風(fēng)格我覺(jué)得特別丑姜性，也就只能在游戲中用了瞪慧。
所以目前來(lái)看 Haxe 做跨平臺(tái)游戲開(kāi)發(fā)或許可行，但 APP 開(kāi)發(fā)就別指望了污抬，而基于它來(lái)共用代碼實(shí)在就更不靠譜了汞贸，因?yàn)槭煜に拈_(kāi)發(fā)者極少，反而增加成本印机。

XMLVM

除了前面提到的源碼到源碼的轉(zhuǎn)換矢腻，還有 XMLVM 這種與眾不同的方式，它首先將字節(jié)碼轉(zhuǎn)成一種基于 XML 的中間格式射赛，然后再通過(guò) XSL 來(lái)生成不同語(yǔ)言多柑，目前支持生成 C、Objective-C楣责、JavaScript竣灌、C#、Python 和 Java秆麸。
雖然基于一個(gè)中間字節(jié)碼可以方便支持多語(yǔ)言初嘹，然而它也導(dǎo)致生成代碼不可讀，因?yàn)楹芏嗾Z(yǔ)言中的語(yǔ)法糖會(huì)在字節(jié)碼中被抹掉沮趣，這是不可逆的屯烦，以下是一個(gè)簡(jiǎn)單示例生成的 Objective-C 代碼，看起來(lái)就像匯編：
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)...

在我看來(lái)這個(gè)方案相當(dāng)不靠譜房铭，萬(wàn)一生成的代碼有問(wèn)題基本沒(méi)法修改驻龟，也沒(méi)法調(diào)試代碼，所以不推薦缸匪。

小結(jié)

雖然代碼轉(zhuǎn)換這種方式風(fēng)險(xiǎn)小翁狐，但我覺(jué)得對(duì)于很多小 APP 來(lái)說(shuō)共享不了多少代碼，因?yàn)檫@類(lèi)應(yīng)用大多數(shù)圍繞 UI 來(lái)開(kāi)發(fā)的凌蔬，大部分代碼都和 UI 耦合露懒，所以公共部分不多闯冷。
在目前的所有具體方案中，只有 j2objc 可以嘗試隐锭，其它都不成熟窃躲。

編譯流

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

優(yōu)點(diǎn)可以重用一些實(shí)現(xiàn)很復(fù)雜的代碼，比如之前用 C++ 實(shí)現(xiàn)的游戲引擎躁倒，重寫(xiě)一遍成本太高
編譯后的代碼反編譯困難
或許性能會(huì)好些（具體要看實(shí)現(xiàn)）

缺點(diǎn)如果這個(gè)工具本身有 Bug 或性能問(wèn)題荞怒，定位和修改成本會(huì)很高
編譯后體積不小，尤其是如果要支持 ARMv8 和 x86 的話

接下來(lái)我們通過(guò)區(qū)分不同語(yǔ)言來(lái)介紹這個(gè)流派下的各種方案秧秉。

C++ 類(lèi)

C++ 是最常見(jiàn)的選擇褐桌，因?yàn)槟壳?Android、iOS 和 Windows Phone 都提供了 C++ 開(kāi)發(fā)的支持象迎，它通常有三種做法：
只用 C++ 實(shí)現(xiàn)非界面部分荧嵌，這是官方比較推崇的方案，目前有很多應(yīng)用是這么做的砾淌，比如 Mailbox 和 Microsoft Office啦撮。
使用 2D 圖形庫(kù)來(lái)自己繪制界面，這種做法在桌面比較常見(jiàn)汪厨，因?yàn)楹芏嘟缑娑加袀€(gè)性化需求赃春，但在移動(dòng)端用得還不多。
使用 OpenGL 來(lái)繪制界面劫乱，常見(jiàn)于游戲中织中。

使用 C++ 實(shí)現(xiàn)非界面部分比較常見(jiàn)，所以這里就不重復(fù)介紹了衷戈，除了能提升性能和共用代碼狭吼，還有人使用這種方式來(lái)隱藏一些關(guān)鍵代碼（比如密鑰），如果你不知道如何構(gòu)建這樣的跨平臺(tái)項(xiàng)目殖妇，可以參考 Dropbox 開(kāi)源的 libmx3 項(xiàng)目刁笙，它還內(nèi)嵌了 json 和 sqlite 庫(kù)，并通過(guò)調(diào)用系統(tǒng)庫(kù)來(lái)實(shí)現(xiàn)對(duì)簡(jiǎn)單 HTTP拉一、EventLoop 及創(chuàng)建線程的支持采盒。
而如果要用 C++ 實(shí)現(xiàn)界面部分，在 iOS 和 Windows Phone 下可以分別使用 C++ 的超集 Objective-C++ 和 C++/CX蔚润，所以還比較容易磅氨，但在 Android 下問(wèn)題就比較麻煩了，主要原因是 Android 的界面絕大部分是 Java 實(shí)現(xiàn)的嫡纠，所以用 C++ 開(kāi)發(fā)界面最大的挑戰(zhàn)是如何支持 Android烦租，這有兩種做法：通過(guò) JNI 調(diào)用系統(tǒng)提供的 Java 方法或者自己畫(huà) UI延赌。
第一種做法雖然可行，但代碼太冗余了比如一個(gè)簡(jiǎn)單的函數(shù)調(diào)用需要寫(xiě)那么多代碼：
JNIEnv* env;jclass testClass = (env)->FindClass(env, "com/your/package/name/Test"); // get ClassjmethodID 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);

那自己畫(huà) UI 是否會(huì)更方便點(diǎn)叉橱？比如 JUCE 和 QT 就是自己畫(huà)的挫以，我們來(lái)看看 QT 的效果：

qt-example

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ù)雜歼争，如果你覺(jué)得簡(jiǎn)單，那只能說(shuō)明你沒(méi)看過(guò)這個(gè)世界有多大渗勘，或許你知道中文有編碼問(wèn)題沐绒、英語(yǔ)有連字符(hyphen)折行，但你是否知道繁體中文有豎排版旺坠、阿拉伯文是從右到左的乔遮、日語(yǔ)有平假名注音(ルビ)、印度語(yǔ)有元音附標(biāo)文字(abugida ????)……取刃？
而相比之下如果每個(gè)平臺(tái)單獨(dú)開(kāi)發(fā)界面蹋肮，看似工作量不小出刷，但目前在各個(gè)平臺(tái)下都會(huì)有良好的官方支持，相關(guān)工具和文檔都很完善坯辩，所以其實(shí)成本沒(méi)那么高馁龟，而且可以給用戶和系統(tǒng)風(fēng)格保持一致的良好體驗(yàn)，所以我認(rèn)為對(duì)于大多數(shù)應(yīng)用來(lái)說(shuō)自己畫(huà) UI 是很不劃算的漆魔。
不過(guò)也有特例坷檩，對(duì)于 UI 比較獨(dú)特的應(yīng)用來(lái)說(shuō)，自己畫(huà)也是有好處的有送，除了更靈活的控制淌喻，它還能使得不同平臺(tái)下風(fēng)格統(tǒng)一，這在桌面應(yīng)用中很常見(jiàn)雀摘，比如 Windows 下你會(huì)發(fā)現(xiàn)幾乎每個(gè)必備軟件的 UI 都不太一樣，而且好多都有換膚功能八拱，在這種情況下很適合自己畫(huà) UI阵赠。

Xamarin

Xamarin 可以使用 C# 來(lái)開(kāi)發(fā) Android 及 iOS 應(yīng)用，它是從 Mono 發(fā)展而來(lái)的肌稻，目前看起來(lái)商業(yè)運(yùn)作得不錯(cuò)清蚀，相關(guān)工具及文檔都挺健全。
因?yàn)樗?iOS 下是以 AOT 的方式編譯為二進(jìn)制文件的爹谭，所以把它歸到編譯流來(lái)討論枷邪，其實(shí)它在 Android 是內(nèi)嵌了 Mono 虛擬機(jī) 來(lái)實(shí)現(xiàn)的，因此需要裝一個(gè) 17M 的運(yùn)行環(huán)境诺凡。
在 UI 方面东揣，它可以通過(guò)調(diào)用系統(tǒng) API 來(lái)使用系統(tǒng)內(nèi)置的界面組件，或者基于 Xamarin.Forms 開(kāi)發(fā)定制要求不高的跨平臺(tái) UI腹泌。
對(duì)于熟悉 C# 的團(tuán)隊(duì)來(lái)說(shuō)嘶卧，這還真是一個(gè)看起來(lái)很不錯(cuò)的，但這種方案最大的問(wèn)題就是相關(guān)資料不足凉袱，遇到問(wèn)題很可能搜不到解決方案芥吟，不過(guò)由于時(shí)間關(guān)系我并沒(méi)有仔細(xì)研究，推薦看看這篇文章专甩，其中談到它的優(yōu)缺點(diǎn)是：
優(yōu)點(diǎn)開(kāi)發(fā) app 所需的基本功能全部都有
有商業(yè)支持钟鸵，而且這個(gè)項(xiàng)目對(duì) Windows Phone 很有利，微軟會(huì)大力支持

缺點(diǎn)如果深入后會(huì)發(fā)現(xiàn)功能缺失涤躲，尤其是定制 UI棺耍，因?yàn)槲撮_(kāi)源使得遇到問(wèn)題時(shí)不知道如何修復(fù)
Xamarin 本身有些 Bug
相關(guān)資源太少，沒(méi)有原生平臺(tái)那么多第三方庫(kù)
Xamarin studio 比起 Xcode 和 Android Studio 在功能上還有很大差距

Objective-C 編譯為 Windows Phone

微軟知道自己的 Windows Phone 太非主流篓叶，所以很懂事地推出了將 Objective-C 項(xiàng)目編譯到 Windows Phone 上運(yùn)行的工具烈掠，目前這個(gè)工具的相關(guān)資料很少羞秤，鑒于 Visual Studio 支持 Clang，所以極有可能是使用 Clang 的前端來(lái)編譯左敌，這樣最大的好處是以后支持 Swift 會(huì)很方便瘾蛋，因此我歸到編譯流。
而對(duì)于 Android 的支持矫限，微軟應(yīng)該使用了虛擬機(jī)的方式哺哼，所以放到下個(gè)章節(jié)介紹。

RoboVM

RoboVM 可以將 Java 字節(jié)碼編譯為可在 iOS 下運(yùn)行的機(jī)器碼叼风，這有點(diǎn)類(lèi)似 GCJ取董，但它的具體實(shí)現(xiàn)是先使用 Soot 將字節(jié)碼編譯為 LLVM IR，然后通過(guò) LLVM 的編譯器編譯成不同平臺(tái)下的二進(jìn)制文件无宿。
比如簡(jiǎn)單的 new UITextField(new CGRect(44, 32, 232, 31))
最后會(huì)變?nèi)缦碌臋C(jī)器碼(x86)：
call imp___jump_table__[j]org.robovm.apple.uikit.UITextField[allocator][clinit]mov esi, eaxmov dword [ss:esp], ebxcall imp___jump_table__[j]org.robovm.apple.coregraphics.CGRect[allocator][clinit]mov edi, eaxmov dword [ss:esp+0x4], edimov dword [ss:esp], ebxmov dword [ss:esp+0xc], 0x40460000...

基于字節(jié)碼編譯的好處是可以支持各種在 JVM 上構(gòu)建的語(yǔ)言茵汰，比如 Scala、Kotlin孽鸡、Clojure 等蹂午。
在運(yùn)行環(huán)境上，它使用的 GC 和 GCJ 一樣彬碱，都是 Boehm GC豆胸，這是一個(gè)保守 GC，會(huì)有內(nèi)存泄露問(wèn)題巷疼，盡管官方說(shuō)已經(jīng)優(yōu)化過(guò)了影響不大晚胡。
在 UI 的支持方面，它和 Xamarin 挺像嚼沿，可以直接用 Java 調(diào)用系統(tǒng)接口來(lái)創(chuàng)建界面（最近支持 Interface Builder 了）估盘，比如上面的示例就是。另外還號(hào)稱(chēng)能使用 JavaFX伏尼，這樣就能在 iOS 和 Android 上使用同一套 UI 了忿檩，不過(guò)目前看起來(lái)很不靠譜。
在我看來(lái) RoboVM 目前最大的用途就是使用 libGDX 開(kāi)發(fā)游戲了爆阶，盡管在功能上遠(yuǎn)不如 Cocos2d-x（尤其是場(chǎng)景及對(duì)象管理）燥透，但不管怎么說(shuō)用 Java 比 C++ 還是方便很多（別跟我說(shuō)沒(méi)人用 Java 做游戲，價(jià)值 25 億美元的 Minecraft 就是）辨图，不過(guò)本文主要關(guān)心的是 UI 開(kāi)發(fā)班套，所以這方面的話題就不深入討論了，
RoboVM 和 Xamarin 很像故河，但 RoboVM 風(fēng)險(xiǎn)會(huì)小些吱韭，因?yàn)樗恍枰?iOS 支持好就行了，對(duì)優(yōu)先開(kāi)發(fā) Android 版本的團(tuán)隊(duì)挺適用，但目前官方文檔太少了理盆，而且不清楚 RoboVM 在 iOS 上的性能和穩(wěn)定性怎樣痘煤。

Swift - Apportable/Silver

apportable 可以直接將 Swift/Objective-C 編譯為機(jī)器碼，但它官網(wǎng)的成功案例全部都是游戲猿规，所以用這個(gè)來(lái)做 APP 感覺(jué)很不靠譜衷快。
所以后來(lái)它又推出了 Tengu 這個(gè)專(zhuān)門(mén)針對(duì) APP 開(kāi)發(fā)的工具，它的比起之前的方案更靈活些姨俩，本質(zhì)上有點(diǎn)類(lèi)似 C++ 公共庫(kù)的方案蘸拔，只不過(guò)語(yǔ)言變成了 Swift/Objective-C，使用 Swift/Objective-C 來(lái)編譯生成跨平臺(tái)的 SO 文件环葵，提供給 Android 調(diào)用调窍。
另一個(gè)類(lèi)似的是 Silver，不過(guò)目前沒(méi)正式發(fā)布张遭，它不僅支持 Swift邓萨，還支持 C# 和自創(chuàng)的 Oxygene 語(yǔ)言（看起來(lái)像 Pascal），在界面方面它還有個(gè)跨平臺(tái)非 UI 庫(kù) Sugar菊卷，然而目前 Star 數(shù)只有 17先誉，太非主流了，所以實(shí)在懶得研究它的烁。
使用 Swift 編譯為 SO 給 Android 用雖然可行，但目前相關(guān)工具都不太成熟诈闺，所以不推薦使用渴庆。

Go

Go 是最近幾年很火的后端服務(wù)開(kāi)發(fā)語(yǔ)言，它語(yǔ)法簡(jiǎn)單且高性能雅镊，目前在國(guó)內(nèi)有不少用戶襟雷。
Go 從 1.4 版本開(kāi)始支持開(kāi)發(fā) Android 應(yīng)用（并將在 1.5 版本支持 iOS），不過(guò)前只能調(diào)用很少 的 API仁烹，比如 OpenGL 等耸弄，所以只能用來(lái)開(kāi)發(fā)游戲，但我感覺(jué)并不靠譜卓缰，現(xiàn)在還有誰(shuí)直接基于 OpenGL 開(kāi)發(fā)游戲计呈？大部分游戲都是基于某個(gè)框架的，而 Go 在這方面太缺乏了征唬，我只看到一個(gè)桌面端 Azul3D捌显，而且非常不成熟。
因?yàn)?Android 的 View 層完全是基于 Java 寫(xiě)的总寒，要想用 Go 來(lái)寫(xiě) UI 不可避免要調(diào)用 Java 代碼扶歪，而這方面 Go 還沒(méi)有簡(jiǎn)便的方式，目前 Go 調(diào)用外部代碼只能使用 cgo摄闸，通過(guò) cgo 再調(diào)用 jni善镰，這需要寫(xiě)很多中間代碼妹萨，所以目前 Go 1.4 采用的是類(lèi)似 RPC 通訊的方式來(lái)做，從它源碼中例子可以看出這種方式有多麻煩炫欺，性能肯定有不小的損失乎完。
而且 cgo 的實(shí)現(xiàn)本身就對(duì)性能有損失，除了各種無(wú)關(guān)函數(shù)的調(diào)用竣稽，它還會(huì)鎖定一個(gè) Go 的系統(tǒng)線程囱怕，這會(huì)影響其它 gorountine 的運(yùn)行，如果同時(shí)運(yùn)行太多外部調(diào)用毫别，甚至?xí)?dǎo)致所有 gorountine 等待娃弓。
這個(gè)問(wèn)題的根源在于 Go 的棧是可以自動(dòng)擴(kuò)充的，這種方式有利于創(chuàng)建無(wú)數(shù) gorountine岛宦，但卻也導(dǎo)致了無(wú)法直接調(diào)用 C 編譯后的函數(shù)台丛，需要進(jìn)行棧切換。
所以使用 Go 開(kāi)發(fā)跨平臺(tái)移動(dòng)端應(yīng)用目前不靠譜砾肺。
話說(shuō) Rust 沒(méi)有 Go 的性能挽霉，它調(diào)用 C 函數(shù)是沒(méi)有性能損耗的，但目前 Rust 還沒(méi)提供對(duì) iOS/Android 的官方支持变汪，盡管有人還是嘗試過(guò)是可行的侠坎，但現(xiàn)在還不穩(wěn)定，從 Rust 語(yǔ)言本身的設(shè)計(jì)來(lái)看裙盾，它挺適合取代 C++ 來(lái)做這種跨平臺(tái)公共代碼实胸，但它的缺點(diǎn)是語(yǔ)法復(fù)雜，會(huì)嚇跑很多開(kāi)發(fā)者番官。
#######Xojo
我之前一直以為 BASIC 掛了庐完，沒(méi)想到還有這么一個(gè)特例，Xojo 使用的就是 BASIC徘熔，它有看起來(lái)很強(qiáng)大的 IDE门躯，讓人感覺(jué)像是在用 VisualBasic。
它的定位應(yīng)該是給小朋友或業(yè)余開(kāi)發(fā)者用的酷师，因?yàn)樗坪蹩雌饋?lái)學(xué)習(xí)成本低讶凉，但我不這么認(rèn)為，因?yàn)橛玫萌松僦仙炊W(wǎng)上資料會(huì)很少缀遍，所以恐怕成本會(huì)更高。
因?yàn)闀r(shí)間關(guān)系饱须，以及對(duì) BASIC 無(wú)愛(ài)域醇，我并沒(méi)有怎么研究它。

小結(jié)

從目前分析的情況看，C++ 是比較穩(wěn)妥的選擇譬挚，但它對(duì)團(tuán)隊(duì)成員有要求锅铅，如果大家都沒(méi)寫(xiě)過(guò) C++，可以試試 Xamrin 或 RoboVM减宣。

虛擬機(jī)流

除了編譯為不同平臺(tái)下的二進(jìn)制文件盐须，還有另一種常見(jiàn)做法是通過(guò)虛擬機(jī)來(lái)支持跨平臺(tái)運(yùn)行，比如 JavaScript 和 Lua 都是天生的內(nèi)嵌語(yǔ)言漆腌，所以在這個(gè)流派中很多方案都使用了這兩個(gè)語(yǔ)言贼邓。
不過(guò)虛擬機(jī)流會(huì)遇到兩個(gè)問(wèn)題：一個(gè)是性能損耗，另一個(gè)是虛擬機(jī)本身也會(huì)占不小的體積闷尿。

Java 系

說(shuō)到跨平臺(tái)虛擬機(jī)大家都會(huì)想到 Java塑径，因?yàn)檫@個(gè)語(yǔ)言一開(kāi)始就是為了跨平臺(tái)設(shè)計(jì)的，Sun 的 J2ME 早在 1998 年就有了填具，在 iPhone 出來(lái)前的手機(jī)上统舀，很多小游戲都是基于 J2ME 開(kāi)發(fā)的，這個(gè)項(xiàng)目至今還活著劳景，能運(yùn)行在 Raspberry Pi 上誉简。
前面提到微軟提供了將 Objective-C 編譯在 Windows Phone 上運(yùn)行的工具，在對(duì) Android 的支持上我沒(méi)找到的詳細(xì)資料盟广，所以就暫時(shí)認(rèn)為它是虛擬機(jī)的方式闷串，從 Astoria 項(xiàng)目的介紹上看它做得非常完善，不僅能支持 NDK 中的 C++筋量，還實(shí)現(xiàn)了 Java 的 debug 接口窿克，使得可以直接用 Android Studio 等 IDE 來(lái)調(diào)試，整個(gè)開(kāi)發(fā)體驗(yàn)和在 Android 手機(jī)上幾乎沒(méi)區(qū)別毛甲。
另外 BlackBerry 10 也是通過(guò)內(nèi)嵌虛擬機(jī)來(lái)支持直接運(yùn)行 Android 應(yīng)用，不過(guò)據(jù)說(shuō)比較卡具被。
不過(guò)前面提到 C# 和 Java 在 iOS 端的方案都是通過(guò) AOT 的方式實(shí)現(xiàn)的玻募，目前還沒(méi)見(jiàn)到有 Java 虛擬機(jī)的方案，我想主要原因是 iOS 的限制一姿，普通 app 不能調(diào)用 mmap七咧、mprotect，所以無(wú)法使用 JIT 來(lái)優(yōu)化性能叮叹，如果 iOS 開(kāi)放艾栋，或許哪天有人開(kāi)發(fā)一個(gè)像微軟那樣能直接在 iOS 上運(yùn)行 Android 應(yīng)用的虛擬機(jī)，就不需要跨平臺(tái)開(kāi)發(fā)了蛉顽，大家只需要學(xué) Android 開(kāi)發(fā)就夠了蝗砾。。。

Titanium/Hyperloop

Titanium 應(yīng)該不少人聽(tīng)過(guò)悼粮，它和 PhoneGap 幾乎是同時(shí)期的著名跨平臺(tái)方案闲勺，和 PhoneGap 最大的區(qū)別是：它的界面沒(méi)有使用 HTML/CSS，而是自己設(shè)計(jì)了一套基于 XML 的 UI 框架 Alloy扣猫，代碼類(lèi)似下面這個(gè)樣子：
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></Alloy>

前面我們說(shuō)過(guò)由于 CSS 的過(guò)于靈活拖累了瀏覽器的性能菜循，那是否自己建立一套 UI 機(jī)制會(huì)更靠譜呢？盡管這么做對(duì)性能確實(shí)有好處申尤，然而它又帶來(lái)了學(xué)習(xí)成本問(wèn)題癌幕，做簡(jiǎn)單的界面問(wèn)題不大，一旦要深入定制開(kāi)發(fā)就會(huì)發(fā)現(xiàn)相關(guān)資料太少昧穿，所以還是不靠譜勺远。
Titanium 還提供了一套跨平臺(tái)的 API 來(lái)方便調(diào)用，這么做是它的優(yōu)點(diǎn)更是缺點(diǎn)粤咪，尤其是下面三個(gè)問(wèn)題：
API 有限谚中，因?yàn)檫@是由 Titanium 提供的，它肯定會(huì)比官方 API 少且有延遲寥枝，Titanium 是肯定跟不過(guò)來(lái)的
相關(guān)資料及社區(qū)有限宪塔，比起 Android/iOS 差遠(yuǎn)了，遇到問(wèn)題都不知道去哪找答案
缺乏第三方庫(kù)囊拜，第三方庫(kù)肯定不會(huì)專(zhuān)門(mén)為 Titanium 提供一個(gè)版本某筐，所以不管用什么都得自己封裝

Titanium 也意識(shí)到了這個(gè)問(wèn)題，所以目前在開(kāi)發(fā)下一代的解決方案 Hyperloop冠跷，它可以將 JavaScript 編譯為原生代碼南誊，這樣的好處是調(diào)用原生 API 會(huì)比較方便，比如它的 iOS 是這樣寫(xiě)的
@import("UIKit");@import("CoreGraphics");var view = new UIView();view.frame = CGRectMake(0, 0, 100, 100);

這個(gè)方案和之前的說(shuō)的 Xamarin 很相似蜜托，基本上等于將 Objective-C 翻譯為 JavaScript 后的樣子抄囚，意味著你可以對(duì)著 Apple 的官方文檔開(kāi)發(fā)，不過(guò)如果發(fā)現(xiàn)某些 Objective-C 語(yǔ)法發(fā)現(xiàn)不知道對(duì)應(yīng)的 JavaScript 怎么寫(xiě)時(shí)就悲劇了橄务，只有自己摸索幔托。
但從 Github 上的提交歷史看，這項(xiàng)目都快開(kāi)發(fā)兩年了蜂挪，但至今仍然是試驗(yàn)階段重挑，從更新頻率來(lái)看，最近一年只提交了 8 次棠涮，所以恐怕是要棄坑了谬哀，非常不靠譜。
因此我認(rèn)為 Titanium/Hyperloop 都非常不靠譜严肪，不推薦使用史煎。
NativeScript
之前說(shuō)到 Titanium 自定義 API 帶來(lái)的各種問(wèn)題谦屑，于是就有人換了個(gè)思路，比如前段時(shí)間推出的 NativeScript劲室，它的方法說(shuō)白了就是用工具來(lái)自動(dòng)生成 wrapper API伦仍，和系統(tǒng) API 保持一致。
有了這個(gè)自動(dòng)生成 wrapper 的工具很洋，它就能方便基于系統(tǒng) API 來(lái)開(kāi)發(fā)跨平臺(tái)組件充蓝，以簡(jiǎn)單的 Button
為例，源碼在 cross-platform-modules/ui/button 中喉磁，它在 Android 下是這樣實(shí)現(xiàn)的（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 下是這樣實(shí)現(xiàn)的（省略了很多代碼）
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 中的調(diào)用方式是一樣的谓苟，只不過(guò)語(yǔ)言換成了 JavaScript，并且寫(xiě)法看起來(lái)比較詭異罷了协怒，風(fēng)格類(lèi)似前面的 Hyperloop 類(lèi)似涝焙，所以也同樣會(huì)有語(yǔ)法轉(zhuǎn)換的問(wèn)題。
這么做最大的好處就是能完整支持所有系統(tǒng) API孕暇，對(duì)于第三方庫(kù)也能很好支持仑撞，但它目前最大缺點(diǎn)是生成的文件體積過(guò)大，即便什么都不做妖滔，生成的 apk 文件也有 8.4 MB隧哮，因?yàn)樗鼘⑺?API binding 都生成了，而且這也導(dǎo)致在 Android 下首次打開(kāi)速度很慢座舍。
從底層實(shí)現(xiàn)上看沮翔，NativeScript 在 Android 下內(nèi)嵌了 V8，而在 iOS 下內(nèi)嵌了自己編譯的 JavaScriptCore（這意味著沒(méi)有 JIT 優(yōu)化曲秉，具體原因前面提到了）采蚀，這樣的好處是能調(diào)用更底層的 API，也避免了不同操作系統(tǒng)版本下 JS 引擎不一致帶來(lái)的問(wèn)題承二，但后果是生成文件的體積變大和在 iOS 下性能不如 WKWebView榆鼠。
WKWebView 是基于多進(jìn)程實(shí)現(xiàn)的，它在 iOS 的白名單中亥鸠，所以能支持 JIT璧眠。

它的使用體驗(yàn)很不錯(cuò)，做到了一鍵編譯運(yùn)行读虏，而且還有 MVVM 的支持，能進(jìn)行數(shù)據(jù)雙向綁定袁滥。
在我看來(lái) NativeScript 和 Titanium 都有個(gè)很大的缺點(diǎn)盖桥，那就是排它性太強(qiáng)，如果你要用這兩個(gè)方案题翻，就得完整基于它們進(jìn)行開(kāi)發(fā)揩徊，不能在某些 View 下進(jìn)行嘗試腰鬼，也不支持直接嵌入第三方 View，有沒(méi)有方案能很好地解決這兩個(gè)問(wèn)題塑荒？有熄赡，那就是我們接下來(lái)要介紹的 React Native。

React Native

關(guān)于 React Native 目前網(wǎng)上有很多討論了齿税，知乎上也有不少回答彼硫，盡管有些回答從底層實(shí)現(xiàn)角度看并不準(zhǔn)確，但大部分關(guān)鍵點(diǎn)倒是都提到了凌箕。
鑒于我不喜歡重復(fù)別人說(shuō)過(guò)的話拧篮，這里就聊點(diǎn)別的。
React Native 的思路簡(jiǎn)單來(lái)說(shuō)就是在不同平臺(tái)下使用平臺(tái)自帶的 UI 組件牵舱，這個(gè)思路并不新奇串绩，十幾年前的 SWT 就是這么做的。
從團(tuán)隊(duì)上看芜壁，F(xiàn)acebook 的 iOS 團(tuán)隊(duì)中不少成員是來(lái)自 Apple 的礁凡，比如 Paper 團(tuán)隊(duì)的經(jīng)理及其中不少成員都是，因?yàn)?iOS 不開(kāi)源慧妄，所以從 Apple 中出來(lái)的開(kāi)發(fā)者還是有優(yōu)勢(shì)的顷牌，比如前 Apple 開(kāi)發(fā)者搞出來(lái)的 Duet 就秒殺了市面上所有其他方案，而且從 Facebook 在 iOS 上開(kāi)源的項(xiàng)目看他們?cè)?iOS 方面的經(jīng)驗(yàn)和技術(shù)都不錯(cuò)腰涧，所以從團(tuán)隊(duì)角度看他們做出來(lái)的東西不會(huì)太差韧掩。
在做 React Native 方案的同時(shí)，其實(shí) Facebook 還在做一個(gè) Objective-C++ 上類(lèi)似 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++ 的方案恐怕沒(méi)幾年就過(guò)時(shí)了费彼，所以 Facebook 押寶 React 是比較正確的滑臊。
我看到有人說(shuō)這是 Facebook 回歸 H5，但其實(shí) React Native 和 Web 扯不上太多關(guān)系箍铲，我所理解的 Web 是指 W3C 定義的那些規(guī)范雇卷，比如 HTML、CSS颠猴、DOM关划，而 React Native 主要是借鑒了 CSS 中的 Flexbox 寫(xiě)法，還有 navigator翘瓮、XMLHttpRequest 等幾個(gè)簡(jiǎn)單的 API贮折，更別說(shuō)完全沒(méi)有 Web 的開(kāi)放性，所以 React Native 和 HTML 5 完全不是一回事资盅。
Facebook Groups 的 iOS 版本很大一部分基于 React Native 開(kāi)發(fā)调榄，其中用到了不少內(nèi)部通過(guò)組件踊赠，比如 ReactGraphQL，這里我就八卦一下它每庆，GraphQL 這是一個(gè)結(jié)構(gòu)化數(shù)據(jù)查詢(xún)的語(yǔ)法筐带，就像 MongoDB 查詢(xún)語(yǔ)法那樣查詢(xún) JSON 數(shù)據(jù)，不過(guò)它并不是一種文檔型數(shù)據(jù)庫(kù)缤灵，而只是一個(gè)中間層伦籍，具體的數(shù)據(jù)源可以連其它數(shù)據(jù)庫(kù)，它想取代的應(yīng)該是 RESTful 那樣的前后端簡(jiǎn)單 HTTP 協(xié)議凤价，讓前端更方便的獲取數(shù)據(jù)鸽斟，據(jù)說(shuō)將會(huì)開(kāi)源（看起來(lái)打算用 Node 實(shí)現(xiàn)）。
寫(xiě)文章拖時(shí)間太長(zhǎng)的問(wèn)題就是這期間會(huì)發(fā)生很多事情利诺，比如 GraphQL 在我開(kāi)始寫(xiě)的時(shí)候外界都不知道富蓄，所以需要八卦一下，結(jié)果現(xiàn)在官方已經(jīng)宣布了慢逾，不過(guò)官方并沒(méi)提到我說(shuō)的那個(gè) Node 實(shí)現(xiàn)立倍，它目前還在悄悄開(kāi)發(fā)階段

React Native 的官方視頻中說(shuō)它能做到 App 內(nèi)實(shí)時(shí)更新，其實(shí)這是 Apple 明文禁止的（App Store Review Guidelines 中的 2.7）侣滩，要做得低調(diào)口注。
評(píng)論中有人提到 Apple 居然在 iOS 8.2 中改條款了，可以下載執(zhí)行 JavaScript君珠，而且 UIKit 的作者都覺(jué)得 React Native 很贊

我比較喜歡的是 React Native 中用到了 Flow寝志，它支持定義函數(shù)參數(shù)的類(lèi)型，極大提升了代碼可讀性策添，另外還能使用 ES6 的語(yǔ)法材部，比如 class 關(guān)鍵字等。
React Native 比傳統(tǒng) Objective-C 和 UIView 的學(xué)習(xí)成本低多了唯竹，熟悉 JavaScript 的開(kāi)發(fā)者應(yīng)該半天內(nèi)就能寫(xiě)個(gè)使用標(biāo)準(zhǔn) UI 的界面乐导，而且用 XML+CSS 畫(huà)界面也遠(yuǎn)比 UIView 中用 Frame 進(jìn)行手工布局更易讀（我沒(méi)用過(guò) Storyboards，它雖然看起來(lái)直觀浸颓，但多人編輯很容易沖突）物臂，感興趣可以抽空看看這個(gè)詳細(xì)的入門(mén)教程，親自動(dòng)手試試就能體會(huì)到了产上，Command + R 更新代碼感覺(jué)很神奇棵磷。
它目前已經(jīng)有組件倉(cāng)庫(kù)了，而且在 github 上都有 500 多倉(cāng)庫(kù)了晋涣，其中有 sqlite仪媒、Camera 等原生組件，隨著這些第三方組件的完善姻僧，基于 React Native 開(kāi)發(fā)越來(lái)越不需要寫(xiě)原生代碼了规丽。
不過(guò)壞消息是 React Native 的 Android 版本還要等半年，這可以理解撇贺，因?yàn)樵?Android 上問(wèn)題要復(fù)雜得多赌莺，有 Dalvik/ART 攔在中間，使得交互起來(lái)很麻煩松嘶。
NativeScript 和 React Native 在側(cè)重點(diǎn)上有很大的不同艘狭，使得這兩個(gè)產(chǎn)品目前走向了不同的方向：
React Native 要解決的是開(kāi)發(fā)效率問(wèn)題，它并沒(méi)指望完全取代 Native 開(kāi)發(fā)翠订，它的 rootView 繼承自 UIView巢音，所以可以在部分 View 是使用，很方便混著尽超，不需要重寫(xiě)整個(gè) app官撼，而且混用的時(shí)候還需要顯示地將 API 暴露給 JavaScript
NativeScript 則像是 Titanium 那樣企圖完全使用 JavaScript 開(kāi)發(fā)，將所有系統(tǒng) API 都暴露給了 JavaScript似谁，讓 JavaScript 語(yǔ)言默認(rèn)就擁有 Native 語(yǔ)言的各種能力傲绣，然后再次基礎(chǔ)上來(lái)開(kāi)發(fā)

方向的不同導(dǎo)致這兩個(gè)產(chǎn)品將會(huì)有不同的結(jié)局，我認(rèn)為 React Native 肯定會(huì)完勝 NativeScript巩踏，因?yàn)樗氖褂蔑L(fēng)險(xiǎn)要小很多秃诵，你可以隨時(shí)將部分 View 使用 React Native 來(lái)試驗(yàn)，遇到問(wèn)題就改回 Native 實(shí)現(xiàn)塞琼，風(fēng)險(xiǎn)可控菠净，而用 NativeScript 就不行了，這導(dǎo)致大家在技術(shù)選型的時(shí)候不敢使用 NativeScript彪杉。
話說(shuō) Angular 團(tuán)隊(duì)看到 React Native 后表示不淡定了毅往，于是開(kāi)始重新設(shè)計(jì) Angular 2 的展現(xiàn)架構(gòu)，將現(xiàn)有的 Render 層獨(dú)立出來(lái)在讶，以便于做到像 React 那樣適應(yīng)不同的運(yùn)行環(huán)境煞抬，可以運(yùn)行在 NativeScript 上。
綜合來(lái)看构哺，我覺(jué)得 React Native 很值得嘗試革答，而且風(fēng)險(xiǎn)也不高。
游戲引擎中的腳本
游戲引擎大多都能跨平臺(tái)曙强，為了提升開(kāi)發(fā)效率残拐，不少引擎還內(nèi)嵌了對(duì)腳本支持，比如：
Ejecta碟嘴，它實(shí)現(xiàn)了 Canvas 及 Audio 的 API溪食，可以開(kāi)發(fā)簡(jiǎn)單的游戲，但目前還不支持 Android
CocoonJS娜扇，實(shí)現(xiàn)了 WebGL 的 API错沃，可以運(yùn)行 Three.js 寫(xiě)的游戲
Unreal Engine 3栅组，可以使用 UnrealScript 來(lái)開(kāi)發(fā)，這個(gè)語(yǔ)言的語(yǔ)法很像 Java
Cocos2d-js枢析，Cocos2d-x 的 JavaScript binding玉掸，它內(nèi)部使用的 JS 引擎是 SpiderMonkey
Unity 3D，可以使用 C# 或 JavaScript 開(kāi)發(fā)游戲邏輯
Corona醒叁，使用 Lua 來(lái)開(kāi)發(fā)
…

目前這種方式只有 Unity 3D 發(fā)展比較好司浪，Cocos2d-JS 據(jù)說(shuō)還行，有些小游戲在使用把沼，Corona 感覺(jué)比較非主流啊易，雖然它也支持簡(jiǎn)單的按鈕等界面元素，但用來(lái)寫(xiě) APP 我不看好饮睬，因?yàn)椴婚_(kāi)源所以沒(méi)研究租谈，目前看來(lái)最大的好處似乎是虛擬機(jī)體積小，內(nèi)嵌版本官方號(hào)稱(chēng)只有 1.4M续捂，這是 Lua 引擎比較大的優(yōu)勢(shì)垦垂。
而剩下的 3 個(gè)都基本上掛了，Ejecta 至今還不支持 Android牙瓢，CocoonJS 轉(zhuǎn)型為類(lèi)似 Crosswalk 的 WebView 方案劫拗，而 Unreal Engine 4 開(kāi)始不再支持 UnrealScript，而是轉(zhuǎn)向了使用 C++ 開(kāi)發(fā)矾克，感興趣可以圍觀一下 Epic 創(chuàng)始人解釋為什么要這么做页慷。
當(dāng)然，這些游戲引擎都不適合用來(lái)做 APP胁附，一方面是會(huì)遇到前面提到的界面繪制問(wèn)題酒繁，另一方面游戲引擎的實(shí)現(xiàn)一般都要不斷重繪，這肯定比普通 App 更耗電控妻，很容易被用戶發(fā)現(xiàn)后怒刪砌滞。

Adobe AIR

從我周邊了解到的情況看对雪，幾乎所有人都以為 Flash 徹底放棄移動(dòng)端了上煤，不得不說(shuō) Adobe 的宣傳真是失策藏斩，明明只是放棄移動(dòng)瀏覽器端插件，F(xiàn)lash 還是可以在 iOS 下運(yùn)行的好不好菇存，那就是 Adobe AIR夸研，對(duì)于熟悉 ActionScript 的團(tuán)隊(duì)來(lái)說(shuō)，這是一種挺好的跨平臺(tái)游戲開(kāi)發(fā)解決方案依鸥，國(guó)內(nèi)游戲公司之前有用亥至，現(xiàn)在還有沒(méi)人用我就不知道了，不過(guò)考慮到很多不明真相的小朋友都以為 Flash 在移動(dòng)端掛了，所以后備力量肯定嚴(yán)重不足姐扮，連人都招不到絮供，其它就別想了。
評(píng)論中有人指出在 iOS 下是通過(guò)編譯實(shí)現(xiàn)的茶敏，看來(lái)和 Xamarin RoboVM 很類(lèi)似杯缺。

但開(kāi)發(fā) APP 方面，它同樣缺乏好的 UI 庫(kù)睡榆，Flex 使用體驗(yàn)很差，目前基本上算掛了袍榆，目前只有 Feathers 還算能看胀屿，不過(guò)主要是給游戲中的 UI 設(shè)計(jì)的，并不適合用來(lái)開(kāi)發(fā) APP包雀。

Dart

Dart 在 Web 基本上失敗了宿崭，于是開(kāi)始轉(zhuǎn)戰(zhàn)移動(dòng)開(kāi)發(fā)，目前有兩個(gè)思路才写，一個(gè)是類(lèi)似 Lua 那樣的嵌入語(yǔ)言來(lái)統(tǒng)一公共代碼葡兑，但因?yàn)?Dart 虛擬機(jī)源自 V8，在一開(kāi)始設(shè)計(jì)的時(shí)候就只有 JIT 而沒(méi)有解釋器赞草，甚至連字節(jié)碼都沒(méi)有讹堤，所以它無(wú)法在 iOS 下運(yùn)行，于是 Dart 團(tuán)隊(duì)又做了個(gè)小巧的虛擬機(jī) Fletch厨疙，它基于傳統(tǒng)的字節(jié)碼解釋執(zhí)行方式來(lái)運(yùn)行洲守，目前代碼只有 1w 多行，和 Lua 一樣輕量級(jí)沾凄。
另一個(gè)就是最近比較熱門(mén)的 Sky梗醇，這里吐槽一下國(guó)內(nèi)外的媒體，我看到的報(bào)道都是說(shuō) Google 想要用 Dart 取代 Android 下的 Java 開(kāi)發(fā)撒蟀。叙谨。。這個(gè)東東確實(shí)是 Google 的 Chrome 團(tuán)隊(duì)開(kāi)發(fā)的保屯，但 Google 是一個(gè)很大的公司好不好手负，內(nèi)部有無(wú)數(shù)小團(tuán)隊(duì)，某個(gè)小團(tuán)隊(duì)并不能代表個(gè) Google配椭，如果真是 Google 高層的決定虫溜，它將會(huì)在 Google I/O 大會(huì)主題演講上推出來(lái)，而不是 Dart Developer Summit 這樣非主流的技術(shù)分享股缸。
有報(bào)道稱(chēng) Sky 只支持在線應(yīng)用衡楞，不支持離線，這錯(cuò)得太離譜了，人家只是為了演示它的在線更新能力瘾境，你要想將代碼內(nèi)嵌到 app 里當(dāng)然是可以的歧杏。

Sky 的架構(gòu)如下圖所示，它參考了 Chrome迷守，依靠一個(gè)消息系統(tǒng)來(lái)和本地環(huán)境進(jìn)行通訊犬绒，使得 Dart 的代碼和平臺(tái)無(wú)關(guān)，可以運(yùn)行在各種平臺(tái)上兑凿。

C++ 不包含注釋的代碼部分就有近 70w 行啊，而且一看目錄結(jié)構(gòu)就是濃濃的 Chromium 風(fēng)格，至少?gòu)募夹g(shù)難度來(lái)說(shuō)絕對(duì)秒掉前面所有方案恼琼，也印證了我前面說(shuō)過(guò)如果有簡(jiǎn)化版 CSS/HTML 就能很好解決性能問(wèn)題妨蛹。
這也讓我理解了為什么 Eric 在談到 Mojo 的時(shí)候語(yǔ)焉不詳，讓人誤以為僅僅是一個(gè)消息系統(tǒng)晴竞，他要是明確說(shuō)這是一個(gè)精簡(jiǎn)版 Chrome蛙卤，那得引起多大的誤會(huì)啊，沒(méi)準(zhǔn)會(huì)有小編用「Google 宣布開(kāi)發(fā)下一代瀏覽器內(nèi)核取代 Blink」這樣的標(biāo)題了噩死。
之前 Dart 決定不將 Dart VM 放到 Chrome 里颤难，原來(lái)并不是因?yàn)楸?a target="_blank" rel="nofollow">眾人反對(duì)而死心了，而是因?yàn)?fork 了一個(gè) Chrome 自己拿來(lái)玩了已维。
綜合來(lái)看乐严，目前 Dart 的這兩個(gè)方案都非常不成熟，Sky 雖然在技術(shù)上看很強(qiáng)大衣摩，但 Dart 語(yǔ)言目前接受度非常低，比起它所帶來(lái)的跨平臺(tái)優(yōu)點(diǎn)捂敌，它的缺點(diǎn)更大艾扮，比如無(wú)法使用第三方 Native UI 庫(kù)，也無(wú)法使用第三方 Web UI 庫(kù)占婉，這導(dǎo)致它的社區(qū)會(huì)非常難發(fā)展泡嘴，命中注定非主流，真可惜了這幫技術(shù)大牛逆济，但方向比努力更重要酌予，希望他們能盡早醒悟，讓 Sky 也支持 JavaScript奖慌。
我的結(jié)論
看到這里估計(jì)不少讀者暈了抛虫，有那么多種方案，最后到底哪個(gè)最適合自己简僧？該學(xué)哪個(gè)建椰？這里簡(jiǎn)單說(shuō)說(shuō)我的看法。
如果你只會(huì) JavaScript岛马，那目前最好的方案是 React Native棉姐，有了它你即使不了解 Native 開(kāi)發(fā)也能寫(xiě)出很多中小應(yīng)用，反正多半不會(huì)火啦逆，花太多精力也沒(méi)意義伞矩，等萬(wàn)一火了再學(xué) Native 開(kāi)發(fā)也不遲啊。
如果你只會(huì) Java夏志，那可以嘗試 RoboVM 或 j2objc乃坤，j2objc 雖然目前更穩(wěn)定靠譜，但它不能像 RoboVM 那樣完全用 Java 開(kāi)發(fā)，所以你還得學(xué) Objective-C 來(lái)寫(xiě)界面侥袜，而 RoboVM 的缺點(diǎn)就是貌似還不太穩(wěn)定蝌诡，而且似乎除了游戲以外還沒(méi)見(jiàn)到比較知名的應(yīng)用使用，而它這種方案注定會(huì)比 j2objc 更容易出問(wèn)題枫吧，所以你得做好踩坑的心理準(zhǔn)備浦旱。
如果你只會(huì) C#，那唯一的選擇就是 Xamarin 了九杂。
如果你只會(huì) Objective-C颁湖，很杯具目前沒(méi)有比較靠譜的方案，我建議你還是學(xué)學(xué) Java 吧例隆，多學(xué)一門(mén)語(yǔ)言沒(méi)啥壞處甥捺。
如果你只會(huì) C++，可以做做游戲或非 UI 的公共部分镀层，我不建議使用 QT 或自己畫(huà)界面镰禾，還是學(xué)學(xué) Native 開(kāi)發(fā)吧。
如果你只會(huì) Go唱逢，還別指望用它開(kāi)發(fā)移動(dòng)端吴侦，因?yàn)槟壳暗膶?shí)現(xiàn)很低效，而且這和 Go 底層的實(shí)現(xiàn)機(jī)制密切相關(guān)坞古，導(dǎo)致很難優(yōu)化备韧，所以預(yù)計(jì)很長(zhǎng)一段時(shí)間內(nèi)也不會(huì)有改觀。
如果你會(huì) Rust痪枫，說(shuō)明你很喜歡折騰织堂，多半也會(huì)前面所有語(yǔ)言，自己做決定吧奶陈。易阳。。
當(dāng)然吃粒，上面都是針對(duì)個(gè)人的闽烙，對(duì)于團(tuán)隊(duì)來(lái)說(shuō)，那不用想了声搁，肯定用 Native黑竞，然后混用內(nèi)嵌的方案，比如 Lua疏旨、React Native很魂，前面那些排它的方案（比如 Titanium）千萬(wàn)別選，會(huì)死很慘檐涝。
本文涉及到的技術(shù)點(diǎn)很多遏匆，有什么不準(zhǔn)確的地方歡迎提出法挨，另外可以關(guān)注我的微博 weibo.com/nwind 進(jìn)行交流。
P.S. 本文說(shuō)的是移動(dòng)端幅聘，很多人覺(jué)得跨平臺(tái)從來(lái)都不靠譜凡纳，但其實(shí)是有的，那就是 Web帝蒿，這個(gè)歷史上最成功的例子荐糜，太成功以致于大家都習(xí)以為常了，大樹(shù)之下葛超，寸草不生暴氏，它擠掉了其它方案的生存空間，十幾年前還有 B/S 和 C/S 之爭(zhēng)呢绣张。