百度外賣移動組件架構與優化

百度外賣移動組件架構與優化

寫在前面：

  本文內容是餓了麼技術沙龍20期：移動技術專場《百度外賣移動組件架構與優化》張朝@百度外賣Android高級開發工程師演講分享，本文Github連接

分享內容

1、跨平臺動態組件方案
2、外賣移動組件架構設計
3、組件業務流程生態
4、組件性能優化實踐
5、將來規劃

1、跨平臺動態組件方案

1.1 三類動態組件方案

Native原⽣生組件：

一、性能、體驗很是好
二、開發成本高
三、沒法跨平臺，傳播性差
四、可能的審覈風險

Hybrid組件：

一、徹底跨平臺，易於傳播
二、迭代效率很是高
三、性能、體驗較差
四、端能力依賴發版

JS驅動原生：

一、性能、體驗很是好
二、迭代效率較高
三、學習與開發成本較高
四、穩定性較差

2、外賣移動組件架構設計

2.1 早期業務背景與架構

一、主業務與垂類業務同時快速迭代  
二、缺乏平臺化與模塊化的支撐
三、H5垂類業務井噴式發展（各種H5對端能力需求不一樣，發散不收斂，通訊方式不統一，協議混亂）
四、模塊耦合嚴重，新業務沒法快速上線

2.2 移動組件—通訊樞紐

JS -> Native

一、API層最終經過kernel發起通訊
二、WMApp.kernel.invoke(action, params, callback)
三、invoke內建立iframe向Native發送消息
四、Android可採用addJSInterface，iOS原生支持，不通用

Native -> JS

一、Native執行WMAppBridge函數，listener需提早註冊
二、WMAppBridge.notify(callback,data)
三、WMAppBridge.notifyListener(name, data)

2.3 傳統頁面加載流程

2.4 移動組件—離線化機制

一、離線包內置Config配置離線頁面屬性：本地文件相對路徑、預加載開關等
二、基於MD5 Check的離線包更新與安裝
三、invoke內建立iframe向Native發送消息
四、file://跨域問題，需Bridge提供網絡請求能力
五、是否支持多版本管、是否內置默認包，由業務特徵決定
六、頁面啓動由外賣OpenUrl支持，保證靈活性與一致性

2.5 移動組件—本地目錄

3、組件業務流程生態

3.1 業務接入與迭代流程

3.2 重要平臺搭建

組件發佈管理平臺、組件性能監控平臺、組件異常監控平臺

4、組件性能—網絡優化

4.1 網絡請求預加載

Total Time：T1 + T2 + T3 + T4，串行化
網絡請求T3與WebView加載流程較獨立，可經過Native前置發起實現並化

Total Time：Max ( T1 + T2, T3 ) + T4，並行化，時長縮減約300ms - 800ms

4.2 預加載配置

一、預約義的請求配置規則，對組件Config擴充request節點（網絡請求基本配置：url、method、contentType、data、header等）
二、Native完成動態參數的替換，生成網絡請求併發出（經常使用的動態參數：lat、lng、os、addressId等）
三、業務組件可動態開啓/關閉預加載，靈活降級

4.3 網絡鏈接優化

一、組件⽹網絡請求由Native發起，更高效率且可掌控
二、基於OkHttp，默認具有Gzip、ConnectionPool等優點
三、基於百度DNS服務的WMHttpDNS，防劫持，更高的穩定性與性能
四、Native級別更細粒度的接口性能與異常監控（APM）
五、低成本的https/http2.0切換

5、組件性能—容器預熱

5.1 組件容器預熱

一、Total Time：Max ( T1 + T2, T3 ) + T4，大部分狀況下，T1 + T2 > T3 
二、離線化機制已經使T2儘量下降，T1成瓶頸（Android尤其明顯）
三、Android初次建立WebView，開銷很大（時長高達500ms - 1000ms）
四、非初次建立，開銷會下降（時長約100ms - 500ms）
五、ApplicationContext進行容器預建立，啓動後context替換成Activity

不建議作WebView容器複用，需作DOM清理，避免JS Context污染

6、組件其餘優化

6.1 組件I/O優化

一、頻繁I/O性能開銷較大，下降穩定性
二、JSBridge-Cache，下降注入開銷
三、PageConfig-Map，下降I/O次數，快速定位文件位置

6.2 安全性

安全性問題，域名過濾+沙盒目錄校驗。控制敏感信息讀取權限，避免第三方頁面隱私泄露， 控制File、Content讀取權限，避免File域攻擊（跨域高危漏洞）

7、將來規劃

7.1 離線包體積與實時性

一、採用7zip壓縮技術，更高的壓縮率
二、對用戶流量與成本作更深評估，引入Diff增量包支持
三、在主動拉取包更新的基礎上，引入Push實時推包機制

7.2 性能與安全性

一、更細粒度的頁面性能監控
二、更深刻的網絡優化（性能與成功率）
三、更全面的安全性控制（離線包簽名與認證，避免惡意篡改）

## 最後

  不知不覺，本身已在前端兩年摸爬滾打兩年了，講前端成長，我認爲主要在兩個方面，一部分是能力，一部分是知識。我我的的觀點，能力佔百分之八十，知識佔百分之二十。聯想起魯迅先生的《朝花夕拾》，因而乎我從今年6月底開始用docsify搭建了幾個文檔網站在個人github裏開始編寫《前端筆記系列》(注：有參考[nieyafei]，我把它們分爲四類：[【Html/Css/Sass/Less/瀏覽器/網絡】]()、【JavaScript/數據結構/算法】、【Vue/React/Angular/Node】、【微信/小程序】。它們記錄分享我眼中的前端相關零碎知識、原理、源碼、技巧、麪包、前端會議沙龍筆記...目前只編寫了【Html/Css/Sass/Less/瀏覽器/網絡】，後面的三節會陸陸續續持續更新...
  本文記錄在【Html/Css/Sass/Less/瀏覽器/網絡】行業會議 裏，若是有幫助到你，賞個★star。