跨平臺(tái)一直是老生常談的話題，cordova、ionic、react-native、weex、kotlin-native、flutter等跨平臺(tái)框架的百花齊放，頗有一股推倒原生開發(fā)者的勢(shì)頭。本文將對(duì)當(dāng)下跨平臺(tái)移動(dòng)開發(fā)的現(xiàn)狀、實(shí)現(xiàn)原理、框架的選擇等進(jìn)行深度解析。
為什么我們需要跨平臺(tái)開發(fā)？ 本質(zhì)上，跨平臺(tái)開發(fā)是為了增加代碼復(fù)用，減少開發(fā)者對(duì)多個(gè)平臺(tái)差異適配的工作量，降低開發(fā)成本，提高業(yè)務(wù)專注的同時(shí)，提供比web更好的體驗(yàn)。通俗了說就是：省錢、偷懶。
本篇主要以react-native、weex、flutter，結(jié)合資訊展望，深入聊聊當(dāng)前跨平臺(tái)移動(dòng)開發(fā)的實(shí)現(xiàn)原理、現(xiàn)狀與未來。至于為什么只講它們，因?yàn)閷?duì)比ionic、phoneGap，它們更于 “naive”。
目前移動(dòng)端跨平臺(tái)開發(fā)中，大致歸納為以下幾種情況：
react native、weex均使用Java作為編程語言，目前Java在跨平臺(tái)開發(fā)中，可謂占據(jù)半壁江山，大有“一統(tǒng)天下”的趨勢(shì)。
kotlin-native開始支持iOS和Web開發(fā)，（kotlin已經(jīng)成為android的一級(jí)語言）也想嘗試“一統(tǒng)天下”。
flutter是Google跨平臺(tái)移動(dòng)UI框架，Dart作為谷歌的親兒子，毫無疑問Dart成為flutter的編程語言，如下圖，作為巨頭新生兒，在flutter官網(wǎng)也可以看出，flutter同樣“心懷天下”。
Facebook 出品，Java語言，JSCore引擎，React設(shè)計(jì)模式，原生渲染
1.1、理念架構(gòu)
“ Learn once, write anywhere ”，代表著 Facebook對(duì) react native 的定義：學(xué)習(xí) react ，同時(shí)掌握web與app兩種開發(fā)技能。 react native 用了 react 的設(shè)計(jì)模式，但UI渲染、動(dòng)畫效果、網(wǎng)絡(luò)請(qǐng)求等均由原生端實(shí)現(xiàn)。開發(fā)者編寫的js代碼，通過 react native 的中間層轉(zhuǎn)化為原生控件和操作，比ionic等跨平臺(tái)應(yīng)用，大大提高了的用戶體驗(yàn)。
總結(jié)起來其實(shí)就是利用 JS 來調(diào)用 Native 端的組件，從而實(shí)現(xiàn)相應(yīng)的功能。
如下圖所示，react native 的跨平臺(tái)是實(shí)現(xiàn)主要由三層構(gòu)成，其中 C++ 實(shí)現(xiàn)的動(dòng)態(tài)連結(jié)庫(.so)，作為中間適配層橋接，實(shí)現(xiàn)了js端與原生端的雙向通信交互。這里最主要是封裝了JavaCore執(zhí)行js的解析，而 react native 運(yùn)行在JavaCore中，所以不存在瀏覽器兼容的問題。
其中在IOS上直接使用內(nèi)置的javacore，在Android則使用 webkit.org官方開源的jsc.so 。
1.2、實(shí)現(xiàn)原理
和前端開發(fā)不同，react native所有的標(biāo)簽都不是真實(shí)控件，JS代碼中所寫控件的作用，類似 Map 中的key值。JS端通過這個(gè)key組合的Dom，最后Native端會(huì)解析這個(gè) Dom ，得到對(duì)應(yīng)的Native控件渲染，如 Android 中標(biāo)簽對(duì)應(yīng) ViewGroup 控件。
在 react native 中，JS端是運(yùn)行在獨(dú)立的線程中（稱為JS Thread ）。JS Thread 作為單線程邏輯，不可能處理耗時(shí)的操作。那么如fetch 、圖片加載、數(shù)據(jù)持久化等操作，在 Android 中實(shí)際對(duì)應(yīng)的是okhttp 、Fresco 、SharedPreferences等。而跨線程通信，也意味著 Js Thread 和原生之間交互與通訊是異步的。
可以看出，跨平臺(tái)的關(guān)鍵在于C++ 層，開發(fā)人員大部分時(shí)候，只專注于JS 端的代碼實(shí)現(xiàn)。 在原生端提供的各種 Native Module 模塊（如網(wǎng)絡(luò)請(qǐng)求，ViewGroup控件），和 JS 端提供的各種 JS Module（如JS EventEmiter模塊），都會(huì)在C++ 實(shí)現(xiàn)的so中保存起來，雙方的通訊通過C++中的保存的映射，最終實(shí)現(xiàn)兩端的交互。通信的數(shù)據(jù)和指令，在中間層會(huì)被轉(zhuǎn)為String字符串傳輸，雙向的調(diào)用流程如下圖。
1.3、打包加載
最終，JS代碼會(huì)被打包成一個(gè) bundle 文件，自動(dòng)添加到 App 的資源目錄下。react native 的打包腳本目錄為/node_modules/react-native/local-cli，打包最后會(huì)通過 metro 模塊壓縮 bundle 文件。而bundle文件只會(huì)打包js代碼，自然不會(huì)包含圖片等靜態(tài)資源，所以打包后的靜態(tài)資源，其實(shí)是被拷貝到對(duì)應(yīng)的平臺(tái)資源文件夾中。
其中圖片等存在資源的映射規(guī)則，比如放在 react native 項(xiàng)目根目錄下的 img/pic/logo.png 的資源，編譯時(shí)，會(huì)被重命名后，根據(jù)大小 merged 到對(duì)應(yīng)的是drawable目錄下，修改名稱為img_pic_logo.png。
打包Android和IOS，肯定需要相應(yīng)的平臺(tái)項(xiàng)目存在，在 react-native init 時(shí)創(chuàng)建的項(xiàng)目，就已經(jīng)包含了 android 和 ios 的模版工程，打包完的工程會(huì)加載bundle文件，然后啟動(dòng)項(xiàng)目，如下圖。這里就不展（tou）開（lan）了，有興趣的可以看：React Native For Android 架構(gòu)初探。
Alibaba 出品，Java語言，JS V8引擎，Vue設(shè)計(jì)模式，原生渲染
2.1、理念架構(gòu)
“Write once, run everywhere”, weex的定義就像是： 寫個(gè) vue 前端，順便幫你編譯成性能還不錯(cuò)的 apk 和 ipa （當(dāng)然，現(xiàn)實(shí)有時(shí)很骨感）。基于 Vue 設(shè)計(jì)模式，支持 web、android、ios 三端，原生端同樣通過中間層轉(zhuǎn)化，將控件和操作轉(zhuǎn)化為原生邏輯來提高用戶體驗(yàn)。
在 weex 中，主要包括三大部分：JS Bridge、Render、Dom，分別對(duì)應(yīng)WXBridgeManager、WXRenderManager、WXDomManager，三部分通過WXSDKManager統(tǒng)一管理。其中 JS Bridge 和 Dom 都運(yùn)行在獨(dú)立的 HandlerThread 中，而 Render 運(yùn)行在 UI 線程。
JS Bridge 主要用來和 JS 端實(shí)現(xiàn)進(jìn)行雙向通信，比如把 JS 端的 dom 結(jié)構(gòu)傳遞給 Dom 線程。Dom 主要是用于負(fù)責(zé) dom 的解析、映射、添加等等的操作，最后通知UI線程更新。而 Render 負(fù)責(zé)在UI線程中對(duì) dom 實(shí)現(xiàn)渲染。
2.2、實(shí)現(xiàn)原理
和 react native一樣，weex 所有的標(biāo)簽也不是真實(shí)控件，JS 代碼中所生成存的 dom，最后都是由 Native 端解析，再得到對(duì)應(yīng)的Native控件渲染，如 Android 中標(biāo)簽對(duì)應(yīng)WXTextView控件。
weex 中文件默認(rèn)為 .vue ，而 vue 文件是被無法直接運(yùn)行的，所以 vue 會(huì)被編譯成 .js 格式的文件，Weex SDK會(huì)負(fù)責(zé)加載渲染這個(gè)js文件。Weex可以做到跨三端的原理在于： 在開發(fā)過程中，代碼模式、編譯過程、模板組件、數(shù)據(jù)綁定、生命周期等上層語法是一致的 。不同的是在JS Framework層的最后，web 平臺(tái)和 Native 平臺(tái)，對(duì) Virtual DOM 執(zhí)行的解析方法是有區(qū)別的。
實(shí)際上，在 Native 中對(duì) bundle 文件的加載大致經(jīng)歷以下階段：
weex 接收到 js 文件以后，JS Framework 根據(jù)文件為 Vue 模式，會(huì)調(diào)用weex-vue-framework中提供的createInstance方法創(chuàng)建實(shí)例。
createInstance中會(huì)執(zhí)行 Js Entry 代碼里new Vue()創(chuàng)建一個(gè)組件，通過其 render 函數(shù)創(chuàng)建出 Virtual DOM 節(jié)點(diǎn)。
由JS V8 引擎上解析 Virtual DOM ，得到 Json 數(shù)據(jù)發(fā)送至 Dom 線，這里輸出 Json 也是方便跨端的數(shù)據(jù)傳輸。
Dom 線程解析 Json 數(shù)據(jù)，得到對(duì)應(yīng)的WxDomObject，然后創(chuàng)建對(duì)應(yīng)的WxComponent提交 Render 。
得益于上層的統(tǒng)一性，只是通過weex-vue-framework判斷是由Vue.js生成真實(shí)的 Dom ，還是通過 Native Api 渲染組件，weex 一定程度上上，用JS 實(shí)現(xiàn)了vue一統(tǒng)天下的效果。
weex 在原生渲染 Render 時(shí)，在接收到渲染指令后，會(huì)逐步將數(shù)據(jù)渲染成原生組件。Render 通過解析渲染數(shù)據(jù)的描述，然后分發(fā)給不同的模塊。
比如 控件渲染屬于dom模塊中，頁面跳轉(zhuǎn)屬于navigator模塊等。模塊的渲染過程并非一個(gè)執(zhí)行完，再執(zhí)行另一個(gè)的流程，而是類似流式的過程。如上一個(gè)的組件還沒渲染好，下一個(gè)的渲染又發(fā)了過來。這樣當(dāng)一個(gè)組件的嵌套組件很多時(shí)，或者可以看到這個(gè)大組件內(nèi)的UI，一個(gè)一個(gè)渲染出來的過程。
承當(dāng)了重要的職責(zé)，使得上層具備統(tǒng)一性，可以支持跨三個(gè)平臺(tái)?？偟膩碚f它主要負(fù)責(zé)是： 管理Weex的生命周期；解析JS Bundle，轉(zhuǎn)為Virtual DOM，再通過所在平臺(tái)不同的API方法，構(gòu)建頁面；進(jìn)行雙向的數(shù)據(jù)交互和響應(yīng)。
2.3、打包
weex 作為 react-native 之后出現(xiàn)的跨平臺(tái)實(shí)現(xiàn)方案，自然可以站在前人的肩膀上優(yōu)化問題，比如：Bundle文件過大問題。
Bundle文件的大小，很大程度上影響了框架的性能，而 weex 選擇將JS Framework集成到 WeexSDK 中，一定程度減少了JS Bundle的體積，使得 bundle 里面只保留業(yè)務(wù)代碼。
打包時(shí)，weex 是通過 webpack 打包出 bundle 文件的。bundle 文件的打包和 entry.js文件的配置數(shù)量有關(guān)，默認(rèn)情況下之后一個(gè) entry 文件，自然也就只有一個(gè)bundle文件。
在 weex 項(xiàng)目的 webpack.common.conf.js中可以看到，其實(shí)打包也是區(qū)分了 webConfig和weexConfig的不同打包方式。如下圖，其中weexEntry 就是 weex 打包配置的地方，可以看到本來已經(jīng)有index和 entry.js存在了。如果有需要，可配置上你需要的打包頁面，具體這里就不詳細(xì)展開了。有興趣可看：Weex原理之帶你去蹲坑 。
Google 出品，Dart語言，F(xiàn)lutter Engine引擎，響應(yīng)式設(shè)計(jì)模式，原生渲染
Flutter 是谷歌2018年發(fā)布的跨平臺(tái)移動(dòng)UI框架。相較于本人已經(jīng)在項(xiàng)目中使用過 react native 和 Weex，F(xiàn)lutter目前僅僅是簡(jiǎn)單運(yùn)行過Demo，畢竟還是beta 階段，這里更多的聊一下它的實(shí)現(xiàn)機(jī)制和效果。
與 react native 和 weex 的通過 Java 開發(fā)不同，F(xiàn)lutter 的編程語言是Drat，（谷歌親兒子，據(jù)說是因?yàn)?Drat 項(xiàng)目組就在 Flutter 隔壁而被選上）所以執(zhí)行時(shí)并不需要 Java 引擎，但實(shí)際效果最終也通過原生渲染。
如上圖，F(xiàn)lutter 主要分為Framework和Engine，我們基于Framework 開發(fā)App，運(yùn)行在 Engine 上。Engine 是 Flutter 的獨(dú)立虛擬機(jī)，由它適配和提供跨平臺(tái)支持，目前猜測(cè) Flutter 應(yīng)用程序在 Android 上，是直接運(yùn)行 Engine 上 所以在是不需要Dalvik虛擬機(jī)。（這是比kotlin更徹底，拋棄JVM的糾纏？）
如下圖，得益于 Engine 層，F(xiàn)lutter 甚至不使用移動(dòng)平臺(tái)的原生控件， 而是使用自己 Engine 來繪制 Widget （Flutter的顯示單元），而 Dart 代碼都是通過 AOT 編譯為平臺(tái)的原生代碼，所以 Flutter 可以 直接與平臺(tái)通信，不需要JS引擎的橋接。同時(shí) Flutter 唯一要求系統(tǒng)提供的是 canvas，以實(shí)現(xiàn)UI的繪制。咦？這么想來，支持web端也沒問題吧！
在Flutter中，大多數(shù)東西都是widget，而widget是不可變的，僅支持一幀，并且在每一幀上不會(huì)直接更新，要更新而必須使用Widget的狀態(tài)。無狀態(tài)和有狀態(tài) widget 的核心特性是相同的，每一幀它們都會(huì)重新構(gòu)建，有一個(gè)State對(duì)象，它可以跨幀存儲(chǔ)狀態(tài)數(shù)據(jù)并恢復(fù)它。
Flutter 上 Android 自帶了 Skia，Skia是一個(gè) 2D的繪圖引擎庫，跨平臺(tái)，所以可以被嵌入到 Flutter的 iOS SDK中，也使得 Flutter Android SDK要比 iOS SDK小很多。
這算是互相傷害的環(huán)節(jié)了吧。
上面Apk大小是通過react-native init、weex create 和 flutter 創(chuàng)建出的工程后，直接不添加任何代碼，打包出來的 release 簽名 apk 大小。從下圖可以看出，其中大比例都是在so庫。
react native 作為 Facebook 主力開源項(xiàng)目之一，至今已有各類豐富的第三方庫，甚至如realm、lottie 等開源項(xiàng)目也有 react native 相關(guān)的版本，社群實(shí)際無需質(zhì)疑。當(dāng)然，因?yàn)椴⑼耆y(tǒng)開發(fā)平臺(tái)，第三庫的健壯性和兼容性有時(shí)候總是良莠不齊。
weex 其實(shí)有種生錯(cuò)在國(guó)內(nèi)的感覺。其實(shí) weex 的設(shè)計(jì)和理念都很優(yōu)秀，性能也不錯(cuò)，但是對(duì)比 react native 的第三方支持，就顯得有點(diǎn)后媽養(yǎng)的。2016年開源至今，社區(qū)和各類文檔都顯得有點(diǎn)疲弱，作為跨平臺(tái)開發(fā)人員，大多時(shí)候肯定不會(huì)希望，需要頻繁的自己增加原生功能支持，因?yàn)檫@樣的工作一多，反而會(huì)與跨平臺(tái)開發(fā)的理念背道而馳，帶來開發(fā)成本被維護(hù)難度增加。
Flutter目前還處理beta階段，但是谷歌的號(hào)召力一直很可觀，這一點(diǎn)無需質(zhì)疑。
理論上 flutter 的性能應(yīng)該是最好的，但是目前實(shí)際體驗(yàn)中，卻并沒有感受出來太大的差距，和 react native（0.5.0之后）、weex 在性能上個(gè)人體驗(yàn)差異不是很大。當(dāng)然，這里并沒有實(shí)測(cè)渲染的毫秒時(shí)間和幀率數(shù)據(jù)。
Weex的多頁面實(shí)現(xiàn)問題
weex 在 native 端是不支持 的，這一點(diǎn)和 react-native 不同在與，如果在 native 需要實(shí)現(xiàn)頁面跳轉(zhuǎn)，使用 vue-router 將會(huì)慘不忍睹：返回后頁面不做特別處理時(shí)，是會(huì)空白一片。參考官方Demo playground ，native 端 的采用weex.requireModule(‘navigator’)跳轉(zhuǎn) Activity 是才正確實(shí)現(xiàn)。
同時(shí)，weex中 navigator 跳轉(zhuǎn)的設(shè)計(jì)，也導(dǎo)致了多頁面的頁面間通訊的差異。weex在多頁面下的數(shù)據(jù)通訊，是通過url實(shí)現(xiàn)的，比如file://assets/dist/SecondPage.js params=0，而vuex和vue-router在跨頁面是無法共用的；而 react native 在跨 Actvity 使用時(shí)，因?yàn)槭峭粋€(gè)bundle文件，只要 manager 相同，那么 router 和 store 時(shí)可以照樣使用的，數(shù)據(jù)通信方式也和當(dāng)個(gè) Actvity 沒區(qū)別。
項(xiàng)目模板
weex 和 react native 模板代碼模式也不同。weex 的模板是從 cordova 模式修改過來的，根據(jù)platform需求，用命令添加固定模塊，而在 .gitignore 對(duì) platforms文件夾是忽略跟蹤。 react native 在項(xiàng)目創(chuàng)建時(shí)模版就存在了，特別是添加第三方插件原生端支持時(shí)，會(huì)直接修改模板代碼，git代碼中也會(huì)添加跟蹤修改。
我們選擇框架的時(shí)候，很多時(shí)候會(huì)關(guān)注框架的成熟度和生命力不是么。
“Airbnb 宣布放棄使用 React Native，回歸使用原生技術(shù)” : Airbnb 作為 react native 平臺(tái)上大的支持者之一，其開源的lottie同樣是支持原生和 react native。
Airbnb 在宣布放棄的文中，也對(duì) react native 的表示了很大量的肯定，而使得他們放棄的理由，其實(shí)主要還是集中于項(xiàng)目龐大之后的維護(hù)困難，第三方庫的良莠不齊，兼容上需要耗費(fèi)更多的精力導(dǎo)致放棄。
ps：（ Lottie庫Airbnb出的是一個(gè)能夠幫助解析AE導(dǎo)出的包含動(dòng)畫信息的json文件。這很好的解決了一個(gè)矛盾，設(shè)計(jì)師可以更專注的設(shè)計(jì)出各種炫酷的動(dòng)畫效果，而開發(fā)只需要將其加入支持即可。）
Facebook 正在重構(gòu) React Native，將重寫大量底層。 在經(jīng)歷了開源協(xié)議風(fēng)波后，可以看出 Facebook 對(duì)于 react native 還是很看重的， 這些底層重構(gòu)優(yōu)化的地方，主要集中于：
首先，改變線程模型。UI 更新不再需要在三個(gè)不同的線程上執(zhí)行，而是可以在任意線程上同步調(diào)用 Java 進(jìn)行優(yōu)先更新，同時(shí)將低優(yōu)先級(jí)工作推出主線程，以便保持對(duì) UI 的響應(yīng)。其次，將異步渲染功能引入 React Native 中，允許執(zhí)行多個(gè)渲染并簡(jiǎn)化異步數(shù)據(jù)處理。最后，簡(jiǎn)化橋接，讓它更快、更輕量。原生和 Java 之間的直接調(diào)用效率更高，并且可以更輕松地構(gòu)建調(diào)試工具，如跨語言堆棧跟蹤。
沒有死！阿里公開Weex技術(shù)架構(gòu)，還開源了一大波組件。 從 2018年初的新聞可以看出，weex 的遭遇有點(diǎn)類似曾經(jīng)的 Duddo（Dubbo因?yàn)閮?nèi)部競(jìng)爭(zhēng)被阿里一度放棄維護(hù)），這波詐尸后weex被托管到了Apache，而github的weexteam 如今也還保持著更新，希望后續(xù)能有多好的發(fā)展，拭目以待吧。
Flutter 是 Google 跨平臺(tái)移動(dòng)UI框架，Dart作為谷歌的親兒子在 Flutter 中使用，并且谷歌新操作系統(tǒng) Fuchsia 支持 Dart，使用 Flutter 作為操作UI框架。這些集合到一起難免讓你懷疑 Android 是否要被谷歌拋棄的想法。
或者如今先 Android 等平臺(tái)上推廣 Flutter 與 Dart，就是為了以后跟好的過渡到新系統(tǒng)上，畢竟開發(fā)者是操作系統(tǒng)的生命源泉之一。而 Java 與 JVM 或者可以被谷歌完全拋開。當(dāng)然，目前看起來 Flutter 貌似還缺少一些語法糖，嵌套下來的代碼有點(diǎn)不忍直視，或者到正式版之后，我們更能感受出它的美麗吧。
另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)scvps.cn，海內(nèi)外云服務(wù)器15元起步，三天無理由+7*72小時(shí)售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國(guó)服務(wù)器、虛擬主機(jī)、免備案服務(wù)器”等云主機(jī)租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡(jiǎn)單易用、服務(wù)可用性高、性價(jià)比高”等特點(diǎn)與優(yōu)勢(shì)，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場(chǎng)景需求。
重慶分公司
重慶分公司
