建站
咨詢
售后
建站咨詢
新聞中心
【稿件】當下，移動動態(tài)化已經(jīng)成為各大公司都回避不了的問題，產(chǎn)品的快速迭代對技術(shù)提出了更高的要求，而移動端的動態(tài)化方案也是層出不窮：Hypid、結(jié)構(gòu)化 Native View、React Native、Weex，什么樣的方案才是適合自己團隊的呢？本文將分享餓了么蜂鳥團隊在過去兩年多業(yè)務(wù)快速增長過程中，移動動態(tài)化方面的實踐和探索。
站在用戶的角度思考問題，與客戶深入溝通，找到泰州網(wǎng)站設(shè)計與泰州網(wǎng)站推廣的解決方案，憑借多年的經(jīng)驗，讓設(shè)計與互聯(lián)網(wǎng)技術(shù)結(jié)合，創(chuàng)造個性化、用戶體驗好的作品，建站類型包括：成都網(wǎng)站制作、成都網(wǎng)站設(shè)計、企業(yè)官網(wǎng)、英文網(wǎng)站、手機端網(wǎng)站、網(wǎng)站推廣、域名注冊、網(wǎng)絡(luò)空間、企業(yè)郵箱。業(yè)務(wù)覆蓋泰州地區(qū)。
什么是移動動態(tài)化？
移動指的是移動端，包括安卓、iOS。動態(tài)化則是動態(tài)部署和邏輯下發(fā)到客戶端的能力。移動動態(tài)最好的狀態(tài)就是讓移動應(yīng)用和 Web 一樣，想發(fā)就發(fā)！
為什么移動端要強調(diào)動態(tài)化的能力？
原因有如下三大點：
- 業(yè)務(wù)迭代太快。當下大部分團隊都是敏捷開發(fā)的模式，即使兩周做一次迭代，產(chǎn)品周期還是會覺得長，有些應(yīng)用不能及時上線。
- 應(yīng)用市場審核慢。安卓基本當天發(fā)應(yīng)用市場，當天就能夠有更新。但 iOS 需要約 3-4 天來審核。假設(shè)有些功能需要定時上線，iOS 審核時間必須要考慮進去。
- 用戶升級周期長。統(tǒng)計表明，每一個安卓版本發(fā)布，一周內(nèi)會有 70% 的用戶更新，一個月其余用戶才能陸續(xù)完成更新。
移動動態(tài)化方案共性，有如下三點：
- 跨平臺。
- 布局。約定 DSL，保證渲染性能。
- 邏輯。Android 和 iOS 必須共用解釋器。
蜂鳥團隊的現(xiàn)狀與業(yè)務(wù)特點
蜂鳥團隊現(xiàn)狀
蜂鳥團隊于 2014 年成立，初衷是為了承接餓了么的物流業(yè)務(wù)。隨著時間推移，訂單量從每日幾千單到百萬單，配速員也達到百萬數(shù)量，服務(wù)品類涉及外賣、商超、鮮花、蛋糕、文件等，蜂鳥提供全時段配送，配送服務(wù)覆蓋全國 1200 多個城市。
蜂鳥團隊的業(yè)務(wù)特點
蜂鳥團隊的業(yè)務(wù)主要有離散性和突發(fā)性兩大特點，如下圖：
從業(yè)務(wù)曲線可以看到兩個很明顯的波峰，這是午、晚用餐時間。同時，如果運營方面配置一些活動，會導(dǎo)致這兩個波峰徒增。所以，動態(tài)方案要想把這兩個時間段服務(wù)好，必須要考慮流量陡增下的性能壓力。
蜂鳥團隊的技術(shù)特點和挑戰(zhàn)
蜂鳥團隊的技術(shù)特點和挑戰(zhàn)，我主要分享重度依賴、網(wǎng)絡(luò)環(huán)境復(fù)雜、重度使用和 28 定律這四個方面。
重度依賴
當前蜂鳥有眾包、團隊和送送三部分業(yè)務(wù)，右側(cè)是一些功能展示，如下圖：
這樣的工具型應(yīng)用，需要對 APP 有更強的控制、監(jiān)控等能力。必要時還要做到強制更新。
對應(yīng)到動態(tài)方案的話，控制能力就需要動態(tài)方案必須具備動態(tài)降級的能力、監(jiān)控能力，實時的性能監(jiān)控和業(yè)務(wù)埋點監(jiān)控。強制更新方面，動態(tài)方案必須做到用戶無感知的熱更新。
網(wǎng)絡(luò)環(huán)境復(fù)雜
餓了么小哥，每天穿梭在大街小巷、地下商超，他們的網(wǎng)絡(luò)環(huán)境非常不穩(wěn)定。據(jù)統(tǒng)計，有近 25% 的用戶請求還來自非 4G 環(huán)境。
整體來說的網(wǎng)絡(luò)環(huán)境復(fù)雜、信號差和 DNS 污染，那么動態(tài)方案就要解決 DNS 攔截、弱網(wǎng)環(huán)境下資源下發(fā)等問題。
重度使用
無論是下雨、下雪，還是發(fā)洪水大家都會叫餓了么。
配送員在高峰期的運動曲線，如下圖：
面對這樣爭分奪秒的準時達壓力，如果動態(tài)方案不給力，會導(dǎo)致應(yīng)用出現(xiàn)崩潰或卡頓，騎手必定不會有好的體驗，甚至影響送餐時間。所以我們的動態(tài)方案一定要保證性能和穩(wěn)定性。
28定律
相信很多公司的應(yīng)用都符合類似 28 定律，蜂鳥也不例外。
如下圖，蜂鳥的 28 定律：
可以從圖中看出，大部分騎手日常使用的主流層面，可以采用 Native 來開發(fā)，這部分重度使用的占比約 20%，其余 80% 的功能都可以考慮動態(tài)化方案（H5）。
蜂鳥團隊的動態(tài)化架構(gòu)演進
蜂鳥的動態(tài)方案經(jīng)過 Hypid、React Native 和 Weex 三個主要階段。
第一階段：Hypid
在 Hypid 方案上，以 H5 的動態(tài)性為基礎(chǔ)，通過 Jspidge 做橋梁，與 Native 進行通信，之后通過 URL Router 進行跳轉(zhuǎn)，架構(gòu)如下圖：
這套動態(tài)方案的優(yōu)點顯而易見，這里主要介紹開發(fā)效率、更新體驗和跨平臺三方面：
- 開發(fā)效率。Web 經(jīng)過多年的應(yīng)用實踐，已經(jīng)擁有完整的開發(fā)流程和開發(fā)工具，開發(fā)一個 H5 頁面非?？焖佟ｉ_發(fā)效率這一因素不能忽略，因為初期產(chǎn)品的想法和落地速度會直接影響產(chǎn)品的命運。
- 如蜂鳥送送，初期沒有原生的資源去支撐，就用原生包殼，內(nèi)部全部用 H5，這樣的情況堅持了兩月左右，為蜂鳥送送前期的方案驗證做了很大的貢獻。
- 更新體驗。因 H5 和原生耦合只有擴展的 Native API，只要把這些 API 維護足夠全，開發(fā)的業(yè)務(wù)功能就可以在完全不用更新 APK 的情況下，做到熱更新。且用戶下一次打開應(yīng)用是最新的，這和 Native 的升級體驗相比簡直是一天一地。
- 跨平臺。之前安卓和 iOS 代碼需要開發(fā)兩次，現(xiàn)在一個功能決定用 H5 后，由一個工程師來開發(fā)一套代碼即可。
這套動態(tài)方案很大的缺點就是用戶體驗差，當用 H5 做一些復(fù)雜的功能或動畫時，可能會卡頓的和 PPT 一樣。因為 H5 的體驗問題，蜂鳥的原則是經(jīng)常更新的且功能不復(fù)雜的頁面會選擇用 H5。
第二階段：React Native
這個動態(tài)方案完全脫離了以 H5 為基礎(chǔ)的 Hypid 方案，通過自定義 DSL 將 UI 渲染成原生控件，這樣一來， RN 的頁面就保證了原生的體驗和 Web 的效率。
除了上一點，還有組件化開發(fā)、復(fù)用率高、Android 和 iOS 95% 的代碼共用和測試效率高等優(yōu)點。
鑒于這些優(yōu)點，蜂鳥在 React Native 上做了很多事情，如 Crash 優(yōu)化、基礎(chǔ)控件沉淀、Bundle+ 圖片熱更新、首屏加載優(yōu)化和 Redux 單項數(shù)據(jù)流等。
正當享受 React Native 帶來的開發(fā)體驗和應(yīng)用體驗提升時，蜂鳥遇到 RN 的一些痛點，如 ScrollView 性能、Bundle 包過大、很多優(yōu)化都需要修改源碼和 peaking change 等。
第三階段：WEEX
面對如上這些痛點，不知如何應(yīng)對時，WEEX 來了。官方宣傳的輕量、可擴展和高性能等特點，讓蜂鳥團隊眼前一亮。
經(jīng)深入研究后，蜂鳥發(fā)現(xiàn) WEEX 和 React Native 如出一轍，那么為什么要選擇類似的方案呢？
我們隊 WEEX 和 React Native 兩者基于 JS 引擎、語法、數(shù)據(jù)流、性能、開發(fā)體驗及熱更新等維度進行了對比。
如下圖，是 WEEX 和 React Native JS 引擎對比：
React Native 在安卓和 iOS 使用的都是 JsCore，WEEX 在安卓端使用的是 UC 精簡版 V8。如上圖中的圖表可以看出，V8 相比 JsCore 要勝一籌。
WEEX 和 React Native 語法對比。語法方面，React Native 使用的是 React，WEEX 使用的是 Vue。雖然兩套方案都實現(xiàn)了如響應(yīng)式，組件化、狀態(tài)管理等功能。
如下圖，是兩者簡單 Demo 的實踐：
實踐發(fā)現(xiàn)，WEEX 相比 React Native 要優(yōu)雅一些，是因為 Vue 有很多自定義標簽，當在做一些 UI 和邏輯交雜在一起時，會讓代碼簡潔很多。
WEEX 和 React Native 的數(shù)據(jù)流對比，React Native 使用 Redux，而 WEEX 使用 Vuex，不是 WEEX 不能使用 Redux，而是 Vuex 更適合 WEEX。
如下圖，是兩者的數(shù)據(jù)流，大同小異：
但 Vuex 在實現(xiàn)一些計算屬性時，能在更細的顆粒度去更新 UI，而 Redux 只能實現(xiàn)到組件的級別，這樣的點很多的話會帶來性能上的差異。
如下圖，是 WEEX 和 React Native 的性能對比，左側(cè)是 WEEX 官方給出的與 React Native 在性能方面的對比圖：
在渲染時間和內(nèi)存占用方面 WEEX 要優(yōu)于 React Native，在 CPU 占用方面兩者相差不大，F(xiàn)PS 上 WEEX 要稍遜于 React Native。
在 ListView Android 方面，React Native 目前采用 ScrollView，WEEX 使用 Recyclerview 實現(xiàn)，性能稍好。
同時 WEEX 在增強開發(fā)、指定線程、首屏渲染和性能監(jiān)控等方面也做了優(yōu)化。
如下圖，是 WEEX 和 React Native 的開發(fā)體驗對比：
和 React Native 相比，WEEX 在打包、監(jiān)控性能、跨平臺等方面都有一定優(yōu)勢?？傮w來說，React Native 更像是一個技術(shù)框架，WEEX 更像是一個業(yè)務(wù)框架。
如下圖，是 WEEX 和 React Native 的熱更新對比：
React Native 與 WEEX 官方都表示支持熱更新，但他們的實現(xiàn)方式不同。在 React Native 上可通過把圖片打包下發(fā)到本地來實現(xiàn)更新。
WEEX 有兩個方法，一是選擇本地資源加載，二是像網(wǎng)頁一樣直接加載頁面。
如下圖，是 React Native 與 WEEX 的對比總結(jié)：
React Native 更像一個先驅(qū)者，擁有超強的社區(qū)人氣，但也因開源社區(qū)維護代碼的原因處于一個野蠻生長的狀態(tài)。而 WEEX 是站在 React Native 的肩膀上，做了各種微創(chuàng)新，實現(xiàn)更多貼心的小細節(jié)。
基于 WEEX 性能、穩(wěn)定性等方面都比 React Native 高，蜂鳥決定把動態(tài)化方案往 WEEX 上遷移，雖然它現(xiàn)在還有不足，有些輪子還是要自己去做。
蜂鳥團隊 WEEX 實踐
憑借之前 React Native 相關(guān)的實踐經(jīng)驗，基于 WEEX 做了一套更完整的動態(tài)方案。涉及以下幾個方面，如下圖：
統(tǒng)一的pidge
在 Android & iOS 端，約定相同的方法名、參數(shù)，在 JS 層抹平平臺差異以及統(tǒng)一分類管理暴露給業(yè)務(wù)的 API。
把這樣的統(tǒng)一 pidge 方案提供給業(yè)務(wù)部門，他們只需關(guān)心暴露的 API，而不需要關(guān)心下一層平臺的兼容，大大提升開發(fā)效率。
加載更新策略
加載更新方面，我們約定了一套自有協(xié)議，有 Page、URL 和 Tag，通過封裝的 Router，就可以做到頁面級的跳轉(zhuǎn)。
這樣一來，我們很輕松地做到了頁面的跳轉(zhuǎn)、解耦和頁面的降級。當頁面出現(xiàn)問題，只需要把 URL 改成降級之后的 H5 頁面下發(fā)即可，用戶觸及到的就是修復(fù)之后的 H5 頁面了。
如下圖，是預(yù)加載策略：
當 H5 頁面下發(fā)到客戶端之后，會對本地資源進行檢查，如果有 JS 文件，就忽略，沒有的話就把頁面下載。當用戶打開頁面，再去看本地，存在資源的話直接加載，不存在的話就即時下載再運行，與傳統(tǒng)的 Web 流程相似。
性能監(jiān)控
性能監(jiān)控用來判斷線上服務(wù)是否正常，是整套方案最重要的部分。
WEEX 可以很方便地將所有的參數(shù)全部拿到且通過反射拿到所有的性能數(shù)據(jù)傳到云端。
基于這些數(shù)據(jù)，我們就可以知道線上有了哪些頁面，它的渲染是否有問題?；谶@些問題，就可做相應(yīng)的優(yōu)化。
如下圖，是線上的數(shù)據(jù)情況：
監(jiān)控三個指標，分別是 JS 引擎的初始化時間、頁面打開時間和網(wǎng)絡(luò)時間。因大部分 WEEX 頁面都是業(yè)務(wù)，所以說業(yè)務(wù)埋點必不可少。餓了么也實現(xiàn)了一套框架，將業(yè)務(wù)埋點傳給服務(wù)端，然后方便產(chǎn)品去制定一些產(chǎn)品方面的策略。
JS 的錯誤統(tǒng)計
可以捕捉 JS 端拋出的錯誤，如果所處團隊是前端主導(dǎo)，可傳給前端。如果是 Native 主導(dǎo)，可通過搜集平臺將這些崩潰上傳，在后臺看到這些錯誤之后，找到相應(yīng)的代碼去修復(fù)。
Native 的錯誤
有了 JS 錯誤，Native 錯誤也不能忽略。
如下圖，是 WEEX 動態(tài)方案上線一周之后線上拋的錯誤：
從圖中可以看到都是個位數(shù)，這一點其實當時也很驚訝，WEEX 確實做得很穩(wěn)定，這一點超出預(yù)料。
共用組件和 API
之前蜂鳥在 React Native 上面的一些實踐，積累了一些很常用的組件和 API。WEEX 和 React Native 都是使用 JS 實現(xiàn)，所以我們很方便的將 RN 的控件轉(zhuǎn)化為 WEEX 控件。
如下圖，是實現(xiàn)的組件和 API，幾乎可以滿足中小團隊的日常使用：
調(diào)試工具
這方面 WEEX 做的很貼心，雖然沒有整合到整個初始化的項目中，但開源了幾個庫，可把代碼拷貝到業(yè)務(wù)中進行使用。
WEEX 還可支持 Debug 模式顯示調(diào)試工具、支持 hot reload、方便的查看性能指標和 Shell 腳本一鍵打包等功能。
綜上所述，基于這些維度實現(xiàn)的框架，可以方便的讓業(yè)務(wù)來使用。
如下，是餓了么和蜂鳥用 WEEX 實現(xiàn)的兩個頁面：
餓了么的第二個發(fā)現(xiàn)頁面，就是基于 WEEX。蜂鳥 APP 可能大家接觸不到，上圖是當前通知的活動界面，還有大量的新功能正在接入。
如果你正在考慮 WEEX 與 React Native 方案，或是正在接入 React Native?？吹竭@篇文章，你可以去調(diào)研以下 WEEX 方案，可能你會有另一種選擇。
以上內(nèi)容根據(jù)許錦洋老師在 WOTA2017 “移動端架構(gòu)演進”專場的演講內(nèi)容整理。
負責餓了么蜂鳥 APP 的架構(gòu)、研發(fā)等工作。擁有餓了么商家、風行者、蜂鳥眾包等多款 APP 開發(fā)工作經(jīng)歷，并從 0 開始架構(gòu)和開發(fā)了整個蜂鳥團隊 APP。目前關(guān)注的技術(shù)方向為移動跨平臺技術(shù)方案、移動端架構(gòu)、移動端性能優(yōu)化等。
【原創(chuàng)稿件，合作站點轉(zhuǎn)載請注明原文作者和出處為.com】
本文題目：移動動態(tài)化方案在蜂鳥的架構(gòu)演進（含ReactNative與Weex對比）
標題網(wǎng)址：http://www.dlmjj.cn/article/djopdcg.html
