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

如果你有這些疑問，這篇文章有你需要的信息昼钻。

Hybrid 技術(shù)

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

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

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

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

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

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

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

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

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

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

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

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

這類平臺(tái)和 Hybrid 相比，跟原生平臺(tái)靠得更近一些魄梯，更多地依賴原生平臺(tái)的一些知識(shí)桨螺。比如，很多機(jī)制酿秸，其實(shí)還是要分 iOS 平臺(tái)和 Android 平臺(tái)的灭翔。即無法做到真正的跨平臺(tái)開發(fā)，在利用 React-Native 這類構(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)建的退客。

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

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

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

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

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

總結(jié)

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

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

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

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