Weex 在餓了麼前端的實踐

內容來源：2017年4月8日，餓了麼前端資深工程師在「第二屆中國前端開發者大會-高效前端開發實踐和創新」進行《Weex 在餓了麼前端的實踐》演講分享。IT大咖說做爲獨家視頻合做方，經主辦方和講者審閱受權發佈。
閱讀字數：1888 | 3分鐘閱讀

摘要

Weex方案輕量，高性能，可擴展的特性可以提高餓了麼一些業務的體驗。於是咱們作了些嘗試和積累，給你們分享餓了麼在 Weex方面的開發，文檔，緩存，監控相關的經驗。

嘉賓演講視頻及PPT地址：t.cn/R0wvUjj

餓了麼前端場景

大量的在WebView中使用頁面，Vue開發者多於React開發者。頁面中和店鋪頁面、活動頁面相關的比較多，並且活動更新會比店鋪更新多一點。

移動端業務中大多追求頁面的輕量與流暢，HTML5的性能瓶頸爲人詬病已久，最爲明顯的問題是加載性能。

React Native?

在「蜂鳥配送」等APP中使用React Native來快速更新APP，積累經驗。

對於咱們的場景來講，React Native的列表佔用內存過大，沒有複用機制，會佔用愈來愈多的資源。

ReactNative不一樣版本之間的breaking change太多，後期維護成本太高，並不適用於餓了麼這個體量的APP。

Weex

Weex的構架主要是有一個JavaScript Runtime，底層是iOS、Andriod和H5的渲染引擎，經過JavaScript Runtime和Native渲染引擎之間發生事件進行通訊。

上層是JS Bundle，經過webpack打包出來的JavaScript代碼。在前面開發者編寫的主要是Vue語法。

Weex是一套構建高性能、可擴展的原生應用跨平臺開發方案。它的特色是輕量、可擴展和高性能。

Weex的體積小、語法簡單、易於掌握是經過Vue來達成的。還能夠利用Native代碼經過編寫Native組件在JavaScript中調用擴展定製原生組件和功能。加載時間和資源佔用的深度優化對listview的優化和啓動頁面的速度會比較明顯，總體來講它的體驗會相對來講好一些。

開發Weex頁面

咱們通過一些探索後開始嘗試把原來用H5作的一個WebView頁面替換成Weex頁面。

Weex試驗頁面

Weex的頁面相對來講簡單一些，交互量比較少，訪問量大，便於咱們收集反饋。由於這個頁面原來是基於Vue寫的，遷移比較方便。

具體工做

業務的實現：基於Vue版本，投入一我的，用時3天左右。

Weex的報錯和性能監控：前端和APP方配合，大概須要兩週左右。

Weex的降級策略：這個是咱們和APP方討論後得出降級方案，主要由APP方來實現。

當時整個過程從立項到上線大概花了三週的時間。從效果來看，發現頁的Weex版本性能很是優異，相對原來H5版本，頁面打開速度變得很是快。後面咱們也有計劃逐步接入更多頁面。

Weex開發體驗

由於Weex是基於Web技術，學習門檻相對原生開發要低不少。

Weex僅有Flexbox佈局，text沒法嵌套，難以實現長文當中樣式的混合。

NoCookies.只能用storage來完成對應信息的存儲。

三端一致性不徹底，特別是HTML5支持不完善。

CSS和Web當中存在差別。

DevTools的成熟度不夠，熱替換不夠強大。

相對Web而言組件的豐富度不夠。

整體的來講就是Weex有不少Web開發中的習慣，但在不少方面只是支持了一些子集或本身強化過的部分。

Weex頁面性能

{ 「JSLibInitTime」：「157」, 「JSTemplateSize」：「65」, 「SDKInitInvokeTime」：「7」, 「SDKInitTime」：「231」, 「communicateTime」：「146」, 「networkTime」：「0」, 「totalTime」：「184」, 「fromCache」：true }

SDKInitInvokeTime也是SDK初始化方法調用時間，初始化時是異步進行的，因此SDKInitTime會比較大。

SDKInitTime是SDK啓動初始化時間，應該是一次性的開銷，不是每一個Weex instance的開銷，第一次啓動執行。

communicateTime是Weex實例的建立時間，如今的用法每次新建頁面都會建立新的實例。

screenRenderTime是首屏渲染時間。

TotalTime是完整渲染時間。

NetworkTime網絡消耗時間（本身實現）。

FromCache代碼是否來自緩存（本身實現）。

在Android平臺上渲染時間大體在450ms，在iOS上的性能更好一些，頁面也相對簡單，渲染時間只須要160ms。

降級方案

咱們的降級方案是在APP裏進行控制的。咱們會給一個APP提供一個配置文件，而後它根據這個配置文件決定這個頁面是否經過Weex來顯示。

爲了保證不影響用戶的使用，咱們採起的灰度策略是在支持Weex的APP灰度發版以後，咱們在業務低峯期的時候開啓這個開關。

經過咱們接入的監控平臺，，咱們能夠及時對Weex頁面的錯誤進行監控，若是出現大規模報錯，則會當即把支持Weex的開關關閉。

開關配置文件

{  「url」： 「https://www.example.com/discover/index.html」, 「weex-url」：「https://www.example.com/discover/weex.js」,  「weex-enabled」：true,  「weex-minimal-version」：「0.8.0」 }

url：Windows使用的Web頁面的地址，當weex-enabled爲false的時候，會使用這個地址打開一個WebView。

Weex-url：Weex資源所在的位置，正常狀況下使用此URL下載Weex使用的JavaScript文件。

Weex-enabled：boolean類型，默認爲false，當此屬性爲true的時候，纔會使用weex-url加載一個WeexView。

Weex-minimal-version：字符串類型，表明了加載weex-url須要使用的Weex的最低版本，此屬性必填，若是不填則weex-enabled不生效。當APP中的Weex SDK版本比這個版本低的時候，則會fallback到WebView的形式。

Weex的版本兼容性優異，咱們從0.8.0升級到0.10.0的過程當中，尚未出現須要降級的狀況。

在學習成本上，React Native比H5和Weex要高；

測試方面，React Native和Weex的弱交互性能比較好。可是在強交互方面，React Native性能最佳；H5能實現，性能差；Weex則還存在一些相對較弱的方面，部分拖動的相關效果沒法實現。

ReactNative在兼容性方面並無那麼好。

使用React Native須要熟悉React全家桶，這個學習成本比Vue高很多。

Github上有一個用React Native高仿Eleme APP的實現，大部分效果都能實現；基於咱們對Weex的理解，Weex實現拖動部分交互很是困難，甚至目前的版本不可能實現。

關於React Native的Breaking Changes，能夠經過Google搜索「React Native放棄」，能夠搜到大量的文章。

從咱們的實踐上看，Weex運行穩定，性能優異，在作好監控降級機制以後，能夠放心的投入到生產。

我今天的分享就到這裏，感謝聆聽！

推薦文章

• 面向前端開發者的V8性能優化
  

• 百度外賣如何作到前端開發配置化
  

近期活動

• 直播 | 博學實踐日：DevOps與高可用架構最佳實踐之路
  

• 直播 | LiveVideoStackCon 2017 音視頻技術大趴就要開始了

• 直播 | 將來密碼——從互聯網傳輸協議到後量子時代的密碼學

• 直播 | 滬江技術沙龍 - 不斷演變的架構實踐