來自：螞蟻金服高階無線開發專家 bang

隨著移動裝置效能不斷增強，web 頁面的效能體驗逐漸變得可以接受，又因為 web 開發模式的諸多好處(跨平臺，動態更新，減體積，無限擴充套件)，APP 客戶端裡出現越來越多內嵌 web 頁面（為了配上當前流行的說法，以下把所有網頁都稱為 H5 頁面，雖然可能跟 H5 沒關係），很多 APP 把一些功能模組改成用 H5 實現。

雖然說 H5 頁面效能變好了，但如果沒針對性地做一些優化，體驗還是很糟糕的，主要兩部分體驗：

1.頁面啟動白屏時間：開啟一個 H5 頁面需要做一系列處理，會有一段白屏時間，體驗糟糕。

2.響應流暢度：由於 webkit 的渲染機制，單執行緒，歷史包袱等原因，頁面重新整理/互動的效能體驗不如原生。

本文先不討論第二點，只討論第一點，怎樣減少白屏時間。對 APP 裡的一些使用 H5 實現的功能模組，怎樣加快它們的啟動速度，讓它們啟動的體驗接近原生。

過程

為什麼開啟一個 H5 頁面會有一長段白屏時間？因為它做了很多事情，大概是：

初始化 webview -> 請求頁面 -> 下載資料 -> 解析HTML -> 請求 js/css 資源 -> dom 渲染 -> 解析 JS 執行 -> JS 請求資料 -> 解析渲染 -> 下載渲染圖片

一些簡單的頁面可能沒有 JS 請求資料 這一步，但大部分功能模組應該是有的，根據當前使用者資訊，JS 向後臺請求相關資料再渲染，是常規開發方式。

一般頁面在 dom 渲染後能顯示雛形，在這之前使用者看到的都是白屏，等到下載渲染圖片後整個頁面才完整顯示，首屏秒開優化就是要減少這個過程的耗時。

前端優化

上述開啟一個頁面的過程有很多優化點，包括前端和客戶端，常規的前端和後端的效能優化在 PC 時代已經有最佳實踐，主要的是：

1.降低請求量：合併資源，減少 HTTP 請求數，minify / gzip 壓縮，webP，lazyLoad。
2.加快請求速度：預解析DNS，減少域名數，並行載入，CDN 分發。
3.快取：HTTP 協議快取請求，離線快取 manifest，離線資料快取localStorage。
4.渲染：JS/CSS優化，載入順序，服務端渲染，pipeline。

其中對首屏啟動速度影響最大的就是網路請求，所以優化的重點就是快取，這裡著重說一下前端對請求的快取策略。我們再細分一下，分成 HTML 的快取，JS/CSS/image 資源的快取，以及 json 資料的快取。

HTML 和 JS/CSS/image 資源都屬於靜態檔案，HTTP 本身提供了快取協議，瀏覽器實現了這些協議，可以做到靜態檔案的快取。

總的來說，就是兩種快取：

1.詢問是否有更新：根據 If-Modified-Since / ETag 等協議向後端請求詢問是否有更新，沒有更新返回304，瀏覽器使用本地快取。

2.直接使用本地快取：根據協議裡的 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 檔案的“快取”和跟“更新”間存在矛盾。

客戶端優化

接著輪到客戶端出場了，桌面時代受限於瀏覽器，H5 頁面無法做更多的優化，現在 H5 頁面是內嵌在客戶端 APP 上，客戶端有更多的許可權，於是客戶端上可以超出瀏覽器的範圍，做更多的優化。

HTML 快取

先接著快取說，在客戶端有更自由的快取策略，客戶端可以攔截 H5 頁面的所有請求，由自己管理快取，針對上述 HTML 檔案的“快取”和“更新”之間的矛盾，我們可以用這樣的策略解決：

1.在客戶端攔截請求，首次請求 HTML 檔案後快取資料，第二次不發請求，直接使用快取資料。

2.什麼時候去請求更新？這個更新請求可以客戶端自由控制策略，可以在使用本地快取開啟本地頁面後再在後臺發起請求詢問更新快取，下次開啟時生效；也可以在 APP 啟動時或某個時機在後臺去發起請求預更新，提升使用者訪問最新程式碼的機率。

這樣看起來已經比較完美了，HTML 檔案在用客戶端的策略快取，其餘資源和資料沿用上述前端的快取方式，這樣一個 H5 頁面第二次訪問從 HTML 到 JS/CSS/Image 資源，再到資料，都可以直接從本地讀取，無需等待網路請求，同時又能保持儘可能的實時更新，解決了快取問題，大大提升 H5 頁面首屏啟動速度。

問題

上述方案似乎已完整解決快取問題，但實際上還有很多問題：

1.沒有預載入：第一次開啟的體驗很差，所有資料都要從網路請求。
2.快取不可控：快取的存取由系統 webview 控制，無法控制它的快取邏輯，帶來的問題包括：

清理邏輯不可控，快取空間有限，可能快取幾張大圖片後，重要的 HTML/JS/CSS 快取就被清除了。
磁碟 IO 無法控制，無法從磁碟預載入資料到記憶體。
更新體驗差：後臺 HTML/JS/CSS 更新時全量下載，資料量大，弱網下載耗時長。
無法防劫持：若 HTML 頁面被運營商或其他第三方劫持，將長時間快取劫持的頁面。

這些問題在客戶端上都是可以被解決的，只不過有點麻煩，簡單描述下：

1.可以配置一個預載入列表，在APP啟動或某些時機時提前去請求，這個預載入列表需要包含所需 H5 模組的頁面和資源，還需要考慮到一個H5模組有多個頁面的情況，這個列表可能會很大，也需要工具生成和管理這個預載入列表。

2.客戶端可以接管所有請求的快取，不走 webview 預設快取邏輯，自行實現快取機制，可以分快取優先順序以及快取預載入。

3.可以針對每個 HTML 和資原始檔做增量更新，只是實現和管理起來比較麻煩。
4.在客戶端使用 httpdns + https 防劫持。

上面的解決方案實現起來十分繁瑣，原因就是各個 HTML 和資原始檔很多很分散，管理困難，有個較好的方案可以解決這些問題，就是離線包。

離線包

既然很多問題都是檔案分散管理困難引起，而我們這裡的使用場景是使用 H5 開發功能模組，那很容易想到把一個個功能模組的所有相關頁面和資源打包下發，這個壓縮包可以稱為功能模組的離線包。使用離線包的方案，可以相對較簡單地解決上述幾個問題：

1.可以預先下載整個離線包，只需要按業務模組配置，不需要按檔案配置，離線包包含業務模組相關的所有頁面，可以一次性預載入。

2.離線包核心檔案和頁面動態的圖片資原始檔快取分離，可以更方便地管理快取，離線包也可以整體提前載入進記憶體，減少磁碟 IO 耗時。

3.離線包可以很方便地根據版本做增量更新。

4.離線包以壓縮包的方式下發，同時會經過加密和校驗，運營商和第三方無法對其劫持篡改。

到這裡，對於使用 H5 開發功能模組，離線包是一個挺不錯的方案了，簡單複述一下離線包的方案：

1.後端使用構建工具把同一個業務模組相關的頁面和資源打包成一個檔案，同時對檔案加密/簽名。

2.客戶端根據配置表，在自定義時機去把離線包拉下來，做解壓/解密/校驗等工作。

3.根據配置表，開啟某個業務時轉接到開啟離線包的入口頁面。

4.攔截網路請求，對於離線包已經有的檔案，直接讀取

5.離線包資料返回，否則走 HTTP 協議快取邏輯。
離線包更新時，根據版本號後臺下發兩個版本間的 diff 資料，客戶端合併，增量更新。

更多優化

離線包方案在快取上已經做得差不多了，還可以再配上一些細節優化：

公共資源包

每個包都會使用相同的 JS 框架和 CSS 全域性樣式，這些資源重複在每一個離線包出現太浪費，可以做一個公共資源包提供這些全域性檔案。

預載入 webview

無論是 iOS 還是 Android，本地 webview 初始化都要不少時間，可以預先初始化好 webview。這裡分兩種預載入：

1.首次預載入：在一個程序內首次初始化 webview 與第二次初始化不同，首次會比第二次慢很多。原因預計是 webview 首次初始化後，即使 webview 已經釋放，但一些多 webview 共用的全域性服務或資源物件仍沒有釋放，第二次初始化時不需要再生成這些物件從而變快。我們可以在 APP 啟動時預先初始化一個 webview 然後釋放，這樣等使用者真正走到 H5 模組去載入 webview時就變快了。

2.webview 池：可以用兩個或多個 webview 重複使用，而不是每次開啟 H5 都新建 webview。不過這種方式要解決頁面跳轉時清空上一個頁面，另外若一個 H5 頁面上 JS 出現記憶體洩漏，就影響到其他頁面，在 APP 執行期間都無法釋放了。

預載入資料

理想情況下離線包的方案第一次開啟時所有 HTML/JS/CSS 都使用本地快取，無需等待網路請求，但頁面上的使用者資料還是需要實時拉，這裡可以做個優化，在 webview 初始化的同時並行去請求資料，webview 初始化是需要一些時間的，這段時間沒有任何網路請求，在這個時機並行請求可以節省不少時間。

具體實現上，首先可以在配置表註明某個離線包需要預載入的 URL，客戶端在 webview 初始化同時發起請求，請求由一個管理器管理，請求完成時快取結果，然後 webview 在初始化完畢後開始請求剛才預載入的 URL，客戶端攔截到請求，轉接到剛才提到的請求管理器，若預載入已完成就直接返回內容，若未完成則等待。

Fallback

如果使用者訪問某個離線包模組時，這個離線包還沒有下載，或配置表檢測到已有新版本但本地是舊版本的情況如何處理？幾種方案：

1.簡單的方案是如果本地離線包沒有或不是最新，就同步阻塞等待下載最新離線包。這種使用者開啟的體驗更差了，因為離線包體積相對較大。

2.也可以是如果本地有舊包，使用者本次就直接使用舊包，如果沒有再同步阻塞等待，這種會導致更新不及時，無法確保使用者使用最新版本。

3.還可以對離線包做一個線上版本，離線包裡的檔案在服務端有一一對應的訪問地址，在本地沒有離線包時，直接訪問對應的線上地址，跟傳統開啟一個線上頁面一樣，這種體驗相對等待下載整個離線包較好，也能保證使用者訪問到最新。

第三種 Fallback 的方式還帶來兜底的好處，在一些意外情況離線包出錯的時候可以直接訪問線上版本，功能不受影響，此外像公共資源包更新不及時導致版本沒有對應上時也可以直接訪問線上版本，是個不錯的兜底方案。

上述幾種方案策略也可以混著使用，看業務需求。

使用客戶端介面

網路和儲存介面如果使用 webkit 的 ajax 和 localStorage 會有不少限制，難以優化，可以在客戶端提供這些介面給 JS，客戶端可以在網路請求上做像 DNS 預解析/IP直連/長連線/並行請求等更細緻的優化，儲存也使用客戶端介面也能做讀寫併發/使用者隔離等針對性優化。

服務端渲染

早期 web 頁面裡，JS 只是負責互動，所有內容都是直接在 HTML 裡，到現代 H5 頁面，很多內容已經依賴 JS 邏輯去決定渲染什麼，例如等待 JS 請求 JSON 資料，再拼接成 HTML 生成 DOM 渲染到頁面上，於是頁面的渲染展現就要等待這一整個過程，這裡有一個耗時，減少這裡的耗時也是白屏優化的範圍之內。

優化方法可以是人為減少 JS 渲染邏輯，也可以是更徹底地，迴歸到原始，所有內容都由服務端返回的 HTML 決定，無需等待 JS 邏輯，稱之為服務端渲染。是否做這種優化視業務情況而定，畢竟這種會帶來開發模式變化/流量增大/服務端開銷增大這些負面影響。手Q的部分頁面就是使用服務端渲染的方式，稱為動態直出。

最後

從前端優化，到客戶端快取，到離線包，到更多的細節優化，做到上述這些點，H5 頁面在啟動上差不多可以媲美原生的體驗了。

總結起來，大體優化思路就是：快取/預載入/並行，快取一切網路請求，儘量在使用者開啟之前就載入好所有內容，能並行做的事不序列做。這裡有些優化手段需要做好一整套工具和流程支援，需要跟開發效率權衡，視實際需求優化。

另外上述討論的是針對功能模組類的 H5 頁面秒開的優化方案，客戶端 APP 上除了功能模組，其他一些像營銷活動/外部接入的 H5 頁面可能有些優化點就不適用，還需要視實際情況和需求而定。另外微信小程式就是屬於功能模組的類別，差不多是這個套路。

這裡討論了 H5 頁面首屏啟動時間的優化，上述優化過後，基本上耗時只剩 webview 本身的啟動/渲染機制問題了，這個問題跟後續的響應流暢度的問題一起屬於另一個優化範圍，就是類 RN / Weex 這樣的方案，有機會再探討。