移動(dòng)動(dòng)態(tài)化方案在蜂鳥的架構(gòu)演進(jìn)（含ReactNative與Weex對比）

當(dāng)下，移動(dòng)動(dòng)態(tài)化已經(jīng)成為各大公司都回避不了的問題，產(chǎn)品的快速迭代對技術(shù)提出了更高的要求，而移動(dòng)端的動(dòng)態(tài)化方案也是層出不窮：Hypid、結(jié)構(gòu)化 Native View、React Native、Weex，什么樣的方案才是適合自己團(tuán)隊(duì)的呢？本文將分享餓了么蜂鳥團(tuán)隊(duì)在過去兩年多業(yè)務(wù)快速增長過程中，移動(dòng)動(dòng)態(tài)化方面的實(shí)踐和探索。

成都創(chuàng)新互聯(lián)為客戶提供專業(yè)的成都網(wǎng)站建設(shè)、成都網(wǎng)站制作、程序、域名、空間一條龍服務(wù)，提供基于WEB的系統(tǒng)開發(fā). 服務(wù)項(xiàng)目涵蓋了網(wǎng)頁設(shè)計(jì)、網(wǎng)站程序開發(fā)、WEB系統(tǒng)開發(fā)、微信二次開發(fā)、手機(jī)網(wǎng)站制作設(shè)計(jì)等網(wǎng)站方面業(yè)務(wù)。

什么是移動(dòng)動(dòng)態(tài)化？

移動(dòng)指的是移動(dòng)端，包括安卓、iOS。動(dòng)態(tài)化則是動(dòng)態(tài)部署和邏輯下發(fā)到客戶端的能力。移動(dòng)動(dòng)態(tài)最好的狀態(tài)就是讓移動(dòng)應(yīng)用和 Web 一樣，想發(fā)就發(fā)！

為什么移動(dòng)端要強(qiáng)調(diào)動(dòng)態(tài)化的能力？

原因有如下三大點(diǎn)：

•     業(yè)務(wù)迭代太快。當(dāng)下大部分團(tuán)隊(duì)都是敏捷開發(fā)的模式，即使兩周做一次迭代，產(chǎn)品周期還是會(huì)覺得長，有些應(yīng)用不能及時(shí)上線。

•     應(yīng)用市場審核慢。安卓基本當(dāng)天發(fā)應(yīng)用市場，當(dāng)天就能夠有更新。但 iOS 需要約 3-4 天來審核。假設(shè)有些功能需要定時(shí)上線，iOS 審核時(shí)間必須要考慮進(jìn)去。

•     用戶升級(jí)周期長。統(tǒng)計(jì)表明，每一個(gè)安卓版本發(fā)布，一周內(nèi)會(huì)有 70% 的用戶更新，一個(gè)月其余用戶才能陸續(xù)完成更新。

移動(dòng)動(dòng)態(tài)化方案共性，有如下三點(diǎn)：

•     跨平臺(tái)。

•     布局。約定 DSL，保證渲染性能。

•     邏輯。Android 和 iOS 必須共用解釋器。

蜂鳥團(tuán)隊(duì)的現(xiàn)狀與業(yè)務(wù)特點(diǎn)

蜂鳥團(tuán)隊(duì)現(xiàn)狀

蜂鳥團(tuán)隊(duì)于 2014 年成立，初衷是為了承接餓了么的物流業(yè)務(wù)。隨著時(shí)間推移，訂單量從每日幾千單到百萬單，配速員也達(dá)到百萬數(shù)量，服務(wù)品類涉及外賣、商超、鮮花、蛋糕、文件等，蜂鳥提供全時(shí)段配送，配送服務(wù)覆蓋全國 1200 多個(gè)城市。

蜂鳥團(tuán)隊(duì)的業(yè)務(wù)特點(diǎn)

蜂鳥團(tuán)隊(duì)的業(yè)務(wù)主要有離散性和突發(fā)性兩大特點(diǎn)，如下圖：

從業(yè)務(wù)曲線可以看到兩個(gè)很明顯的波峰，這是午、晚用餐時(shí)間。同時(shí)，如果運(yùn)營方面配置一些活動(dòng)，會(huì)導(dǎo)致這兩個(gè)波峰徒增。所以，動(dòng)態(tài)方案要想把這兩個(gè)時(shí)間段服務(wù)好，必須要考慮流量陡增下的性能壓力。

蜂鳥團(tuán)隊(duì)的技術(shù)特點(diǎn)和挑戰(zhàn)

蜂鳥團(tuán)隊(duì)的技術(shù)特點(diǎn)和挑戰(zhàn)，我主要分享重度依賴、網(wǎng)絡(luò)環(huán)境復(fù)雜、重度使用和 28 定律這四個(gè)方面。

重度依賴

當(dāng)前蜂鳥有眾包、團(tuán)隊(duì)和送送三部分業(yè)務(wù)，右側(cè)是一些功能展示，如下圖：

這樣的工具型應(yīng)用，需要對 APP 有更強(qiáng)的控制、監(jiān)控等能力。必要時(shí)還要做到強(qiáng)制更新。

對應(yīng)到動(dòng)態(tài)方案的話，控制能力就需要?jiǎng)討B(tài)方案必須具備動(dòng)態(tài)降級(jí)的能力、監(jiān)控能力，實(shí)時(shí)的性能監(jiān)控和業(yè)務(wù)埋點(diǎn)監(jiān)控。強(qiáng)制更新方面，動(dòng)態(tài)方案必須做到用戶無感知的熱更新。

網(wǎng)絡(luò)環(huán)境復(fù)雜

餓了么小哥，每天穿梭在大街小巷、地下商超，他們的網(wǎng)絡(luò)環(huán)境非常不穩(wěn)定。據(jù)統(tǒng)計(jì)，有近 25% 的用戶請求還來自非 4G 環(huán)境。

整體來說的網(wǎng)絡(luò)環(huán)境復(fù)雜、信號(hào)差和 DNS 污染，那么動(dòng)態(tài)方案就要解決 DNS 攔截、弱網(wǎng)環(huán)境下資源下發(fā)等問題。

重度使用

無論是下雨、下雪，還是發(fā)洪水大家都會(huì)叫餓了么。

配送員在高峰期的運(yùn)動(dòng)曲線，如下圖：

面對這樣爭分奪秒的準(zhǔn)時(shí)達(dá)壓力，如果動(dòng)態(tài)方案不給力，會(huì)導(dǎo)致應(yīng)用出現(xiàn)崩潰或卡頓，騎手必定不會(huì)有好的體驗(yàn)，甚至影響送餐時(shí)間。所以我們的動(dòng)態(tài)方案一定要保證性能和穩(wěn)定性。

28定律

相信很多公司的應(yīng)用都符合類似 28 定律，蜂鳥也不例外。

如下圖，蜂鳥的 28 定律：

可以從圖中看出，大部分騎手日常使用的主流層面，可以采用 Native 來開發(fā)，這部分重度使用的占比約 20%，其余 80% 的功能都可以考慮動(dòng)態(tài)化方案（H5）。

蜂鳥團(tuán)隊(duì)的動(dòng)態(tài)化架構(gòu)演進(jìn)

蜂鳥的動(dòng)態(tài)方案經(jīng)過 Hypid、React Native 和 Weex三個(gè)主要階段。

第一階段：Hypid

在 Hypid 方案上，以 H5 的動(dòng)態(tài)性為基礎(chǔ)，通過 Jspidge 做橋梁，與 Native 進(jìn)行通信，之后通過 URL Router 進(jìn)行跳轉(zhuǎn)，架構(gòu)如下圖：

這套動(dòng)態(tài)方案的優(yōu)點(diǎn)顯而易見，這里主要介紹開發(fā)效率、更新體驗(yàn)和跨平臺(tái)三方面：

•     開發(fā)效率。Web 經(jīng)過多年的應(yīng)用實(shí)踐，已經(jīng)擁有完整的開發(fā)流程和開發(fā)工具，開發(fā)一個(gè) H5 頁面非?？焖佟ｉ_發(fā)效率這一因素不能忽略，因?yàn)槌跗诋a(chǎn)品的想法和落地速度會(huì)直接影響產(chǎn)品的命運(yùn)。

•     如蜂鳥送送，初期沒有原生的資源去支撐，就用原生包殼，內(nèi)部全部用 H5，這樣的情況堅(jiān)持了兩月左右，為蜂鳥送送前期的方案驗(yàn)證做了很大的貢獻(xiàn)。

•     更新體驗(yàn)。因 H5 和原生耦合只有擴(kuò)展的 Native API，只要把這些 API 維護(hù)足夠全，開發(fā)的業(yè)務(wù)功能就可以在完全不用更新 APK 的情況下，做到熱更新。且用戶下一次打開應(yīng)用是最新的，這和 Native 的升級(jí)體驗(yàn)相比簡直是一天一地。

• 跨平臺(tái)。之前安卓和 iOS 代碼需要開發(fā)兩次，現(xiàn)在一個(gè)功能決定用 H5 后，由一個(gè)工程師來開發(fā)一套代碼即可。

這套動(dòng)態(tài)方案很大的缺點(diǎn)就是用戶體驗(yàn)差，當(dāng)用 H5 做一些復(fù)雜的功能或動(dòng)畫時(shí)，可能會(huì)卡頓的和 PPT 一樣。因?yàn)?H5 的體驗(yàn)問題，蜂鳥的原則是經(jīng)常更新的且功能不復(fù)雜的頁面會(huì)選擇用 H5。

第二階段：React Native

這個(gè)動(dòng)態(tài)方案完全脫離了以 H5 為基礎(chǔ)的 Hypid 方案，通過自定義 DSL 將 UI 渲染成原生控件，這樣一來， RN 的頁面就保證了原生的體驗(yàn)和 Web 的效率。

除了上一點(diǎn)，還有組件化開發(fā)、復(fù)用率高、Android 和 iOS 95% 的代碼共用和測試效率高等優(yōu)點(diǎn)。

鑒于這些優(yōu)點(diǎn)，蜂鳥在 React Native 上做了很多事情，如 Crash 優(yōu)化、基礎(chǔ)控件沉淀、Bundle+ 圖片熱更新、首屏加載優(yōu)化和 Redux 單項(xiàng)數(shù)據(jù)流等。

正當(dāng)享受 React Native 帶來的開發(fā)體驗(yàn)和應(yīng)用體驗(yàn)提升時(shí)，蜂鳥遇到 RN 的一些痛點(diǎn)，如 ScrollView 性能、Bundle 包過大、很多優(yōu)化都需要修改源碼和 peaking change 等。

第三階段：WEEX

面對如上這些痛點(diǎn)，不知如何應(yīng)對時(shí)，WEEX 來了。官方宣傳的輕量、可擴(kuò)展和高性能等特點(diǎn)，讓蜂鳥團(tuán)隊(duì)眼前一亮。

經(jīng)深入研究后，蜂鳥發(fā)現(xiàn) WEEX 和 React Native 如出一轍，那么為什么要選擇類似的方案呢？

我們隊(duì) WEEX 和 React Native 兩者基于 JS 引擎、語法、數(shù)據(jù)流、性能、開發(fā)體驗(yàn)及熱更新等維度進(jìn)行了對比。

如下圖，是 WEEX 和 React Native JS 引擎對比：

React Native 在安卓和 iOS 使用的都是 JsCore，WEEX 在安卓端使用的是 UC 精簡版 V8。如上圖中的圖表可以看出，V8 相比 JsCore 要?jiǎng)僖换I。

WEEX 和 React Native 語法對比。語法方面，React Native 使用的是 React，WEEX 使用的是 Vue。雖然兩套方案都實(shí)現(xiàn)了如響應(yīng)式，組件化、狀態(tài)管理等功能。

如下圖，是兩者簡單 Demo 的實(shí)踐：

實(shí)踐發(fā)現(xiàn)，WEEX 相比 React Native 要優(yōu)雅一些，是因?yàn)?Vue 有很多自定義標(biāo)簽，當(dāng)在做一些 UI 和邏輯交雜在一起時(shí)，會(huì)讓代碼簡潔很多。

 WEEX 和 React Native 的數(shù)據(jù)流對比，React Native 使用 Redux，而 WEEX 使用 Vuex，不是 WEEX 不能使用 Redux，而是 Vuex 更適合 WEEX。

如下圖，是兩者的數(shù)據(jù)流，大同小異：

但 Vuex 在實(shí)現(xiàn)一些計(jì)算屬性時(shí)，能在更細(xì)的顆粒度去更新 UI，而 Redux 只能實(shí)現(xiàn)到組件的級(jí)別，這樣的點(diǎn)很多的話會(huì)帶來性能上的差異。

如下圖，是 WEEX 和 React Native 的性能對比，左側(cè)是 WEEX 官方給出的與 React Native 在性能方面的對比圖：

在渲染時(shí)間和內(nèi)存占用方面 WEEX 要優(yōu)于 React Native，在 CPU 占用方面兩者相差不大，F(xiàn)PS 上 WEEX 要稍遜于 React Native。

在 ListView Android 方面，React Native 目前采用 ScrollView，WEEX 使用 Recyclerview 實(shí)現(xiàn)，性能稍好。

同時(shí) WEEX 在增強(qiáng)開發(fā)、指定線程、首屏渲染和性能監(jiān)控等方面也做了優(yōu)化。

如下圖，是 WEEX 和 React Native 的開發(fā)體驗(yàn)對比：

和 React Native 相比，WEEX 在打包、監(jiān)控性能、跨平臺(tái)等方面都有一定優(yōu)勢?？傮w來說，React Native 更像是一個(gè)技術(shù)框架，WEEX 更像是一個(gè)業(yè)務(wù)框架。

如下圖，是 WEEX 和 React Native 的熱更新對比：

React Native 與 WEEX 官方都表示支持熱更新，但他們的實(shí)現(xiàn)方式不同。在 React Native 上可通過把圖片打包下發(fā)到本地來實(shí)現(xiàn)更新。

WEEX 有兩個(gè)方法，一是選擇本地資源加載，二是像網(wǎng)頁一樣直接加載頁面。

如下圖，是 React Native 與 WEEX 的對比總結(jié)：

React Native 更像一個(gè)先驅(qū)者，擁有超強(qiáng)的社區(qū)人氣，但也因開源社區(qū)維護(hù)代碼的原因處于一個(gè)野蠻生長的狀態(tài)。而 WEEX 是站在 React Native 的肩膀上，做了各種微創(chuàng)新，實(shí)現(xiàn)更多貼心的小細(xì)節(jié)。

基于 WEEX 性能、穩(wěn)定性等方面都比 React Native 高，蜂鳥決定把動(dòng)態(tài)化方案往 WEEX 上遷移，雖然它現(xiàn)在還有不足，有些輪子還是要自己去做。

蜂鳥團(tuán)隊(duì) WEEX 實(shí)踐

憑借之前 React Native 相關(guān)的實(shí)踐經(jīng)驗(yàn)，基于 WEEX 做了一套更完整的動(dòng)態(tài)方案。涉及以下幾個(gè)方面，如下圖：

統(tǒng)一的pidge 

在 Android & iOS 端，約定相同的方法名、參數(shù)，在 JS 層抹平平臺(tái)差異以及統(tǒng)一分類管理暴露給業(yè)務(wù)的 API。

把這樣的統(tǒng)一 pidge 方案提供給業(yè)務(wù)部門，他們只需關(guān)心暴露的 API，而不需要關(guān)心下一層平臺(tái)的兼容，大大提升開發(fā)效率。

加載更新策略

加載更新方面，我們約定了一套自有協(xié)議，有 Page、URL 和 Tag，通過封裝的 Router，就可以做到頁面級(jí)的跳轉(zhuǎn)。

這樣一來，我們很輕松地做到了頁面的跳轉(zhuǎn)、解耦和頁面的降級(jí)。當(dāng)頁面出現(xiàn)問題，只需要把 URL 改成降級(jí)之后的 H5 頁面下發(fā)即可，用戶觸及到的就是修復(fù)之后的 H5 頁面了。

如下圖，是預(yù)加載策略：

當(dāng) H5 頁面下發(fā)到客戶端之后，會(huì)對本地資源進(jìn)行檢查，如果有 JS 文件，就忽略，沒有的話就把頁面下載。當(dāng)用戶打開頁面，再去看本地，存在資源的話直接加載，不存在的話就即時(shí)下載再運(yùn)行，與傳統(tǒng)的 Web 流程相似。

性能監(jiān)控

性能監(jiān)控用來判斷線上服務(wù)是否正常，是整套方案最重要的部分。

WEEX 可以很方便地將所有的參數(shù)全部拿到且通過反射拿到所有的性能數(shù)據(jù)傳到云端。

基于這些數(shù)據(jù)，我們就可以知道線上有了哪些頁面，它的渲染是否有問題?；谶@些問題，就可做相應(yīng)的優(yōu)化。

如下圖，是線上的數(shù)據(jù)情況：

監(jiān)控三個(gè)指標(biāo)，分別是 JS 引擎的初始化時(shí)間、頁面打開時(shí)間和網(wǎng)絡(luò)時(shí)間。因大部分 WEEX 頁面都是業(yè)務(wù)，所以說業(yè)務(wù)埋點(diǎn)必不可少。餓了么也實(shí)現(xiàn)了一套框架，將業(yè)務(wù)埋點(diǎn)傳給服務(wù)端，然后方便產(chǎn)品去制定一些產(chǎn)品方面的策略。

JS 的錯(cuò)誤統(tǒng)計(jì)

可以捕捉 JS 端拋出的錯(cuò)誤，如果所處團(tuán)隊(duì)是前端主導(dǎo)，可傳給前端。如果是 Native 主導(dǎo)，可通過搜集平臺(tái)將這些崩潰上傳，在后臺(tái)看到這些錯(cuò)誤之后，找到相應(yīng)的代碼去修復(fù)。

Native 的錯(cuò)誤

有了 JS 錯(cuò)誤，Native 錯(cuò)誤也不能忽略。

如下圖，是 WEEX 動(dòng)態(tài)方案上線一周之后線上拋的錯(cuò)誤：

從圖中可以看到都是個(gè)位數(shù)，這一點(diǎn)其實(shí)當(dāng)時(shí)也很驚訝，WEEX 確實(shí)做得很穩(wěn)定，這一點(diǎn)超出預(yù)料。

共用組件和 API

之前蜂鳥在 React Native 上面的一些實(shí)踐，積累了一些很常用的組件和 API。WEEX 和 React Native 都是使用 JS 實(shí)現(xiàn)，所以我們很方便的將 RN 的控件轉(zhuǎn)化為 WEEX 控件。

如下圖，是實(shí)現(xiàn)的組件和 API，幾乎可以滿足中小團(tuán)隊(duì)的日常使用：

調(diào)試工具

這方面 WEEX 做的很貼心，雖然沒有整合到整個(gè)初始化的項(xiàng)目中，但開源了幾個(gè)庫，可把代碼拷貝到業(yè)務(wù)中進(jìn)行使用。

WEEX 還可支持 Debug 模式顯示調(diào)試工具、支持 hot reload、方便的查看性能指標(biāo)和 Shell 腳本一鍵打包等功能。

綜上所述，基于這些維度實(shí)現(xiàn)的框架，可以方便的讓業(yè)務(wù)來使用。

如下，是餓了么和蜂鳥用 WEEX 實(shí)現(xiàn)的兩個(gè)頁面：

餓了么的第二個(gè)發(fā)現(xiàn)頁面，就是基于 WEEX。蜂鳥 APP 可能大家接觸不到，上圖是當(dāng)前通知的活動(dòng)界面，還有大量的新功能正在接入。

如果你正在考慮 WEEX 與 React Native 方案，或是正在接入 React Native?？吹竭@篇文章，你可以去調(diào)研以下 WEEX 方案，可能你會(huì)有另一種選擇。

以上內(nèi)容根據(jù)許錦洋老師在 WOTA2017 “移動(dòng)端架構(gòu)演進(jìn)”專場的演講內(nèi)容整理。

負(fù)責(zé)餓了么蜂鳥 APP 的架構(gòu)、研發(fā)等工作。擁有餓了么商家、風(fēng)行者、蜂鳥眾包等多款 APP 開發(fā)工作經(jīng)歷，并從 0 開始架構(gòu)和開發(fā)了整個(gè)蜂鳥團(tuán)隊(duì) APP。目前關(guān)注的技術(shù)方向?yàn)橐苿?dòng)跨平臺(tái)技術(shù)方案、移動(dòng)端架構(gòu)、移動(dòng)端性能優(yōu)化等。

本文題目：移動(dòng)動(dòng)態(tài)化方案在蜂鳥的架構(gòu)演進(jìn)（含ReactNative與Weex對比）
轉(zhuǎn)載來源：http://muchs.cn/article48/ihcshp.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供小程序開發(fā)、建站公司、品牌網(wǎng)站設(shè)計(jì)、微信公眾號(hào)、用戶體驗(yàn)、電子商務(wù)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)