導(dǎo)讀

本文主要針對(duì)常用跨端技術(shù)Flutter、ReactNative、Weex、H5，從技術(shù)特點(diǎn)、基本架構(gòu)、編譯原理、基本渲染流程等進(jìn)行梳理分析；以及一些常見(jiàn)性能問(wèn)題如何優(yōu)化解決，然后如何進(jìn)行技術(shù)選型或在進(jìn)行業(yè)務(wù)開(kāi)發(fā)時(shí)選擇不同技術(shù)棧的邏輯是什么。

01背景

在今年的敏捷團(tuán)隊(duì)建設(shè)中，我通過(guò)Suite執(zhí)行器實(shí)現(xiàn)了一鍵自動(dòng)化單元測(cè)試。Juint除了Suite執(zhí)行器還有哪些執(zhí)行器呢？由此我的Runner探索之旅開(kāi)始了！

隨著技術(shù)的發(fā)展，產(chǎn)生了越來(lái)越多的端，如Android、iOS、Mac、Windows、Web、Fuchsia OS、鴻蒙等，而隨著公司業(yè)務(wù)的發(fā)展，出現(xiàn)了越來(lái)越多的業(yè)務(wù)場(chǎng)景；作為APP開(kāi)發(fā)人員，在日常工作中難免會(huì)碰到以下問(wèn)題，如：1、UI設(shè)計(jì)師在進(jìn)行UI審查時(shí)、測(cè)試同學(xué)在回歸測(cè)試過(guò)程中、業(yè)務(wù)方在使用過(guò)程中，多少會(huì)發(fā)現(xiàn)端與端存在著差異，影響用戶體驗(yàn)；2、同樣的業(yè)務(wù)、同樣的功能在不同的端上，需要每端投入資源去開(kāi)發(fā)實(shí)現(xiàn)。而移動(dòng)互聯(lián)網(wǎng)的發(fā)展已經(jīng)處于晚期，領(lǐng)導(dǎo)們?cè)絹?lái)越關(guān)心投入產(chǎn)出。

與此同時(shí)，出現(xiàn)了一些跨端的技術(shù)解決方案，可以實(shí)現(xiàn)一套代碼在多端運(yùn)行，解決業(yè)務(wù)發(fā)展上的痛點(diǎn)，如Flutter、ReactNative、Weex、H5（注：小程序和其它基于DSL的方案暫不在本文討論范圍）。然后對(duì)一些常用APP進(jìn)行了對(duì)比分析，結(jié)論和預(yù)期一致，大部分都在使用跨端技術(shù)；Flutter和ReactNative使用率較高，Weex使用率相對(duì)低一些，H5基本都在使用，使用多種跨端技術(shù)框架是一種常態(tài)。那么，它們都有哪些特點(diǎn)呢?

02 四種技術(shù)棧特點(diǎn)介紹

理解，首先 MCube 會(huì)依據(jù)模板緩存狀態(tài)判斷是否需要網(wǎng)絡(luò)獲取最新模板，當(dāng)獲取到模板后進(jìn)行模板加載，加載階段會(huì)將產(chǎn)物轉(zhuǎn)換為視圖樹(shù)的結(jié)構(gòu)，轉(zhuǎn)換完成后將通過(guò)表達(dá)式引擎解析表達(dá)式并取得正確的值，通過(guò)事件解析引擎解析用戶自定義事件并完成事件的綁定，完成解析賦值以及事件綁定后進(jìn)行視圖的渲染，最終將目標(biāo)頁(yè)面展示到屏幕。

圖1-技術(shù)棧特點(diǎn)

通過(guò)圖1，從性能、開(kāi)發(fā)語(yǔ)言、渲染、包大小、社區(qū)、支持平臺(tái)等方面梳理了它們的主要特點(diǎn)；不由產(chǎn)生幾個(gè)問(wèn)題：為什么原生和Flutter性能更好？為什么ReactNative和Weex性能相對(duì)較差？為什么H5頁(yè)加載慢？這些性能問(wèn)題該如何去優(yōu)化，這是需要深入了解的問(wèn)題，下面將從基本的架構(gòu)、渲染流程、編譯運(yùn)行原理等一起分析。

03基礎(chǔ)架構(gòu)介紹
3.1 Flutter基礎(chǔ)架構(gòu)介紹

ABM是Apple公司提供的iOS應(yīng)用的分發(fā)渠道之一，與App Store平臺(tái)不同，ABM是2019年10月才開(kāi)始在中國(guó)區(qū)啟動(dòng)的一套全新的應(yīng)用分發(fā)系統(tǒng)，部分功能和企業(yè)賬號(hào)類似，旨在為企業(yè)提供快速、高效的方式來(lái)部署應(yīng)用到企業(yè)擁有的蘋果設(shè)備。ABM與App Store兩個(gè)平臺(tái)的關(guān)鍵區(qū)別如下：

圖2-Flutter基礎(chǔ)架構(gòu)

Google在2018年發(fā)布了Flutter 1.0，如圖2所示，主要分為Framework層和Engine層；

Framework層：基于Dart實(shí)現(xiàn)，主要包括Text、Image、Button、動(dòng)畫、手勢(shì)等各種Widgets，核心基礎(chǔ)類庫(kù)io、async、ui等package；基于Framework開(kāi)發(fā)App，其運(yùn)行在Engine層上，F(xiàn)ramework和邏輯層都在基于Dart語(yǔ)言開(kāi)發(fā)，對(duì)于開(kāi)發(fā)而言，一切都是Widget，Widget是UI實(shí)現(xiàn)的基礎(chǔ)；Engine層：基于C 、C實(shí)現(xiàn)；主要包括Skia渲染引擎庫(kù)、Dart Runtime、Text文本渲染庫(kù)等，而Engine層自帶Skia渲染引擎，以此實(shí)現(xiàn)所有端的渲染展示統(tǒng)一，在Engine層適配平臺(tái)差異和跨平臺(tái)支持，實(shí)現(xiàn)更完美的跨端效果；Dart代碼通過(guò)AOT編譯為運(yùn)行平臺(tái)的二進(jìn)制代碼。也就是說(shuō)Flutter不需要橋接，自己完成從邏輯側(cè)和渲染側(cè)的所有能力，和原生類似。這也是它性能突出的關(guān)鍵所在。另外Android自帶Skia引擎，所以也使得在Android的的編譯產(chǎn)物比iOS更小。除了支持移動(dòng)端外，還支持Mac OS、Windows等PC端和Web端，在新的Funchsia OS也支持Dart，使用Flutter作為UI框架。

對(duì)于Flutter Web，F(xiàn)ramework層是公用的，意味著業(yè)務(wù)層可以使用此層的widgets實(shí)現(xiàn)邏輯跨端；但Engine層則不同，需要通過(guò)Canvas Render或者 HTML Render對(duì)齊Engine的能力。2022年5月Google IO大會(huì)發(fā)布Flutter 3.0，除了移動(dòng)端，更好的支持了Mac OS、Linux平臺(tái)，也包括其它一系列優(yōu)化和支持，大家可以多關(guān)注。

3.2 ReactNative基礎(chǔ)架構(gòu)介紹
ABM是Apple公司提供的iOS應(yīng)用的分發(fā)渠道之一，與App Store平臺(tái)不同，ABM是2019年10月才開(kāi)始在中國(guó)區(qū)啟動(dòng)的一套全新的應(yīng)用分發(fā)系統(tǒng)，部分功能和企業(yè)賬號(hào)類似，旨在為企業(yè)提供快速、高效的方式來(lái)部署應(yīng)用到企業(yè)擁有的蘋果設(shè)備。ABM與App Store兩個(gè)平臺(tái)的關(guān)鍵區(qū)別如下：

圖3-ReactNative基礎(chǔ)架構(gòu)

ReactNative是Facebook于2015年開(kāi)源，如圖3所示，主要服務(wù)于Android和iOS兩端，采用React開(kāi)發(fā)實(shí)現(xiàn)邏輯側(cè)代碼（也可應(yīng)用于前端），采用Redux實(shí)現(xiàn)狀態(tài)管理，在APP中UI渲染、網(wǎng)絡(luò)請(qǐng)求、動(dòng)畫等均由原生側(cè)橋接實(shí)現(xiàn)；在這里實(shí)際運(yùn)行過(guò)程中，js側(cè)的dom會(huì)形成一個(gè)virtual dom，并通過(guò)bridge橋接將此dom結(jié)構(gòu)傳輸?shù)皆鷤?cè)，原生側(cè)會(huì)解析并映射到原生控件，形成原生的dom結(jié)構(gòu)后，再調(diào)用原生能力進(jìn)行渲染展示。

2021年ReactNative新版本對(duì)底層進(jìn)行了重構(gòu)，可以關(guān)注一下，如改變線程模型，引入異步渲染能力，允許多個(gè)渲染并簡(jiǎn)化異步數(shù)據(jù)處理，簡(jiǎn)化 JSBridge等。

3.3 Weex基礎(chǔ)架構(gòu)介紹

圖4-Weex基礎(chǔ)架構(gòu)

Weex是阿里2016年發(fā)布的跨端框架，如圖4所示，Weex編譯產(chǎn)物js bundle可以部署在服務(wù)端，APP加載完即可運(yùn)行，也可以看出具備動(dòng)態(tài)發(fā)布的能力；和ReactNative類似，Weex在實(shí)際運(yùn)行過(guò)程中，js側(cè)會(huì)形成一個(gè)dom，并通過(guò)Bridge交由原生側(cè)解析，映射到原生控件再由原生能力進(jìn)行渲染；Weex基于JS V8引擎，基于Vue設(shè)計(jì)，支持Android、iOS、Web三端。

3.4 WebView基礎(chǔ)架構(gòu)介紹

圖5-WebView內(nèi)核基礎(chǔ)架構(gòu)

WebView內(nèi)核模塊較復(fù)雜，如圖5所示，這里主要介紹WebView架構(gòu)主要的幾個(gè)部分：橋接協(xié)議是上層邏輯測(cè)與WebView的通信層，是JS和Native互相通信的能力層；

WebCore是瀏覽器加載和排版渲染頁(yè)面的基礎(chǔ)，主要包括資源加載、HTML解析、CSS解析、DOM解析、排版渲染等，JavaScript引擎是JavaScript解析器，JavaScriptCore是Webkit的JavaScript引擎，V8是Google的Blink的默認(rèn)引擎；WebKit Ports是WebKit中移植部分，包括網(wǎng)絡(luò)、字體、圖片解碼、音視頻解碼、硬件加速等模塊；然后再往下也使用了很多第三方庫(kù)，包括2D圖形庫(kù)、3D圖形庫(kù)、網(wǎng)絡(luò)庫(kù)、存儲(chǔ)庫(kù)、音視頻庫(kù)等；最底層是操作系統(tǒng)，支持Android、iOS、Windows等系統(tǒng)。

3.5 編譯原理分析

Flutter支持Release、Profile、Debug編譯模式。

Release模式即使用AOT預(yù)編譯模式，預(yù)編譯為機(jī)器碼，通過(guò)編譯生成對(duì)應(yīng)架構(gòu)的代碼，在用戶設(shè)備上直接運(yùn)行對(duì)應(yīng)的機(jī)器碼，運(yùn)行速度快，執(zhí)行性能好；此模式關(guān)閉了所有調(diào)試工具，只支持真機(jī)。對(duì)于編譯產(chǎn)物，iOS側(cè)主要生成App.framework和Flutter.framework；App.framework為dart代碼編譯產(chǎn)物，F(xiàn)lutter.framework為引擎編譯產(chǎn)物；Android側(cè)主要在lib下增加了libapp.so和libflutter.so，libapp.so為dart代碼編譯產(chǎn)物，libflutter.so為引擎編譯產(chǎn)物，不同的是在assets下增加了flutter_assets存放引用資源文件。

Profile模式和Release模式類似，此模式最重要的作用是可以用DevTools來(lái)檢測(cè)應(yīng)用的性能，做性能調(diào)試分析。

Debug模式使用JIT即時(shí)編譯技術(shù)，支持常用的開(kāi)發(fā)調(diào)試功能hot reload，在開(kāi)發(fā)調(diào)試時(shí)使用，包括支持的調(diào)試信息、服務(wù)擴(kuò)展、Observatory、DevTools等調(diào)試工具，支持模擬器和真機(jī)。iOS側(cè)主要生成App.framework和Flutter.framework，在App.framework文件夾里多了isolate_snapshot_data，kernel_blob.bin，vm_snapshot_data；Android側(cè)也同樣多了多了以上文件，但lib下少了libapp.so文件。

ReactNative整體分為邏輯側(cè)和渲染側(cè)，邏輯側(cè)基于js引擎，會(huì)將基于React寫的代碼編譯為JavaScript原生代碼，再編譯生成jsbundle文件，內(nèi)置或下發(fā)到APP端運(yùn)行；而渲染側(cè)依賴于Android或iOS原生渲染，需要分平臺(tái)編譯對(duì)應(yīng)的編譯產(chǎn)物，然后發(fā)布到服務(wù)端或內(nèi)置到APP。

Weex和ReactNative類似，weex會(huì)將源碼編譯為js bundle，這些js bundle可以部署在服務(wù)端，APP下載完js bundle后，通過(guò)js引擎構(gòu)建虛擬dom并通過(guò)橋接映射到原生dom，由原生渲染引擎進(jìn)行渲染。

H5：以React和Vue為例，會(huì)將以框架開(kāi)發(fā)的代碼編譯為JavaScript原生代碼，即然后在瀏覽器或者WebView中執(zhí)行；內(nèi)核會(huì)先建立連接、加載資源，然后解析、排版布局、繪制渲染呈現(xiàn)給用戶。

3.6 基本渲染流程對(duì)比

圖6-基本渲染流程對(duì)比

簡(jiǎn)單分析渲染流程，基于Android和iOS原生開(kāi)發(fā)APP，調(diào)用Framework框架層實(shí)現(xiàn)上層邏輯，經(jīng)過(guò)布局繪制后直接調(diào)用系統(tǒng)渲染引擎進(jìn)行渲染展示；基于Flutter開(kāi)發(fā)APP，會(huì)直接調(diào)用Skia渲染引擎進(jìn)行渲染展示；不依賴于原生渲染。

基于ReactNative或Weex開(kāi)發(fā)APP則不同，首先業(yè)務(wù)邏輯是基于React或Weex開(kāi)發(fā)，然后會(huì)將js bundle包預(yù)置或下載到APP，然后將虛擬dom通過(guò)bridge映射到原生控件，再調(diào)用原生渲染引擎進(jìn)行渲染展示。

基于Hybrid方案開(kāi)發(fā)APP，需要通過(guò)React、Vue等前端框架實(shí)現(xiàn)，首頁(yè)要編譯為JavaScript原生語(yǔ)言，然后通過(guò)鏈接在WebView或?yàn)g覽器加載頁(yè)面，關(guān)鍵的流程是連接加載、解析、排版、繪制，最后再調(diào)渲染引擎進(jìn)行展示。

通過(guò)以上所有分析，可以回答前面提出的問(wèn)題：

為什么原生和Flutter性能更好？主是都是經(jīng)過(guò)布局繪制后直接調(diào)系統(tǒng)或自帶渲染引擎進(jìn)行展示。

為什么ReactNative和Weex性能相對(duì)慢？主要是需要下載js bundle包，并把js dom結(jié)構(gòu)解析映射到原生，而下載和預(yù)置都比較耗時(shí)，并且依賴原生進(jìn)行渲染（ReactNative新版本升級(jí)了基礎(chǔ)架構(gòu)，據(jù)說(shuō)有較大性能提升，大家也可以關(guān)注）。

為什么H5頁(yè)加載慢？主要因?yàn)檫B接和加載比較耗時(shí)，這里占大部分時(shí)間，連接和加載完以后基本就是WebView或?yàn)g覽器本地可以完成的工作，后期優(yōu)化也可以以此為切入點(diǎn)。

04常見(jiàn)主要性能問(wèn)題優(yōu)化

在實(shí)際開(kāi)發(fā)過(guò)程中也遇到了一些性能問(wèn)題，接下來(lái)進(jìn)行簡(jiǎn)單介紹。

4.1 如何優(yōu)化Flutter性能？

關(guān)鍵優(yōu)化指標(biāo)：頁(yè)面異常率、頁(yè)面FPS幀率、頁(yè)面加載時(shí)長(zhǎng)。

頁(yè)面異常率（異常發(fā)生次數(shù) / 整體頁(yè)面 PV 數(shù)）：通過(guò) runZoned 與 FlutterError 兩個(gè)方法，在異常攔截的方法中統(tǒng)計(jì)異常的發(fā)生次數(shù)和堆棧數(shù)據(jù)。

頁(yè)面FPS幀率：如何采集FPS是關(guān)鍵，通過(guò)window對(duì)象注冊(cè)onReportTimings回調(diào)，就可以得到整個(gè)構(gòu)建和渲染過(guò)程的耗時(shí)，然后就可以算出頁(yè)面的FPS。

頁(yè)面加載時(shí)長(zhǎng)（頁(yè)面可見(jiàn)的時(shí)間-頁(yè)面創(chuàng)建的時(shí)間）：頁(yè)面可見(jiàn)的時(shí)間通過(guò)WidgetsBinding的addPostFrameCallback回調(diào)獲取，頁(yè)面創(chuàng)建的時(shí)間通過(guò)頁(yè)面初始化方法initState獲取。

將以上數(shù)據(jù)上傳到監(jiān)控和性能分析平臺(tái)（mPaaS和燭龍），作為后期性能分析和優(yōu)化的參考數(shù)據(jù)，在開(kāi)發(fā)過(guò)程中可通過(guò)DevToos性能分析工具、Flutter Inspector分析優(yōu)化性能。按需加載，局部刷新也是常用的優(yōu)化手段。其它性能優(yōu)化如布局加載優(yōu)化、狀態(tài)管理優(yōu)化、啟動(dòng)優(yōu)化-引擎預(yù)加載、內(nèi)存優(yōu)化、包大小優(yōu)化等不再詳細(xì)介紹。可以多關(guān)注Flutter社區(qū)，定期升級(jí)Flutter版本，會(huì)帶來(lái)很好的收獲。

4.2 如何優(yōu)化ReactNative加載慢的問(wèn)題？

一是可以預(yù)下載bundle包，減少包加載的時(shí)間，打開(kāi)頁(yè)面直接映射渲染，從而達(dá)到更快打開(kāi)頁(yè)面的目的，當(dāng)然也可以預(yù)置包，需要平衡好包大小和性能；

二是嘗試升級(jí)ReactNative最新版本，新版本升級(jí)了基礎(chǔ)架構(gòu)，主要包括線程模型，引入了異步渲染能力，優(yōu)化JSBridge，對(duì)性能有明顯提升（作者咨詢過(guò)京東mPaaS團(tuán)隊(duì)，也在跟進(jìn)中）。

4.3 如何優(yōu)化APP中H5加載慢的問(wèn)題

圖7-加載H5流程介紹

圖7描述了從WebView初始化到H5頁(yè)面最終渲染的整個(gè)過(guò)程，以及和前面H5基本渲染流程進(jìn)行分析。耗時(shí)環(huán)節(jié)的主要有兩點(diǎn)，一是WebView初始化，可以通過(guò)提前初始化WebView優(yōu)化此問(wèn)題；二是資源（html、js、css圖片等）的請(qǐng)求連接和加載，可以用H5離線包方案解決此問(wèn)題，通過(guò)資源的預(yù)加載，解決html、js、css和資源圖片的加載問(wèn)題，從而大大降低資源的加載時(shí)間，提升頁(yè)面加載性能，甚至達(dá)到秒開(kāi)的效果。

05總結(jié)

那么如何技術(shù)選型呢？應(yīng)該以提升開(kāi)發(fā)效率和用戶體驗(yàn)為前提去思考，然后再分析關(guān)鍵因素：

1、技術(shù)棧的基礎(chǔ)架構(gòu)如何，原始架構(gòu)是否優(yōu)秀，是否更面向未來(lái)發(fā)展；

2、團(tuán)隊(duì)技術(shù)棧成熟度，學(xué)習(xí)的成本，社區(qū)的成熟度；

3、研發(fā)效率，實(shí)現(xiàn)代碼多端復(fù)用，減少多端差異，降低開(kāi)發(fā)成本，更加專注于業(yè)務(wù)開(kāi)發(fā)；而效率提升是一個(gè)持續(xù)的收益過(guò)程，體現(xiàn)在業(yè)務(wù)發(fā)展的整個(gè)生命周期。當(dāng)然，對(duì)于新技術(shù)在實(shí)踐前期會(huì)有一些成本，但熟悉后總的收益是長(zhǎng)期的；

4、是否更好解決多端一致性，更好解決UI設(shè)計(jì)師在UI審查時(shí)、測(cè)試同學(xué)在測(cè)試過(guò)程中、業(yè)務(wù)方在使用過(guò)程中發(fā)現(xiàn)的端與端并異問(wèn)題，風(fēng)格統(tǒng)一也是良好用戶體驗(yàn)的重要體現(xiàn)；

5、支持動(dòng)態(tài)化的程度，解決新需求必須發(fā)版的問(wèn)題，也是業(yè)務(wù)的痛點(diǎn)，關(guān)鍵因素；

6、用戶體驗(yàn)是最關(guān)鍵的，也需考慮用戶的使用環(huán)境（網(wǎng)絡(luò)環(huán)境、手機(jī)配置）等；

對(duì)于正式的C端項(xiàng)目，面對(duì)千萬(wàn)甚至億級(jí)的用戶量，技術(shù)選型策略一定是在保證用戶體驗(yàn)的基礎(chǔ)上實(shí)現(xiàn)降本提效，用戶第一，用戶利益最大化即保證了公司的利益；對(duì)于非C端項(xiàng)目，可能需要考慮在實(shí)現(xiàn)降本提效基礎(chǔ)上提升用戶體驗(yàn)。