跨平臺(tái) App 開(kāi)發(fā)有哪些技術(shù)方案，各有哪些優(yōu)缺點(diǎn)？是否需要從原生 App 開(kāi)發(fā)切換到這些跨平臺(tái)的方案上來(lái)？切換過(guò)去能節(jié)省多少工作量？

如果你有這些疑問(wèn)，這篇文章有你需要的信息。

Hybrid 技術(shù)

這類(lèi)技術(shù)，使用 HTML/CSS/JavaScript 等前端技術(shù)來(lái)構(gòu)建 App。利用 JSBridge 獲取部分訪問(wèn)原生 API 的能力。最有代表性的是 PhoneGap，它是 Adobe 收購(gòu)一家開(kāi)源創(chuàng)業(yè)公司后推出的平臺(tái)。這個(gè)鏈接有 PhoneGap 的一些歷史信息。

這類(lèi)平臺(tái)的目標(biāo)是保持大部分代碼跨平臺(tái)共用，涉及到平臺(tái)不共用的 API （比如 GPS 接口，iOS 和 Android 肯定是不一樣的），則由 PhoneGap 平臺(tái)通過(guò) JSBridge 提供。除此之外，還有一些明顯的優(yōu)點(diǎn)：

• 開(kāi)發(fā)效率較高：使用 HTML/CSS/JavaScript 構(gòu)建界面的效率要比原生 App 速度快很多。而且前端開(kāi)發(fā)有一堆現(xiàn)成的框架和開(kāi)源庫(kù)可以直接使用。
• 即時(shí)更新：有 Bug 可以快速更新，不需要發(fā)布新 App，只需要更新服務(wù)器上更新相關(guān)的 HTML/CSS/JavaScript 即可。可以繞過(guò) AppStore 的上架認(rèn)證時(shí)間。
• 開(kāi)發(fā)門(mén)檻低：對(duì)于前端開(kāi)發(fā)工程師，可以快速轉(zhuǎn)崗，開(kāi)發(fā)出可用的 App，不需要對(duì) iOS 平臺(tái)和 Android 平臺(tái)有太深入的了解。

這類(lèi)平臺(tái)的硬傷是：

• 單線程：JavaScript 在 WebView 里執(zhí)行時(shí)是單線程的。對(duì)系統(tǒng)并發(fā)能力有較大的影響。
• 性能低：大概只能達(dá)到原生 App 70% 的流暢度。

這篇文章對(duì)幾個(gè)熱門(mén)的 Hybrid 平臺(tái)進(jìn)行了對(duì)比和介紹。

為了克服 Hybrid 的缺點(diǎn)，目前工程應(yīng)用上典型的做法是，以原生 App 為主，把易變的邏輯，以及界面，不涉及性能瓶頸的部分使用基于 WebView 的 Hybrid 技術(shù)來(lái)開(kāi)發(fā)。

準(zhǔn)原生平臺(tái)

為了解決 Hybrid 的問(wèn)題，一些其他的方案逐步流行起來(lái)，最火的要算 React-Native，它是 Facebook 基于其前端框架 React 之上構(gòu)建的跨平臺(tái) App 開(kāi)發(fā)構(gòu)架。

這類(lèi)平臺(tái)的特點(diǎn)是，只使用 JavaScript 來(lái)構(gòu)建界面，但實(shí)際上構(gòu)建出來(lái)的所有界面都是系統(tǒng)原生控件。這是和 Hybrid 平臺(tái)最大的區(qū)別。在 Hybrid 平臺(tái)，一個(gè)按鈕就是 HTML 構(gòu)建出來(lái)的，但在 React-Native 平臺(tái)，一個(gè)按鈕是在各自的平臺(tái) (Android/iOS) 上以原生控件的形式渲染出來(lái)的。

這類(lèi)平臺(tái)最大的優(yōu)勢(shì)是：

• 跨平臺(tái)開(kāi)發(fā)界面及業(yè)務(wù)邏輯：以前端工程師熟悉的構(gòu)架和技術(shù)，以一致的方式構(gòu)建界面和業(yè)務(wù)邏輯。
• 即時(shí)更新：可以把業(yè)務(wù)邏輯放在 JavaScript 里，這樣就可以直接在線更新功能。
• 性能較高：比 Hybrid 性能高，大概能達(dá)到原生 App 90% 的流暢度。
• 開(kāi)發(fā)效率較高：可以使用前端技術(shù)快速構(gòu)建界面。比如，熟悉 React 框架的人，可以無(wú)障礙地在 React-Native 下構(gòu)建界面和業(yè)務(wù)邏輯。

這類(lèi)平臺(tái)和 Hybrid 相比，跟原生平臺(tái)靠得更近一些，更多地依賴(lài)原生平臺(tái)的一些知識(shí)。比如，很多機(jī)制，其實(shí)還是要分 iOS 平臺(tái)和 Android 平臺(tái)的。即無(wú)法做到真正的跨平臺(tái)開(kāi)發(fā)，在利用 React-Native 這類(lèi)構(gòu)架時(shí)，還是需要對(duì)目標(biāo)平臺(tái)有較深入的理解。

除了 React-Native 之外，比較著名的還有 Weex 這是 alibaba 出品的一個(gè)構(gòu)架，它是基于最近火熱的前端構(gòu)架 Vue.js 的。另外一個(gè)是 NativeScript，這是基于老牌的前端構(gòu)架 Angular
之上構(gòu)建的。

大家注意到，這些熱門(mén)平臺(tái)都是基于一個(gè)熱門(mén)的前端構(gòu)架來(lái)構(gòu)建的。從這一點(diǎn)也可以看到這種類(lèi)型的構(gòu)架的目標(biāo)，就是讓前端開(kāi)發(fā)人員可以在其原有知識(shí)體系里，快速開(kāi)發(fā) App ，并且使用自己熟悉的語(yǔ)言 JavaScript 來(lái)處理業(yè)務(wù)邏輯。至于核心的代碼以及性能相關(guān)的代碼，還是需要使用原生編程語(yǔ)言 (OC for iOS, Java for Android) 來(lái)編寫(xiě)，不同的平臺(tái)最終向上層提供一致接口。這樣，上面界面部分代碼，甚至一些邏輯代碼就可以跨平臺(tái)共用了。

原理上，JavaScript 怎么樣和原生平臺(tái)交互呢？

JavaScript 是腳本語(yǔ)言，可以在運(yùn)行時(shí)解釋并執(zhí)行。這類(lèi)平臺(tái)上寫(xiě)出來(lái)的 JavaScript 代碼最終是由原生平臺(tái)里面的 JavaScript 引擎來(lái)負(fù)責(zé)執(zhí)行的。那么 JavaScript 如何調(diào)用原生代碼呢？答案是利用語(yǔ)言的元編程能力，OC 和 Java 都具備一定的元編程能力，這樣 JavaScript 只要知道原生平臺(tái)的類(lèi)名稱(chēng)，函數(shù)名稱(chēng)，就可以調(diào)用到原生平臺(tái)的這個(gè)函數(shù)了。

關(guān)于這個(gè)課題，這里有篇文章寫(xiě)得深入淺出。想要理解原理的同學(xué)，推薦閱讀。

關(guān)于這幾類(lèi)平臺(tái)的性能對(duì)比，這篇文章有非常詳細(xì)的數(shù)據(jù)。

總結(jié)

Hybrid 技術(shù)的愿景是真正達(dá)到一次開(kāi)發(fā)，跨平臺(tái)運(yùn)行，但其性能是其最大的瓶頸。準(zhǔn)原生平臺(tái)的目標(biāo)是讓前端開(kāi)發(fā)人員，基于其熟悉的前端框架，快速開(kāi)發(fā) App 的界面和業(yè)務(wù)邏輯，且其性能和原生 App 很接近。當(dāng)使用準(zhǔn)原生平臺(tái)開(kāi)發(fā) App 時(shí)，除非你是全棧工程師，或者大體了解 iOS/Android 平臺(tái)的一些開(kāi)發(fā)知識(shí)，否則很大概率需要 iOS/Android 原生平臺(tái)的開(kāi)發(fā)人員配合。

以下幾個(gè)場(chǎng)景可以考慮使用 React-Native 之類(lèi)的準(zhǔn)原生架構(gòu)來(lái)開(kāi)發(fā)：

• 熟悉前端技術(shù)構(gòu)架：比如熟悉 React ，則可以考慮使用 React-Native 來(lái)進(jìn)行開(kāi)發(fā)。如果熟悉 Vue.js ，可以考慮選擇 Weex 來(lái)進(jìn)行開(kāi)發(fā)。
• 對(duì)開(kāi)發(fā)效率有較高的要求：特別是那些互聯(lián)網(wǎng)創(chuàng)業(yè)公司，如果剛好又是個(gè)全棧工程師，可以考慮用這種技術(shù)來(lái)來(lái)提高整體開(kāi)發(fā)效率，有可能一個(gè)人把 iOS/Android App 全包圓了。
• 應(yīng)用非常頻繁地更新：不管是修復(fù)嚴(yán)重 Bug 的 HotFix ，還是業(yè)務(wù)場(chǎng)景快速變化，我們?cè)诘却?AppStore 審核的時(shí)候，感覺(jué)是度日如年。如果這個(gè)痛點(diǎn)讓你痛不欲生，不仿考慮一下準(zhǔn)原生平臺(tái)方案。

反過(guò)來(lái)，如果你對(duì)前端開(kāi)發(fā)和構(gòu)架不熟，切換到任何類(lèi)型的跨平臺(tái)技術(shù)方案上來(lái)，成本都將是巨大的。從頭學(xué)習(xí)和適應(yīng)全新的開(kāi)發(fā)模式，雖然最后可能提高了效率，但學(xué)習(xí)時(shí)間成本可能會(huì)是不可承受這重。至少短期來(lái)看，性?xún)r(jià)比不高。