[TOC] ## 頁面加載 為什么打開一個 H5 頁面會有一長段白屏時間？因為它做了很多事情，大概是： ~~~ 初始化 webview -> 請求頁面 -> 下載數據 -> 解析HTML -> 請求 js/css 資源 -> dom 渲染 -> 解析 JS 執行 -> JS 請求數據 -> 解析渲染 -> 下載渲染圖片 ~~~ 一些簡單的頁面可能沒有 JS 請求數據 這一步，但大部分功能模塊應該是有的，根據當前用戶信息，JS 向后臺請求相關數據再渲染，是常規開發方式。 一般頁面在 dom 渲染后能顯示雛形，在這之前用戶看到的都是白屏，等到下載渲染圖片后整個頁面才完整顯示，首屏秒開優化就是要減少這個過程的耗時。 ## 前端優化 上述打開一個頁面的過程有很多優化點，包括前端和客戶端，常規的前端和后端的性能優化在桌面時代已經有最佳實踐，主要的是： * 降低請求量：合并資源，減少 HTTP 請求數，minify / gzip 壓縮，webP，lazyLoad。 * 加快請求速度：預解析DNS，減少域名數，并行加載，CDN 分發。 * 緩存：HTTP 協議緩存請求，離線緩存 manifest，離線數據緩存localStorage。 * 渲染：JS/CSS優化，加載順序，服務端渲染，pipeline。 其中對首屏啟動速度影響最大的就是網絡請求，所以優化的重點就是緩存，這里著重說一下前端對請求的緩存策略。我們再細分一下，分成 HTML 的緩存，JS/CSS/image 資源的緩存，以及 json 數據的緩存。 HTML 和 JS/CSS/image 資源都屬于靜態文件，HTTP 本身提供了緩存協議，瀏覽器實現了這些協議，可以做到靜態文件的緩存，具體可以參考[這里](https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching)，總的來說，就是兩種緩存： * 詢問是否有更新：根據 If-Modified-Since / ETag 等協議向后端請求詢問是否有更新，沒有更新返回304，瀏覽器使用本地緩存。 * 直接使用本地緩存：根據協議里的 Cache-Control / Expires 字段去確定多長時間內可以不去發請求詢問更新，直接使用本地緩存。 前端能做的最大限度的緩存策略是：HTML 文件每次都向服務器詢問是否有更新，JS/CSS/Image資源文件則不請求更新，直接使用本地緩存。那 JS/CSS 資源文件如何更新？常見做法是在在構建過程中給每個資源文件一個版本號或hash值，若資源文件有更新，版本號和 hash 值變化，這個資源請求的 URL 就變化了，同時對應的 HTML 頁面更新，變成請求新的資源URL，資源也就更新了。 json 數據的緩存可以用 localStorage 緩存請求下來的數據，可以在首次顯示時先用本地數據，再請求更新，這都由前端 JS 控制。 這些緩存策略可以實現 JS/CSS 等資源文件以及用戶數據的緩存的全緩存，可以做到每次都直接使用本地緩存數據，不用等待網絡請求。但 HTML 文件的緩存做不到，對于 HTML 文件，如果把 Expires / max-age 時間設長了，長時間只使用本地緩存，那更新就不及時，如果設短了，每次打開頁面都要發網絡請求詢問是否有更新，再確定是否使用本地資源，一般前端在這里的策略是每次都請求，這在弱網情況下用戶感受到的白屏時間仍然會很長。所以 HTML 文件的“緩存”和跟“更新”間存在矛盾。 ## 客戶端優化 ### HTML 緩存 先接著緩存說，在客戶端有更自由的緩存策略，客戶端可以攔截 H5 頁面的所有請求，由自己管理緩存，針對上述 HTML 文件的“緩存”和“更新”之間的矛盾，我們可以用這樣的策略解決： 在客戶端攔截請求，首次請求 HTML 文件后緩存數據，第二次不發請求，直接使用緩存數據。 什么時候去請求更新？這個更新請求可以客戶端自由控制策略，可以在使用本地緩存打開本地頁面后再在后臺發起請求詢問更新緩存，下次打開時生效；也可以在 APP 啟動時或某個時機在后臺去發起請求預更新，提升用戶訪問最新代碼的幾率。 這樣看起來已經比較完美了，HTML 文件在用客戶端的策略緩存，其余資源和數據沿用上述前端的緩存方式，這樣一個 H5 頁面第二次訪問從 HTML 到 JS/CSS/Image 資源，再到數據，都可以直接從本地讀取，無需等待網絡請求，同時又能保持盡可能的實時更新，解決了緩存問題，大大提升 H5 頁面首屏啟動速度。 ### 問題 上述方案似乎已完整解決緩存問題，但實際上還有很多問題： * 沒有預加載：第一次打開的體驗很差，所有數據都要從網絡請求。 * 緩存不可控：緩存的存取由系統 webview 控制，無法控制它的緩存邏輯，帶來的問題包括： i. 清理邏輯不可控，緩存空間有限，可能緩存幾張大圖片后，重要的 HTML/JS/CSS 緩存就被清除了。 ii.磁盤 IO 無法控制，無法從磁盤預加載數據到內存。 * 更新體驗差：后臺 HTML/JS/CSS 更新時全量下載，數據量大，弱網下載耗時長。 * 無法防劫持：若 HTML 頁面被運營商或其他第三方劫持，將長時間緩存劫持的頁面。 這些問題在客戶端上都是可以被解決的，只不過有點麻煩，簡單描述下： * 可以配置一個預加載列表，在APP啟動或某些時機時提前去請求，這個預加載列表需要包含所需 H5 模塊的頁面和資源，還需要考慮到一個H5模塊有多個頁面的情況，這個列表可能會很大，也需要工具生成和管理這個預加載列表。 * 客戶端可以接管所有請求的緩存，不走 webview 默認緩存邏輯，自行實現緩存機制，可以分緩存優先級以及緩存預加載。 * 可以針對每個 HTML 和資源文件做增量更新，只是實現和管理起來比較麻煩。 * 在客戶端使用 httpdns + https 防劫持。 上面的解決方案實現起來十分繁瑣，原因就是各個 HTML 和資源文件很多很分散，管理困難，有個較好的方案可以解決這些問題，就是離線包。 ### 離線包 既然很多問題都是文件分散管理困難引起，而我們這里的使用場景是使用 H5 開發功能模塊，那很容易想到把一個個功能模塊的所有相關頁面和資源打包下發，這個壓縮包可以稱為功能模塊的離線包。使用離線包的方案，可以相對較簡單地解決上述幾個問題： * 可以預先下載整個離線包，只需要按業務模塊配置，不需要按文件配置，離線包包含業務模塊相關的所有頁面，可以一次性預加載。 * 離線包核心文件和頁面動態的圖片資源文件緩存分離，可以更方便地管理緩存，離線包也可以整體提前加載進內存，減少磁盤 IO 耗時。 * 離線包可以很方便地根據版本做增量更新。 * 離線包以壓縮包的方式下發，同時會經過加密和校驗，運營商和第三方無法對其劫持篡改。 到這里，對于使用 H5 開發功能模塊，離線包是一個挺不錯的方案了，簡單復述一下離線包的方案： * 后端使用構建工具把同一個業務模塊相關的頁面和資源打包成一個文件，同時對文件加密/簽名。 * 客戶端根據配置表，在自定義時機去把離線包拉下來，做解壓/解密/校驗等工作。 * 根據配置表，打開某個業務時轉接到打開離線包的入口頁面。 * 攔截網絡請求，對于離線包已經有的文件，直接讀取離線包數據返回，否則走 HTTP 協議緩存邏輯。 * 離線包更新時，根據版本號后臺下發兩個版本間的 diff 數據，客戶端合并，增量更新。 ### 預加載 webview 無論是 iOS 還是 Android，本地 webview 初始化都要不少時間，可以預先初始化好 webview。這里分兩種預加載： * 首次預加載：在一個進程內首次初始化 webview 與第二次初始化不同，首次會比第二次慢很多。原因預計是 webview 首次初始化后，即使 webview 已經釋放，但一些多 webview 共用的全局服務或資源對象仍沒有釋放，第二次初始化時不需要再生成這些對象從而變快。我們可以在 APP 啟動時預先初始化一個 webview 然后釋放，這樣等用戶真正走到 H5 模塊去加載 webview時就變快了。 * webview 池：可以用兩個或多個 webview 重復使用，而不是每次打開 H5 都新建 webview。不過這種方式要解決頁面跳轉時清空上一個頁面，另外若一個 H5 頁面上 JS 出現內存泄漏，就影響到其他頁面，在 APP 運行期間都無法釋放了。 ### 預加載數據 理想情況下離線包的方案第一次打開時所有 HTML/JS/CSS 都使用本地緩存，無需等待網絡請求，但頁面上的用戶數據還是需要實時拉，這里可以做個優化，在 webview 初始化的同時并行去請求數據，webview 初始化是需要一些時間的，這段時間沒有任何網絡請求，在這個時機并行請求可以節省不少時間。 具體實現上，首先可以在配置表注明某個離線包需要預加載的 URL，客戶端在 webview 初始化同時發起請求，請求由一個管理器管理，請求完成時緩存結果，然后 webview 在初始化完畢后開始請求剛才預加載的 URL，客戶端攔截到請求，轉接到剛才提到的請求管理器，若預加載已完成就直接返回內容，若未完成則等待。 ### Fallback 如果用戶訪問某個離線包模塊時，這個離線包還沒有下載，或配置表檢測到已有新版本但本地是舊版本的情況如何處理？幾種方案： * 簡單的方案是如果本地離線包沒有或不是最新，就同步阻塞等待下載最新離線包。這種用戶打開的體驗更差了，因為離線包體積相對較大。 * 也可以是如果本地有舊包，用戶本次就直接使用舊包，如果沒有再同步阻塞等待，這種會導致更新不及時，無法確保用戶使用最新版本。 * 還可以對離線包做一個線上版本，離線包里的文件在服務端有一一對應的訪問地址，在本地沒有離線包時，直接訪問對應的線上地址，跟傳統打開一個在線頁面一樣，這種體驗相對等待下載整個離線包較好，也能保證用戶訪問到最新。 第三種 Fallback 的方式還帶來兜底的好處，在一些意外情況離線包出錯的時候可以直接訪問線上版本，功能不受影響，此外像公共資源包更新不及時導致版本沒有對應上時也可以直接訪問線上版本，是個不錯的兜底方案。 上述幾種方案策略也可以混著使用，看業務需求。 ### 使用客戶端接口 網路和存儲接口如果使用 webkit 的 ajax 和 localStorage 會有不少限制，難以優化，可以在客戶端提供這些接口給 JS，客戶端可以在網絡請求上做像 DNS 預解析/IP直連/長連接/并行請求等更細致的優化，存儲也使用客戶端接口也能做讀寫并發/用戶隔離等針對性優化。 ## 服務端渲染 早期 web 頁面里，JS 只是負責交互，所有內容都是直接在 HTML 里，到現代 H5 頁面，很多內容已經依賴 JS 邏輯去決定渲染什么，例如等待 JS 請求 JSON 數據，再拼接成 HTML 生成 DOM 渲染到頁面上，于是頁面的渲染展現就要等待這一整個過程，這里有一個耗時，減少這里的耗時也是白屏優化的范圍之內。 優化方法可以是人為減少 JS 渲染邏輯，也可以是更徹底地，回歸到原始，所有內容都由服務端返回的 HTML 決定，無需等待 JS 邏輯，稱之為服務端渲染。是否做這種優化視業務情況而定，畢竟這種會帶來開發模式變化/流量增大/服務端開銷增大這些負面影響。手Q的部分頁面就是使用服務端渲染的方式，稱為動態直出，見文章。 參考資料 [移動 H5 首屏秒開優化方案探討](https://mp.weixin.qq.com/s/i035lEHc2w2K-TBhbDtaLQ) [WebView性能、體驗分析與優化](https://tech.meituan.com/WebViewPerf.html)