5000字解析：前端五種跨平臺技術

寫在開頭：

本文不涉及到任何代碼，只講概念層面的，結合本人在實際開發過程當中的各類體驗，對這幾種跨平臺技術進行一個點評

---

跨平臺技術的由來：

傳統的純原生開發已經不能知足日益增加的業務需求。主要表如今以下兩個方面。

1)動態化內容需求增大。當需求發生變化時，純原生應用須要經過版本升級來更新內容，但應用上架、審覈是須要週期的，這個週期對高速變化的互聯網時代來講是很難接受的，因此，對應用動態化(不發版也能夠更新應用內容)的需求就變得迫在眉睫了。

2)業務需求變化快，開發成本變大。因爲原生開發通常都要維護 Android、iOS兩個

開發團隊，版本迭代時，不管人力成本仍是測試成本都會變大。

總結一下，純原生開發主要面臨動態化和開發成本兩個問題，而針對這兩個問題，又誕生了一些跨平臺的動態化框架。

---

跨平臺技術簡介

針對原生開發面臨的問題，人們一直都在努力尋找好的解決方案，然而時至今日，已經存在不少跨平臺框架(注意，本書中所指的「跨平臺」若無特殊說明，即特指 Android和iOS兩個平臺)，根據其原理，主要可分爲以下三類。

1)H5(HTML5)+原生( Cordova、 Tonic、微信小程序)。2) Javascript開發+原生渲染( React Native、Wex、快應用)。3)自繪U+原生( QT Mobile、 Flutter)。

接下來，咱們將逐個來了解這三類框架的原理及優缺點。

1.12 Hybrid技術簡介

H5+原生混合開發

這類框架的主要原理是將APP須要動態變更的一部份內容經過H5來實現，經過原生的網頁加載控件 Webview( Android)或 WK Webview(iOS)來加載(之後若無特殊說明，本書將用 Webview來統一指代 Android和iOs中的網頁加載控件)。這樣，H5部分就能夠

隨時改變而不用發版，動態化需求獲得知足;同時，因爲H5代碼只須要一次開發，就能同時在 Android和OS兩個平臺上正常運行，這也能夠下降開發成本，也就是說，H5部分的

功能越多，開發成本就越小。咱們稱這種H5+原生的開發模式爲混合開發，對於採用混合模式開發的APP，咱們稱之爲混合應用或 Hybrid APP，若是一個應用的大多數功能都是採用H5實現的話，咱們稱其爲 Web APP。

目前混合開發框架的典型表明有 Cordova、 lonic和微信小程序，值得一提的是，微信小程序目前是在 Webview中渲染的。並不是原生渲染，但未來有可能會採用原生渲染。

---

混合開發技術點

如以前所述，原生開發能夠訪間平臺的全部功能，而在混合開發中，H5代碼是運行在

Web Vicw中的， Webview實質上就是一個瀏覽器器內核、其script依然運行在一個權限

受限的沙箱中，因此對大多數系統能力都沒有訪向權限、如沒法訪向文件系統、不能使用藍牙等，因此，對於H5不能實現的功能，都須要原生來實現。

而混合框架通常都會在原生代碼中預先實現一些訪問系統能力的API，而後暴露給 Webview以供 Javascript調用，這樣一來， Webview就成爲 Javascript與原生AP之間通訊的橋樑，主要負責 Javascript與原生之間調用消息的傳遞，而消息的傳遞必須遵照一個標準的協議，其規定了消息的格式與含義，咱們將依賴於 Webview的、用於在 Javascript與原生之間通訊並實現了某種消息傳輸協議的工具稱爲 Webview Javascript Bridge，簡稱 Jsbridge，它也是混合開發框架的核心.

---

我所使用的跨平臺技術：

• Electron
• React-Native
• Taro
• Cordova
• 快應用
• Flutter(剛學習)
• ...

排名由前日後，除了Flutter沒有使用過在商業項目中

---

Electron的核心：

Electron就是把Node.js的運行環境和谷歌瀏覽器內核一塊兒打包了，因而就擁有了Node.js和H5技術的融合能力，又由於是基於C++編寫，因而能夠跨平臺。Mac、windows、Linux。

工具類的軟件是最複雜的，例如vscode、word這些，都是極度複雜的，又由於能夠調用addon、各類腳本插件，原生第三方插件，這個技術簡直就是黑科技，至今我也不敢說對它熟悉。可是APP Store已經不能上線Electron應用了，並且打包簽名服務器也常常掛

特別注意：Electron開發出來的東西是軟件，是一個安裝在電腦上的軟件！

個人GitHub可能有你想要的Demo內容：

https://github.com/JinJieTan

要想開發好Electron，要擁有一名C++人員專門編寫插件，一位後端出生的人生操做sqlite數據庫（數據庫升級雖然能夠兼容老版本，可是複雜的應用設計得很差數據庫就完了），一位先後端都懂而且熟悉調用操做系統插件的全棧工程師開發，這樣才能hold得住複雜應用。若是你說這樣是否是太浪費了，那我以爲你沒有開發過複雜的軟件，一個好的軟件（客戶端），要考慮程序反編譯（保護）、奔潰守護進程等異常蒐集、用戶自動升級（差量or全量）、本地數據庫加密、通訊、激活喚醒。。。。太多了，可是大部分前端作的就是後臺管理系統，這也是一個悲劇。。。面試造火箭

像之前我就作過將微信和QQ裏面一些插件拿出來通過一些處理用在項目裏，至此打開了新世界,總之Electron很是考驗技術，是晉升僞全棧工程師最快的路徑

推薦學習指數：五顆星

---

React-native

去年愛彼迎把APP的技術從RN換回了原生，首先它是外企，它可能某種程度上，使用RN會比國內有更大的優點，得到更大的支持。就像你使用Taro，那麼你有可能在論壇上找到它的負責人，提出想要的支持，最後它真的支持了（這個是存在的，若是你想認識能夠幫你聯繫，我也在建議身邊人使用Taro）

回到正題：

難道RN死了嗎？ 

JQuery都沒死，它會死嗎？固然不會！RN的生態很是強大，它開發出來的，也是真正的原生應用，它的原理以下：

在React-native文件中編寫的代碼，會在內存中生成虛擬DOM對象（其實就是一個JS對象），而後再經過javaScriptCore（IOS自帶，安卓不是，因此RN打包後安卓的包比蘋果大）映射成原生控件樹。不少jsBridge都是基於javaScriptCore實現的

例如：

iOS代碼發送通知：
//須要包含的頭文件
#import <React/RCTEventDispatcher.h>
#import <React/RCTBridge.h>
[self.bridge.eventDispatcher sendAppEventWithName:@"EventNotification"
                                              body:@{@"name": @"nnnnnnn"}];
RN代碼接收通知：
//建立一個監聽收到的通知，須要組件NativeAppEventEmitter
var listener = NativeAppEventEmitter.addListener(
'EventNotification', //監聽的通知名稱
   (reminder) => console.log(reminder.name, '收到的通知')
);

提示：跨平臺不是什麼高深的技術，只要搞懂它的運行機制原理，就好開發，定位問題。

---

那麼RN有什麼缺點呢？例如頻繁setState，可能會形成卡頓（作動畫的時候容易掉幀，特別是性能差的手機），可是也是可使用一些技術優化儘可能避免，跟是誰寫的有很大關係，還有就是項目變得特別大，跟原生交互特別多，特別複雜的應用，跨平臺遇到的問題兼容處理也會愈來愈多，這也是爲何愛彼迎會換回原生的緣由，維護確實比較麻煩，還有版本環境的問題，有可能你升級了之後再也啓動不了了。。。

推薦理由：開發快速，生態成熟，使用React的JSX語法和FLex佈局快速開發原生應用，推薦學習指數：四顆星

---

Taro

小程序跨平臺開發，一款能夠用TSX、JSX和React語法開發小程序的框架，內置了一些UI組件，還有物料市場，目前看勢頭很好。還能夠集成React-native,真正作到一套代碼多處運行，不只能編譯成各類平臺小程序，還能夠是RN的應用～ 666 ,還支持快應用

https://taro.aotu.io/

現現在市面上端的形態多種多樣，Web、React-Native、微信小程序等各類端大行其道，當業務要求同時在不一樣的端都要求有所表現的時候，針對不一樣的端去編寫多套代碼的成本顯然很是高，這時候只編寫一套代碼就可以適配到多端的能力就顯得極爲須要。

使用 Taro，咱們能夠只書寫一套代碼，再經過 Taro 的編譯工具，將源代碼分別編譯出能夠在不一樣端（微信/百度/支付寶/字節跳動/QQ/京東小程序、快應用、H五、React-Native 等）運行的代碼。

Taro的源碼我沒看過，可是我看裏面用了不少他們本身寫的babel包，應該是JIT模式，加入了中間層，把你寫的東西，編譯成了小程序能夠執行的代碼，我的認爲小程序不要作得太複雜，否則你還不如作個APP，輕量跨平臺，天然是最快速的，並且可使用TSX語法，React，太好了。

推薦指數：五顆星

---

Cordova

它是一個比較古老的技術，可是我目前的公司使用得比較6，還作成了一套產業體系，我以爲它也挺不錯的

它是比較傳統的跨平臺技術，相似小程序，在webView中渲染，原理以下：

其實就是原生的webView去加載，執行H5代碼，這樣能夠跨平臺，並且能夠隨時更新發布內容。這就是傳統的hybrid APP (混合開發)

還有一種webApp,直接用h5的技術打包成APP，比較簡單，這個百度下就知道了

Hybrid技術應該比較多，可是原理大同小異，都是經過webView加載，性能體驗確定沒有原生好，由於調用webView須要幾百毫秒的時間，可是也能夠經過一些技術優化，跟誰寫也有很大關係

---

快應用

就是華爲、小米等國內廠商爲了跟小程序競爭搞出來的，像RN這些框架，回內置一些渲染/排版引擎，那麼打包出來提交比較大，快應用是集成到安卓手機的ROM中，因此只有源碼那部分，安裝體積比較小，這樣就叫快應用

快應用使用原生js開發，框架跟原生微信小程序很像（寫着不舒服，Taro支持快應用）

提示：寫快應用的工資很高，感受基本都在30K以上（多是錯覺）

---

Flutter

Flutter是ogle推出並開源的移動應用開發框架，主要特色是跨平臺、高保真、有些性能。開發者能夠經過Dar語言開發APP，一套代碼能夠同時運行在OS和 Android平臺以上。Flutter提供了豐富的組件、接口，開發者能夠很快地爲 Flutter添加 Native擴展。

同時Flutter還可使用 Native引擎渲染視圖，這無疑能爲用戶提供良好的體驗。

跨平臺自繪引擎

Flutter與用於構建移動應用程序的其餘大多數框架不一樣，由於 Flutter既不使用Webview，也不使用操做系統的原生控件。相反， Flutter使用本身的高性能渲染引擎來繪製 Widget。這樣不只能夠保證在 Android和iOS上UI的一致性，並且能夠避免因對原生控

件依賴而帶來的限制及高昂的維護成本。

Flutter使用ska做爲其2D渲染引擎，Skia是 Google的一個2D圖形處理函數庫，包含字形、座標轉換，以及點陣圖，且都有高效能且簡潔的表現，Skia是跨平臺的，而且其還提供了很是友好的API，目前 Google Chrome瀏覽器和 Android均採用Skia做爲其繪圖引擎。目前， Flutter默認支持iOS、 Android、 Fuchsia( Google新的自研操做系統)三個移動平臺。但 Flutter亦可支持Web開發( Flutter for Web)和PC開發

高性能

Flutter的高性能主要靠兩點來保證，首先， Flutter APP採用Dart語言開發。Dart在JT(即時編譯)模式下，速度與 Javascript基本持平。同時Dar還支持AOT，當以AOT模式運行時， Javascript便遠遠追不上了。速度的提高對高幀率下的視圖數據計算頗有幫助。其次， Flutter 1使用本身的渲染引擎來繪製UI，佈局數據等由Dan語言直接控制，因此在佈局過程當中不須要像RN那樣要在 Javascript和 Native之間通訊。

這一點在一些滑動和拖動的場景下具備明顯的優點，由於滑動和拖動的過程每每會引發佈局發生變化，因此 Javascript須要與 Native不停地同步佈局信息，這與在瀏覽器中要 Javascript頻繁操做DOM所帶來的問題是相同的，都會帶來比較可觀的性能開銷。

重點：Flutter本身有本身的渲染引擎，這樣避免了以上幾種跨平臺技術的經過中間層通訊帶來的性能開銷，可是依然避免不了寫原生代碼，並且目前GitHub上的issue還比較多，不太小編已經入坑了，就學最後一個，之後就不學前端了

Dart語言學習也須要一些成本，若是公司有這個安排的話，能夠入坑嘗試

綜上五種所述：不同的業務場景有同樣的技術場景，技術爲產品服務，跨平臺的出現並非爲了幹掉原生，而是爲了更好的、更高效的開發

若是你想加入大前端學習羣，能夠關注微信公衆號：前端巔峯 ，回覆：加羣 便可加入