客戶端H5前端優(yōu)化方案

桌面時代受限于瀏覽器，H5 頁面無法做更多的優(yōu)化，現(xiàn)在 H5 頁面是內(nèi)嵌在客戶端 APP 上，客戶端有更多的權(quán)限，于是客戶端上可以超出瀏覽器的范圍，做更多的優(yōu)化。

HTML 緩存

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

在客戶端攔截請求，第1次請求 HTML 文件后緩存數(shù)據(jù)，第二次不發(fā)請求，直接使用緩存數(shù)據(jù)。

什么時候去請求更新？這個更新請求可以客戶端自由控制策略，可以在使用本地緩存打開本地頁面后再在后臺發(fā)起請求詢問更新緩存，下次打開時生效；也可以在 APP 啟動時或某個時機在后臺去發(fā)起請求預更新，提升用戶訪問醉新代碼的幾率。

這樣看起來已經(jīng)比較完美了，HTML 文件在用客戶端的策略緩存，其余資源和數(shù)據(jù)沿用上述前端的緩存方式，這樣一個 H5 頁面第二次訪問從 HTML 到 JS/CSS/Image 資源，再到數(shù)據(jù)，都可以直接從本地讀取，無需等待網(wǎng)絡請求，同時又能保持盡可能的實時更新，解決了緩存問題，大大提升 H5 頁面首屏啟動速度。

問題

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

沒有預加載：第1次打開的體驗很差，所有數(shù)據(jù)都要從網(wǎng)絡請求。

緩存不可控：緩存的存取由系統(tǒng) webview 控制，無法控制它的緩存邏輯，帶來的問題包括： 1. 清理邏輯不可控，緩存空間有限，可能緩存幾張大圖片后，重要的 HTML/JS/CSS 緩存就被清除了。 2.磁盤 IO 無法控制，無法從磁盤預加載數(shù)據(jù)到內(nèi)存。

更新體驗差：后臺 HTML/JS/CSS 更新時全量下載，數(shù)據(jù)量大，弱網(wǎng)下載耗時長。

無法防劫持：若 HTML 頁面被運營商或其他第三方劫持，將長時間緩存劫持的頁面。

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

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

客戶端可以接管所有請求的緩存，不走 webview 默認緩存邏輯，自行實現(xiàn)緩存機制，可以分緩存優(yōu)先級以及緩存預加載。

可以針對每個 HTML 和資源文件做增量更新，只是實現(xiàn)和管理起來比較麻煩。

在客戶端使用 httpdns + https 防劫持。

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

離線包

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

可以預先下載整個離線包，只需要按業(yè)務模塊配置，不需要按文件配置，離線包包含業(yè)務模塊相關(guān)的所有頁面，可以一次性預加載。

離線包核心文件和頁面動態(tài)的圖片資源文件緩存分離，可以更方便地管理緩存，離線包也可以整體提前加載進內(nèi)存，減少磁盤 IO 耗時。

離線包可以很方便地根據(jù)版本做增量更新。

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

到這里，對于使用 H5 開發(fā)功能模塊，離線包是一個挺不錯的方案了，簡單復述一下離線包的方案：

后端使用構(gòu)建工具把同一個業(yè)務模塊相關(guān)的頁面和資源打包成一個文件，同時對文件加密/簽名。

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

根據(jù)配置表，打開某個業(yè)務時轉(zhuǎn)接到打開離線包的入口頁面。

攔截網(wǎng)絡請求，對于離線包已經(jīng)有的文件，直接讀取離線包數(shù)據(jù)返回，否則走 HTTP 協(xié)議緩存邏輯。

離線包更新時，根據(jù)版本號后臺下發(fā)兩個版本間的 diff 數(shù)據(jù)，客戶端合并，增量更新。

更多優(yōu)化

離線包方案在緩存上已經(jīng)做得差不多了，還可以再配上一些細節(jié)優(yōu)化：

公共資源包

每個包都會使用相同的 JS 框架和 CSS 全局樣式，這些資源重復在每一個離線包出現(xiàn)太浪費，可以做一個公共資源包提供這些全局文件。

預加載 webview

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

預加載：在一個進程內(nèi)初始化 webview 與第二次初始化不同，第1次會比第二次慢很多。原因預計是 webview 第1次初始化后，即使 webview 已經(jīng)釋放，但一些多 webview 共用的全局服務或資源對象仍沒有釋放，第二次初始化時不需要再生成這些對象從而變快。我們可以在 APP 啟動時預先初始化一個 webview 然后釋放，這樣等用戶真正走到 H5 模塊去加載 webview時就變快了。

webview 池：可以用兩個或多個 webview 重復使用，而不是每次打開 H5 都新建 webview。不過這種方式要解決頁面跳轉(zhuǎn)時清空上一個頁面，另外若一個 H5 頁面上 JS 出現(xiàn)內(nèi)存泄漏，就影響到其他頁面，在 APP 運行期間都無法釋放了。

可以參考美團點評的這篇文章。

預加載數(shù)據(jù)

理想情況下離線包的方案第1次打開時所有 HTML/JS/CSS 都使用本地緩存，無需等待網(wǎng)絡請求，但頁面上的用戶數(shù)據(jù)還是需要實時拉，這里可以做個優(yōu)化，在 webview 初始化的同時并行去請求數(shù)據(jù)，webview 初始化是需要一些時間的，這段時間沒有任何網(wǎng)絡請求，在這個時機并行請求可以節(jié)省不少時間。

具體實現(xiàn)上，首先可以在配置表注明某個離線包需要預加載的 URL，客戶端在 webview 初始化同時發(fā)起請求，請求由一個管理器管理，請求完成時緩存結(jié)果，然后 webview 在初始化完畢后開始請求剛才預加載的 URL，客戶端攔截到請求，轉(zhuǎn)接到剛才提到的請求管理器，若預加載已完成就直接返回內(nèi)容，若未完成則等待。

Fallback

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

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

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

還可以對離線包做一個線上版本，離線包里的文件在服務端有一一對應的訪問地址，在本地沒有離線包時，直接訪問對應的線上地址，跟傳統(tǒng)打開一個在線頁面一樣，這種體驗相對等待下載整個離線包較好，也能**用戶訪問到醉新。

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

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

使用客戶端接口

網(wǎng)路和存儲接口如果使用 webkit 的 ajax 和 localStorage 會有不少限制，難以優(yōu)化，可以在客戶端提供這些接口給 JS，客戶端可以在網(wǎng)絡請求上做像 DNS 預解析/IP直連/長連接/并行請求等更細致的優(yōu)化，存儲也使用客戶端接口也能做讀寫并發(fā)/用戶隔離等針對性優(yōu)化。

服務端渲染

早期 web 頁面里，JS 只是負責交互，所有內(nèi)容都是直接在 HTML里，到現(xiàn)代 H5 頁面，很多內(nèi)容已經(jīng)依賴 JS 邏輯去決定渲染什么，例如等待 JS 請求 JSON 數(shù)據(jù)，再拼接成 HTML 生成 DOM 渲染到頁面上，于是頁面的渲染展現(xiàn)就要等待這一整個過程，這里有一個耗時，減少這里的耗時也是白屏優(yōu)化的范圍之內(nèi)。

優(yōu)化方法可以是人為減少 JS 渲染邏輯，也可以是更徹底地，回歸到原始，所有內(nèi)容都由服務端返回的 HTML 決定，無需等待 JS 邏輯，稱之為服務端渲染。是否做這種優(yōu)化視業(yè)務情況而定，畢竟這種會帶來開發(fā)模式變化/流量增大/服務端開銷增大這些負面影響。