移動端的混合架構模式給 App 開發帶來了嶄新的空間，通過 H5 建構的業務子產品可以實作高效快速的版本疊代，滿足多樣化的業務需求。為了彌補 H5 技術的部分性能不足，mPaaS 用戶端架構為開發者提供了“離線”機制。開發者在接入 mPaaS H5 容器後，配合 mPaaS 移動釋出服務，可以讓用戶端友善地從本地加載 H5 業務包，極大地提升了 H5 應用的加載效率。需要注意的是，這套離線機制的接入過程必須要嚴格按照文檔來進行，一些細微的錯誤可能導緻離線機制失敗，給 H5 應用的加載性能帶來影響。這篇文章将和大家分享一例由離線包重構引起的“白屏”等待現象的排查和解決。
1. 問題背景
我們（阿裡雲金融線 SRE 團隊）接到客戶的回報：開發者對所有線上離線包進行了一輪的整合和重構，發版後發現 H5 應用的加載性能出現較大的退化：在網絡好的情況下會有一個短暫的“白屏”等待時間，在網絡較差的情況下，甚至完全無法完成頁面的加載。更詳細的資訊包括：
1) 前一天晚上在生産環境進行離線包版本更新，發現釋出白名單内的使用者通路離線包出現性能退化
2) iOS 和 Android 雙端均存在這個問題
3) 白名單内共有 20 多個内部使用者，非外部使用者，對外業務沒有實際影響
4) 非白名單内使用者通路的還是老版本的離線包，沒有出現問題
5) 開發側的變更内容包括：
a) 全量離線包更新，更新數量大概是60個左右
b) 舊離線包的架構是 1 個公共資源包 + N 個普通資源包
c) 新離線包的架構是 3 個公共資源包 + N 個普通資源包
2. 分析與排查
根據症狀 “網絡好的情況下會有一個短暫的“白屏”等待時間，網絡較差的情況下，甚至完全無法完成頁面的加載”，我們首先懷疑的是離線包的“離線”機制失敗了，流量 fallback 到了線上資源。推測“白屏”等待時間是 Web 資源網絡下載下傳和加載慢導緻的，如下圖所示：
要驗證這個推測，我們需要通過抓取 HTTP 層面的封包來确認這個問題，抓包方法可參考文後資料了解詳情[1]。從網絡包中我們觀察到，每次打開 H5 應用，均存在不同程度的資源檔案拉取行為，這些 Web 資源大的有幾十 MB，通過網絡加載速度較慢，如下圖所示：
和客戶進一步溝通确認，這部分資源來自于一個新增的公共資源包。根據 mPaaS H5 容器的接入要求，公共資源包的注冊需要在容器初始化的時候手動指定，而普通資源包則不需要這樣的操作，可參考文後資料了解詳情[2]，[3]。結合當時的情況（僅進行了離線包的雲端重構，新增 3 個全局資源包，用戶端 App 并未重新發版）推測：這部分 fallback 流量産生原因是用戶端未注冊新的公共資源包，是以容器不知道這部分資源在本地的映射，隻能從網絡 fallback 位址擷取，而這裡的核心 JS 資源的加載慢導緻了“白屏”等待的性能問題。
根據上述分析進行用戶端代碼檢查，确認用戶端确實沒有對新增的公共資源包進行注冊。開發者按照文檔重新對這個細節進行處理，打包測試後确認問題消失：不再有 fallback 的請求，“白屏”等待的問題也得到了解決。
3. 小結
開發者在 mPaaS H5 容器在接入和使用上需要對一些細節投入特别的關注，比如離線包的驗簽和全局包的使用等。因為 H5 容器存在 fallback 機制，是以即使“離線”失敗，容器也是可以“正常”加載業務包的内容的，開發階段開發者往往容易忽略掉“離線”對性能層面的影響。建議開發者在聯調和上線的過程中，對于離線機制的工作情況予以檢查和确認，可以通過抓包的手段從外部确認沒有額外的、非必要的 fallback 請求産生，最終的目的是發揮離線包的性能優勢。
參考文檔
[1]如何抓取 HTTP 封包（Mac OS/Charles）：
https://help.aliyun.com/document_detail/159161.html[2]Android管理離線包：
https://help.aliyun.com/document_detail/112553.html[3]iOS管理離線包：
https://help.aliyun.com/document_detail/112928.html我們是阿裡雲智能全球技術服務-SRE團隊，我們緻力成為一個以技術為基礎、面向服務、保障業務系統高可用的工程師團隊；提供專業、體系化的SRE服務，幫助廣大客戶更好地使用雲、基于雲建構更加穩定可靠的業務系統，提升業務穩定性。我們期望能夠分享更多幫助企業客戶上雲、用好雲，讓客戶雲上業務運作更加穩定可靠的技術，您可用釘釘掃描下方二維碼，加入阿裡雲SRE技術學院釘釘圈子，和更多雲上人交流關于雲平台的那些事。