客戶端突如其來的「白屏」等待該如何解決？

時間 2021-04-05

標籤 html 網絡架構框架性能測試阿里雲 spa htm 事件欄目 HTML 简体版

原文原文鏈接

簡介：一塊兒由離線包重構引發的「白屏」等待現象的排查和解決案例

——本文選自《阿里雲SRE技術期刊》2021年02月刊html

移動端的混合架構模式給 App 開發帶來了嶄新的空間，經過 H5 構建的業務模塊能夠實現高效快速的版本迭代，知足多樣化的業務需求。爲了彌補 H5 技術的部分性能不足，mPaaS 客戶端框架爲開發者提供了「離線」機制。網絡

開發者在接入 mPaaS H5 容器後，配合 mPaaS 移動發佈服務，可讓客戶端方便地從本地加載 H5 業務包，極大地提高了 H5 應用的加載效率。須要注意的是，這套離線機制的接入過程必需要嚴格按照文檔來進行，一些細微的錯誤可能致使離線機制失敗，給 H5 應用的加載性能帶來影響。架構

這篇文章將和你們分享一塊兒由離線包重構引發的「白屏」等待現象的排查和解決案例。框架

1. 問題背景

咱們（阿里雲金融線 SRE 團隊）接到客戶的反饋：開發者對全部線上離線包進行了一輪的整合和重構，發版後發現 H5 應用的加載性能出現較大的退化：在網絡好的狀況下會有一個短暫的「白屏」等待時間，在網絡較差的狀況下，甚至徹底沒法完成頁面的加載。更詳細的信息包括：性能

1) 前一天晚上在生產環境進行離線包版本更新，發現發佈白名單內的用戶訪問離線包出現性能退化測試

2) iOS 和 Android 雙端均存在這個問題阿里雲

3) 白名單內共有 20 多個內部用戶，非外部用戶，對外業務沒有實際影響spa

4) 非白名單內用戶訪問的仍是老版本的離線包，沒有出現問題htm

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 請求產生，最終的目的是發揮離線包的性能優點。