從零開始搞監控系統（6）——較長的白屏時間

一、加載慢

　　在直播間有一個小時榜的Web頁面，經常有用戶反映點擊小時榜，彈出的頁面會有蠻長的一段（3秒上下）時間白屏。

　　

　　查看性能監控中的白屏時間，發現最多1.6秒，最少0.4秒平均每小時的白屏在1秒左右（有待優化），那么大概還有2秒的時間可能是其他原因造成的。

　　

　　在頁面中會包含很多主播頭像，有可能是圖片太多阻塞了渲染，於是將主播的頭像都改成異步加載，在調試的時候直接將他們都隱藏掉，並且在動態讀取的部分加入loading效果。

　　發到預生產做調試，通過Charles把線上地址映射成預發地址。為了讓APP的環境更加純粹，特地刪除了APP重新安裝。

　　但是在iOS中打開小時榜的時候，還是會有2秒以上非常明顯的白屏時間。查詢資源瀑布圖，也就900ms的樣子，離體驗到的白屏時間還是差點。

　　

　　讓iOS和安卓給WebView加了個加載進度條，確認白屏的時候到底有沒有開始請求資源。

　　安卓的情況比iOS好很多，白屏時間並不長，幾乎是一閃而過。

　　后面讓iOS的人查看代碼才發現，原來他們是在等到彈出動畫結束后開始請求資源，差不多有1秒的動畫時間。怪不得每次都要2、3秒的白屏時間。

二、預請求

　　經過觀察發現每次請求后端數據的API大概要花100~200ms，如果把這段時間省下來，那么也能減少白屏時間，於是想到了數據預請求。

　　數據預請求是將數據預請求的時機由業務發起請求的時機，提前到用戶點擊時，並行發送數據請求，縮短數據等待時間。

　　

　　在Webview啟動的時候，並行的去請求首屏需要的數據，流程圖如下所示：

　　

　　首屏數據的接口信息，可以通過一些配置關聯起來，比如一個單獨的配置接口。

　　對客戶端而言，H5初始化的時間和數據請求的時間先后不確定。

　　所以，如果客戶端先拿到數據，會把數據緩存在一個全局變量中，等待H5來調用。

　　具體的實現方案：

• 客戶端分析出當前URL中的路徑和參數，其中 refresh 參數（有的話）是一個時間戳（秒），這次參數用來控制客戶端是否需要重新請求配置接口。
• 當分析的URL參數中無 refresh 字段時，訪問 https://xxx.com/settings 接口，並將URL路徑、客戶端默認帶的參數（包含用戶ID等）和 URL 本身的參數全部傳遞過來，然后本地緩存。

https://xxx.com/settings?path=game%2Fstrick&uid=xxxxx&refresh=1618451992

• 客戶端會將settings接口的響應數據緩存到本地，而key就是當前URL，也就是說URL不變的話，默認就不會去請求settings接口。若要穿透緩存，那么加上refresh參數，賦一個與之前不同的值即可。
• settings 接口返回的JSON格式，包含 urls 字段，是個數組，由接口集合組成，已經拼接好參數。

{
    "urls": [
        "http://xxx.com/xx/xx?id=2",
        "http://xxx.com/yy/yy?uid=1"
    ]
}

• 客戶端將讀取到的數據注入到 WebView 的全局對象中，可以用全局變量同步讀取，名字叫 TheLClientResponse，讀取方式：window.TheLClientResponse，JSON格式如下，其中key是api的路徑，如果無數據可以返回 null。

{
    "xx/xx": {
        code: 0,
        msg: "test",
        data: {
            list: []
        }
    },
    "yy/yy": {
        code: 0,
        msg: "test",
        data: {
            list: []
        }
    }
}