從HybridApp到RN，再到Flutter，跨平臺(tái)技術(shù)的發(fā)展十分火熱，在平時(shí)的業(yè)務(wù)開發(fā)中，跨平臺(tái)也往往由于其動(dòng)態(tài)性，開發(fā)速度，節(jié)省人力而占據(jù)越來(lái)越大的比重。以下簡(jiǎn)單對(duì)比一下跨平臺(tái)技術(shù)

為什么純?cè)_發(fā)不占優(yōu)勢(shì)了

原生開發(fā)的優(yōu)勢(shì)

速度快，性能好。在進(jìn)行一些復(fù)雜的動(dòng)畫繪制時(shí)，體驗(yàn)更好。

一些硬件的訪問，像攝像頭、GPS都可以直接訪問，省去了通過跨平臺(tái)框架協(xié)議兼容的中間件。

它的劣勢(shì)

僅支持特定平臺(tái)，開發(fā)成本高（Android、iOS）

動(dòng)態(tài)化差，改bug基本上只能發(fā)版。

但是目前面臨的問題是

動(dòng)態(tài)化需求變多了，發(fā)版更加頻繁，但是發(fā)版審核都需要時(shí)間，而且過于頻繁的版本更新也會(huì)影響用戶使用，有點(diǎn)跟不上互聯(lián)網(wǎng)的高度發(fā)展

需要Android和iOS兩端開發(fā)，兩個(gè)技術(shù)團(tuán)隊(duì)，人力成本高

所以這些跨平臺(tái)技術(shù)越來(lái)越流行，大幅度壓縮了原生開發(fā)的比重。常見的跨平臺(tái)技術(shù)主要有三種

H5+原生：Hybrid

JS+原生渲染：RN

自繪UI+原生：Flutter

針對(duì)原生開發(fā)的劣勢(shì)，其實(shí)也有一些解決方案

?布局動(dòng)態(tài)化，服務(wù)器下發(fā)布局，客戶端解析加載

熱修復(fù)，如騰訊的thinker等，但是對(duì)Android新版本的支持好像不是很好

Hybrid

簡(jiǎn)單理解為網(wǎng)頁(yè)，webview執(zhí)行h5代碼，本質(zhì)上是個(gè)瀏覽器內(nèi)核，js運(yùn)行在權(quán)限受限的沙箱中，想訪問原生的一些功能，如藍(lán)牙，只能通過調(diào)起原生的代碼實(shí)現(xiàn)。基本上主要是JS通過JsBridge調(diào)用原生的一些功能。

他的優(yōu)勢(shì)在于web技術(shù)棧已經(jīng)很成熟了，資源都很豐富。

劣勢(shì)也很明顯，慢，性能差。復(fù)雜的業(yè)務(wù)界面及動(dòng)畫，卡。

這里也有一些解決方案

?提前將頁(yè)面的公共資源html，css，js模板化，動(dòng)態(tài)下發(fā)到app，在shouldInterceptRequest攔截webview的資源加載，判斷本地模板的資源就直接加載本地的，沒有則再去加載線上資源

數(shù)據(jù)請(qǐng)求由app代理，讓數(shù)據(jù)加載和模板代理并行執(zhí)行

webivew復(fù)用，構(gòu)建一個(gè)webview池，每次進(jìn)入h5頁(yè)，從webview池中取出webview

圖片優(yōu)化，通過shouldInterceptRequest攔截圖片資源并下載

RN

RN實(shí)際上可以理解為js+映射原生空間繪制。

以下簡(jiǎn)單理解一下DOM樹，文檔對(duì)象模型是表示和處理一個(gè)html和xml文檔的標(biāo)準(zhǔn)接口，DOM樹就是文檔樹，與用戶界面的控件樹相對(duì)應(yīng)，也可以與Android的xml布局文件的控件樹相對(duì)應(yīng)

React框架運(yùn)用的是典型的響應(yīng)式編程，狀態(tài)改變則UI隨之改變，它是響應(yīng)用戶狀態(tài)改變的事件而構(gòu)建用戶界面。它的好處是

開發(fā)者只需要關(guān)心狀態(tài)（數(shù)據(jù)），狀態(tài)改變了，UI自然會(huì)改變

當(dāng)接收到用戶狀態(tài)改變的通知時(shí)，根據(jù)當(dāng)前渲染樹，通過diff算法，算出樹中變化的部分，然后只更新改變的部分，避免整個(gè)樹重構(gòu)，提高性能

此處，React框架也不會(huì)立即就刷新界面，而是抽象出一個(gè)虛擬DOM層，改動(dòng)先同步到虛擬DOM層上，然后再批量同步到真實(shí)DOM上，因?yàn)闉g覽器的每次DOM操作都可能引起瀏覽器的重繪或回流。

RN中的虛擬DOM樹最終會(huì)通過JavaScriptCore映射為原生控件樹。JSCore是一個(gè)JS解釋器，作用跟JSBridge差不多

為JS提供運(yùn)行環(huán)境

是JS與原生通信的橋梁

RN中虛擬DOM樹映射為原生控件有兩步

布局消息傳遞：將虛擬DOM布局信息傳遞給原生

原生根據(jù)布局信息通過對(duì)應(yīng)的原生控件渲染控件樹

它的優(yōu)勢(shì)在于

web技術(shù)棧，社區(qū)大，上手快，成本低

原生渲染，比H5好很多

動(dòng)態(tài)化好，支持熱更新

它的劣勢(shì)在于

渲染時(shí)需要和JS通信，某些場(chǎng)景下可能造成卡頓，如拖動(dòng)

JS為腳本語(yǔ)言，執(zhí)行時(shí)需要JIT，效率比AOT慢

渲染依賴原生控件，不同的平臺(tái)的控件需要單獨(dú)維護(hù)，并且系統(tǒng)更新，社區(qū)控件可能延時(shí)，并且收到原生控件的影響，比如存在手勢(shì)沖突問題

Flutter

Flutter是自繪引擎加原生，在不用的平臺(tái)實(shí)現(xiàn)一個(gè)統(tǒng)一的渲染引擎接口來(lái)繪制UI

它的優(yōu)勢(shì)

性能高

靈活，組件庫(kù)容易維護(hù)，UI保真度和一致性高

它的劣勢(shì)

動(dòng)態(tài)性不足，Flutter是AOT模式編譯的aar包，不能像JIT那樣動(dòng)態(tài)下發(fā)代碼

開發(fā)效率低

Flutter相對(duì)一般的自繪引擎的優(yōu)勢(shì)在于

生態(tài)原來(lái)越豐富了，Flutter社區(qū)、Github資源原來(lái)越多

Google也在推廣Flutter

開發(fā)效率上來(lái)講，Flutter的熱重載可以更快的構(gòu)建UI，添加功能，修復(fù)問題

Flutter采用自己的高性能引擎繪制widget，可以保證一致性，也可以避免對(duì)原生控件的依賴。在開發(fā)時(shí)，Flutter是JIT模式，開發(fā)效率比較高，在打成release包的產(chǎn)物時(shí)，它是AOT模式，它的運(yùn)行效率比較高。而且因?yàn)樗亲约旱匿秩疽?#xff0c;在滑動(dòng)和滾動(dòng)場(chǎng)景下具有明顯的優(yōu)勢(shì)。

總結(jié)

平臺(tái)	優(yōu)勢(shì)	劣勢(shì)
原生	1.能訪問平臺(tái)的全部功能 2.速度快，性能高	1.平臺(tái)特定，開發(fā)成本高 2.不支持動(dòng)態(tài)化
Hybrid	web技術(shù)棧，社區(qū)資源豐富	性能差，復(fù)雜的界面和動(dòng)畫，難以支持
RN	1.web技術(shù)棧，社區(qū)資源豐富，上手成本低 2.原生渲染，性能比h5高 3.支持動(dòng)態(tài)化，熱更新	1.渲染時(shí)需要JS和原生通信，拖動(dòng)時(shí)可能因?yàn)橥ㄐ蓬l繁卡頓 2.執(zhí)行時(shí)時(shí)JIT，執(zhí)行效率低 3.渲染依賴原生控件，當(dāng)系統(tǒng)更新時(shí)，RN的更新可能不及時(shí)
Flutter	1.Flutter社區(qū)生態(tài)越來(lái)越豐富 2.性能高，支持AOT 3.自繪UI引擎，不同平臺(tái)展示效果一致 4.開發(fā)JIT，編譯AOT	1.不支持動(dòng)態(tài)化 2.開發(fā)效率低

參考

《Flutter實(shí)戰(zhàn)》

Android WebView H5 秒開方案總結(jié) - 掘金

總結(jié)

以上是生活随笔為你收集整理的Android 跨平台技术对比的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。