基于前端領(lǐng)域移動端跨平臺方案的研究

岳奎

(四川理工學(xué)院，四川自貢643000)

最早的跨端跨平臺解決方案要追溯到PhoneGap 的時代，也叫作Hybird 時代，代表作Cordova，同時期后來也有了基于AngularJS 和Cordova 的增強版Ionic，這些方案都是混合開發(fā)方案。接著迎來了借助原生渲染的方案，先后出現(xiàn)的有React Na‐tive、Weex、uni-app等。之后出現(xiàn)了放棄原生渲染，自建渲染方案的自渲染技術(shù)Flutter。本文主要研究跨端方案的演進(jìn)過程以及各種跨端方案的各自特性。

1 混合開發(fā)時代

混合(hybird)開發(fā)時代的代表作有Apache Cordova[1]，其前身就是PhoneGap。它允許開發(fā)者用標(biāo)準(zhǔn)的Web 技術(shù)也就是HTTML5、CSS3和JavaScript來做跨平臺開發(fā)。應(yīng)用在每個平臺的具體執(zhí)行細(xì)節(jié)都被封裝了，并借助封裝過原生標(biāo)準(zhǔn)的API去訪問每個設(shè)備的功能，比如相機拍照、地理位置定位、傳感器等。

1.1 混合開發(fā)Apache Cordova實現(xiàn)原理以及特點

1.1.1 實現(xiàn)原理

因為是基于Web技術(shù)，所以必然依賴于WebView才能進(jìn)行頁面渲染展示。那么對于Android 來講就是利用WebView 技術(shù)，對于iOS 來說就是利用的UIWebView 或者WKWebView。所以Web 和客戶端Native 的通信方式是依賴于WebView 提供的相關(guān)接口實現(xiàn)的，對于Android 來講一般常用的相互通信方式是WebView 實例加載Web 的URL 以及Native 注入全局變量(使用addJavascriptInterface[2])到WebView 中，這樣HTML5 就可以全局可見地調(diào)用該方法。對于iOS 來說是利用WKWebview里的evaluateJavaScript 方法直接執(zhí)行即可，那么H5 調(diào)用Native的能力是依靠NA 自身的JavaScriptCore 提供接口出去供H5 來調(diào)用。本質(zhì)上兩端通信還有一個共同的方式就是NA攔截Web的URL(也叫作標(biāo)準(zhǔn)協(xié)議規(guī)范schema)做對應(yīng)的處理，這是一個比較常用，而且容易自定義的協(xié)議規(guī)范，實現(xiàn)也相對簡單靈活。

1.1.2 混合開發(fā)特性

開發(fā)效率方面，對前端開發(fā)者友好，前端眾多生態(tài)都可以拿來使用，比傳統(tǒng)的Android 和iOS 開發(fā)效率快很多，但涉及Native 的部分，依然需要去熟悉掌握原理。其次是能力受限于橋接層，擴展性低。調(diào)試和錯誤日志不友好。熱更能力方面，因為使用JS，所以是支持熱更。多端一致性方面，因完全依賴于Native的webview層的內(nèi)核渲染，無法媲美原生體驗，涉及宿主問題必然需要開發(fā)者自己處理。性能方面，因渲染依賴于WebView，所以性能不如Native 直接渲染，特別對于長列表渲染[4]，性能很差。

綜上所述其實Hybird 方案是一個矛盾結(jié)合體，既要快，又要性能還要完善的生態(tài)。當(dāng)然開發(fā)者們都看到了此缺陷所以才有了后來大家耳熟能詳?shù)腞eact-Native。

2 原生Native渲染時代

常見的通過Native 渲染的技術(shù)目前有React Native、Weex、uni-app，接下來逐個分析相關(guān)方案的原理和特性。

2.1 React Native

架構(gòu)理念是Learn once，write anywhere也就是說掌握了Re‐act 開發(fā)，可以同時掌握Web 和App 兩種開發(fā)技能。React Na‐tive[3]用了react 的設(shè)計模式，但UI 渲染、動畫效果、網(wǎng)絡(luò)請求等功能均由原生實現(xiàn)。開發(fā)者編寫的js 代碼，通過React Native的中間層轉(zhuǎn)化為原生控件來渲染和響應(yīng)事件，相比ionic等跨平臺應(yīng)用，極大地提高了用戶體驗。

2.1.1 React Native的框架組成、渲染原理、平臺通信

首先React Native 框架內(nèi)部已提供了很多內(nèi)置組件，如View、Text 等基礎(chǔ)布局組件，一些功能組件如Button、Picker 等，用于列表展示的List 組件和對應(yīng)Android 平臺和iOS 平臺特有的組件、API 等。同時也提供了編寫與原生平臺交互的接口。渲染這塊主要還是把React寫好的JSX代碼通過ReactElements轉(zhuǎn)換，然后經(jīng)歷React的部分生命周期再由AppRegistry.register‐Component[3]進(jìn)行注冊，接著通過遍歷dom進(jìn)行diff算法，但這里是要經(jīng)過消息隊列異步傳遞的，最終把增量的變化傳遞到Na‐tive 側(cè)，然后進(jìn)行渲染真正的Native 組件。平臺通信這塊主要是通過Bridge 來進(jìn)行通信，所有JS 代碼都是要經(jīng)過JavaScript‐Core編譯，然后給到由C/C++編寫的Bridge橋，當(dāng)作中間人進(jìn)行交換通信，再分發(fā)給對應(yīng)的Android或者iOS宿主。所以這個過程中最消耗性能的其實就是渲染時的消息隊列通信相關(guān)的增量變化。大致的架構(gòu)圖如圖1所示。

圖1 架構(gòu)圖

2.1.2 React Native特點總結(jié)

開發(fā)效率方面，在Web基礎(chǔ)上引進(jìn)了React能力，符合前端大趨勢，但涉及與Native 交互的地方就需要開發(fā)者自己處理，這點還是需要對NA比較熟悉，因本地支持熱加載，也有對應(yīng)配套的調(diào)試dom節(jié)點元素的工具提供，開發(fā)體驗是友好的。動態(tài)化方面，因為用的是react，故可以做線上熱更操作，不過需要結(jié)合三方npm 包或者自研NA 相關(guān)的JS Bundle 文件下載、上傳、替換等功能。多端一致性方面，因為是渲染的NA組件，所以可以保證和Native 擁有一樣的用戶體驗，但三方組件依賴性較強，比如版本更新不及時，社區(qū)活躍度不高。性能方面，稍差于Native，但遠(yuǎn)好于Hybird，但因為渲染時需要JavaScript 和原生之間不停地進(jìn)行數(shù)據(jù)通信，在有些場景如拖動可能會因為通信頻繁導(dǎo)致卡頓。其次是因為JavaScript 為腳本語言，執(zhí)行時需要JIT，執(zhí)行效率相比AOT代碼[5]仍有一定的差距。

2.2 Weex

Weex 也是借助NA 來做渲染的一個移動端跨平臺方案。它和React Native 很多方面都很相似，但還是有不同點，比如它使用的是Vuejs 和Rax 這兩個任意一個框架來編寫代碼，同時Weex 的渲染引擎和DSL 語法層是分開的，這點和React Native理念完全不同。因為很多都和React Native 相似，所以這里就簡單闡述。

2.2.1 Weex整體工作流程

首先會把用vue 寫的項目打包成一份JS Bundle，然后部署到服務(wù)器，客戶端打開某一個網(wǎng)頁，先下載服務(wù)端的JS Bundle，然后在客戶端本地執(zhí)行該JS Bundle。一般會用到JavaScript‐Core 或者V8 引擎去執(zhí)行JS Bundle，JS 執(zhí)行引擎和瀏覽器執(zhí)行過程類似，JS Bundle 的代碼被執(zhí)行，生成VNode 樹進(jìn)行patch，找到最小DOM 節(jié)點的操作變化，把DOM 節(jié)點的操作轉(zhuǎn)變?yōu)镹ative DOM API 的操作，然后調(diào)用WXBridge[6]進(jìn)行通信，WX‐Bridge 將渲染指令分發(fā)到Native 渲染引擎，由Native 渲染引擎完成最終的頁面渲染。

2.2.2 Weex的特性

開發(fā)效率方面，和React Native 幾乎沒啥差別，不過本地開發(fā)調(diào)試方面沒有React Native 體驗好。動態(tài)化方面，天然支持動態(tài)化而且還支持拆bundle，React Native當(dāng)然也支持拆包但需要改造。

2.3 總結(jié)

盡管借助NA 渲染方式相比混合開發(fā)性能高很多，而且方案也很完美，但還有很多不足的地方比如框架自身維護(hù)成本高，主要是因為提供的組件大多依賴原生控件，那么這些An‐droid 和iOS 控件也不是一成不變的，系統(tǒng)廠商也會做一些迭代，那么就必然要適配，適配成本很高。所以就會存在天然抹不平雙端的差異，所以才有了后來的自渲染技術(shù)。

3 自渲染技術(shù)

含義是通過框架自身的自繪引擎，來實現(xiàn)布局和繪制到終端，可以認(rèn)為是從另一個角度的創(chuàng)新，為人們打開的新的方向和思考，自渲染的代表作就是Flutter，接下來我們就一起了解下Flutter的核心架構(gòu)思想以及特性。

3.1 Flutter架構(gòu)組成

Flutter 是以Dart 語言編寫[6]，基于Dart 編寫提供了很多組件也叫Widget，有兩套風(fēng)格的Widget，分別Material 和cuperti‐no。兩套風(fēng)格有很多widget，比如Text、Input等，也提供了動畫、手勢等通用的Widget。因為沒有采用WebView，也就沒有JS和Native 的通信了，而是自行實現(xiàn)一套UI 框架，在引擎底層通過Skia[6]渲染到屏幕。對于UI之外所需要使用的移動設(shè)備自身提供的服務(wù)，比如相機拍照、定位等，則采用Platform Channels[6]接口跟原生系統(tǒng)通信的方式來實現(xiàn)。

3.2 Flutter的特點

效率方面，因為采用dart 語言編寫，需要先熟悉dart 語言，但熟練后效率有明顯提升，同樣也支持熱Hot Reload 能夠很好地在本地進(jìn)行快速的開發(fā)和調(diào)試。動態(tài)化方面，目前iOS是不允許進(jìn)行熱更的，因為蘋果官方禁止JS Path，當(dāng)然Android是可以熱更，但大環(huán)境目前是不太友好的。平臺一致性方面，可以做到像素級UI控制，能做到最大限度的還原，保證最大限度在不同平臺的體驗一致性，目前還支持PC、嵌入式等。性能方面，這塊優(yōu)于以上介紹的所有跨平臺框架方案，也是最能媲美原生性能的跨平臺技術(shù)方案，因為Dart代碼執(zhí)行效率比JS高很多，而且是通過AOT 編譯成平臺原生代碼[7]，渲染采用Skia 方案，既不需要JS Bridge也不涉及虛擬機[8]。

4 總結(jié)

通過從最早的Apache Cordova 混合開發(fā)技術(shù)的背景開始，分析了當(dāng)時混合開發(fā)時代的優(yōu)劣勢，當(dāng)時的開發(fā)者為此做了很多努力和改進(jìn)，讓我們知道當(dāng)時的技術(shù)方案是可以降本增效的，但有諸多弊端，于是就迎來了原生渲染技術(shù)的時代，這個時代放大了前端生態(tài)的繁榮，很多方案都是借助前端技術(shù)棧作為入口，撬動了整個跨端方案，無論是從體驗、性能、一致性上都完勝混合開發(fā)，但還是有諸多不完美，比如依賴三方組件，依賴廠商適配，同步迭代更新成本高等問題。最后出現(xiàn)了自渲染技術(shù)，這對于整個跨平臺方案來說立意高，創(chuàng)新強，一出來就在用戶體驗層面和平臺一致性上完勝依賴原生Native渲染方案，但不支持熱更，有一定的學(xué)習(xí)成本。所以綜上所述，目前性能最佳、一致性最好的方案是自渲染。但如果想支持熱更最佳選擇就是React Native。