前言
對於電商APP來講，使用H5技術開發的頁面佔比很高。由於H5加載速度非常依賴網絡環境，所以為了提高用户體驗，針對H5加載速度的優化非常重要。離線包是最常用的優化技術，通過提前下載H5渲染需要的HTML/JS/CSS資源，加載時直接使用本地緩存資源避免額外的網絡請求提高加載速度。本文主要是介紹團隊在離線包技術方案上的探索，以及基於prefetch的離線包實現方案如何減少維護成本和開發成本。
現有方案
離線包技術發展到現在已經比較成熟。離線包技術主要是分為兩部分，一部分是客户端離線包容器，另一部分是線上離線包平台。
離線包容器
• 資源請求攔截 - 攔截H5資源請求，當存在本地緩存資源時直接返回使用
• 資源緩存 - 資源下載、資源緩存策略、增量更新策略
離線包平台
• 資源管理 - 配置H5頁面對應的離線資源、公共離線資源、CDN存放離線資源包
• 發佈系統 - 實時發佈、灰度能力、版本控制
下面先介紹一下常見的技術實現方式：
資源請求攔截方式
Android
Android實現相對比較統一，主要是通過WebView自帶的shouldInterceptRequestAPI 攔截資源請求，返回對應的離線資源即可實現離線包功能。
iOS
iOS由於蘋果的限制，實現方式相對複雜很多。
NSURLProtocol 方案
使用NSURLProtocol攔截所有WebView內發出的請求。
方案存在的問題
Body丟失
因為WKWebView本身是使用多進程模式，WebView資源網絡請求並不在APP進程中。iOS系統目前的實現，當攔截HTTP網絡請求時會丟失Body，所以需要處理Body丟失的問題。一種方式是替換掉WebView內部的網絡 API，例如Fetch/XMLHttpRequest，但是並不能覆蓋所有場景。另一種方式是網絡請求走原生API橋接的方式，但是這需要H5進行適配有一定的侵入性。
使用私有API
WKWebView本身並不支持網絡請求攔截，當我們需要攔截網絡請求時，需要使用系統私有API通過ObjC Runtime的方式動態調用。存在一定的審核風險，例如Apple審核時不允許使用被拒。另外因為並不是系統暴露出的 API，內部實現未來可能會改變。
WKURLSchemeHandler 方案
WKURLSchemeHandler是iOS11引入的新特性，可以通過此 API 來攔截H5的網絡請求。
方案存在的問題
不支持HTTP/HTTPS協議
• 不支持HTTP/HTTPS協議 - 因為WKURLSchemeHandlerAPI 本身的設計，只能攔截自定義協議並不支持HTTP/HTTPS協議。一種方式是原生加載H5時使用自定義協議或H5內資源使用自定義協議。另一種方式是hook系統方法支持HTTP/HTTPS協議，但是這會帶來一定的風險和不確定性。
Cookie 問題
WKURLSchemeHandler不會處理響應裏的Set-Cookie，所以需要自行處理。
Body丟失問題
此方案同樣存在Body丟失問題。
Local Server 方案
Local Server方式是通過在APP運行時啓動一個本地服務器，請求H5時訪問本地服務器，本地服務器檢查是否可以使用本地離線資源。
方案存在的問題
虛擬鏈接
• 虛擬鏈接 - 因為需要使用虛擬鏈接訪問本地服務器，所以會帶來cookie同步等問題需要解決
資源消耗
• 本地服務器有額外的內存、CPU消耗
PWA 方案
PWA提供了一整套Service Worker API來實現離線H5能力，包括資源的下載、更新、緩存策略等。只不過iOS系統本身沒有提供默認的實現，需要自實現一整套相關的 Service Worker API，複雜度和工作量比較高。
離線包管理平台
增量更新策略
因為一個H5頁面的離線包資源通常是聚合到一個ZIP壓縮包中進行下載，為了避免只更新了部分資源導致全量下載，所以需要提供差異化更新能力，只需要下載變更的資源。
prefetch方案介紹
設計目標
分析了目前業界常用的離線包方案後，我們針對離線包的設計目標做了一輪梳理。一部分是前端團隊的訴求，一部分也是我們期望實現的目標：
低侵入性
• H5低侵入 - 接入離線包無需做額外適配，儘可能對於前端做到無感知。一方面可以減少前端適配成本和代碼複雜度，另一方面也有利於我們更好去推動覆蓋更多的 H5 網頁
• 原生無侵入 - 不需要使用特定的WebView容器
低維護成本
因為離線包涉及到資源的提前下載，所以需要提前配置好需要使用的資源URL用於下載。現有方案通常需要一個平台去管理這些資源，針對每一個需要使用離線包能力的H5頁面，配置相關的靜態資源文件URL列表。但是會帶來一個問題就是每次更新都需要人工去維護整個靜態資源URL列表，我們希望儘可能避免人工去維護
個人看法：這裏更好的方式是離線包系統和前端發佈系統打通，發佈時自動更新靜態資源列表到離線包資源管理系統。
低運行時消耗
• 低網絡消耗 - 只下載必要的資源，避免無用資源下載，重複資源下載。
• 低CPU/內存 - 儘可能少的內存和CPU消耗，當不使用時做到零負荷
實現複雜度低
• 後台管理系統 - 由於人力的問題暫時沒辦法支持開發一個完整的離線包後台管理系統
• 客户端容器 - 客户端的實現儘可能簡單，可以更快速的上線同時避免帶來額外的問題
具體實現
實現思路是利用H5瀏覽器自帶的prefetch能力。通過將離線包資源聚合到單個HTML中，APP啓動後使用WebView提前加載HTML，WebView會下載資源到設備中。同時可以直接複用WebView自帶的離線緩存能力和差異化資源更新能力。
prefetch.html
<html>
<head>
<!--公共資源-->
<link rel="prefetch" href="https://wq.360buyimg.com/js/common/dfd0ab35.js">
<link rel="prefetch" href="https://wq.360buyimg.com/data/fontRegular.ttf">
<!--A頁面資源-->
<link rel="prefetch" href="https://wq.360buyimg.com/jxpp/app.css">
<link rel="prefetch" href="https://wq.360buyimg.com/data/min.js">
</head>
<body></body>
</html>
複製代碼
H5 離線包資源聚合
前面有提到不希望讓H5業務開發同學手動管理維護離線包資源，所以我們希望提供一種自動聚合資源的能力。減少後續維護成本的同時儘可能減少資源的下載。
判定是否開啓離線包
和線上H5性能監控系統打通，根據訪問次數和TOP排名來自動判定是否開啓離線包預加載
部分 H5 如果需要預熱可以額外添加
聚合資源
• 根據實際加載情況統計出需要預下載的資源比人工維護更加準確
• 被多個H5引用的資源自動判定為公共資源
提示：通常資源管理，特別是公共資源長期維護之後更難管理，很多時候添加之後不知道是否有被使用不會刪除。
資源聚合流程
通過運行自動化腳本的方式，基於Puppeteer和Performance TimingAPI，自動計算出需要下載的離線包資源及時更新。
如何判定首屏資源
使用瀏覽器自帶的PerformanceTiming API判定。domInteractive是瀏覽器完成對所有HTML的解析並且DOM構建完成的時間點。在domInteractive之前加載的資源既為阻塞首屏渲染的資源。同時需要過濾掉一些不需要緩存的資源，目前我們只收集JS/CSS會阻塞渲染的資源。
客户端
客户端實現相對簡單，APP 啓動後初始化一個新的WebView容器後台靜默加載，Android端加載prefetch.html，iOS端加載preload.html。加載完成後釋放WebView容器，之後不會造成其他性能損耗。雖然每次啓動都會重新觸發下載邏輯，但是隻會進行差異化下載本地緩存中不存在的資源文件。
其他優化
提前加載 WebView
因為 APP 啓動後首次初始化WebView會包含Web引擎的初始化，初始化耗時會更高。所以我們預下載資源時也提前初始化了WebView，之後打開H5時可以減少100-200ms初始化耗時。
提前打通登錄態
因為大部分業務H5都需要登錄態，所以APP在首次打開H5時，需要將原生登錄態信息同步到 H5cookie中，會有1次額外的302跳轉耗時。我們在預加載資源時提前打通登錄態，之後打開H5時可以減少100-200ms302跳轉耗時。
接口預拉取
同時也提供了接口預拉取的能力，可以H5加載前提前拉取首屏接口數據，提高加載速度。
實現過程中遇到的問題
iOS系統
不支持prefetch
iOS系統web內核並不支持prefetch特性，所以針對iOS我們採用preload來代替。Android平台下發link-prefetch，iOS平台下發link-preload進行差異化處理。
提示：prefetch相比preload性能更好。prefetch下載的優先級沒有preload高，避免影響其他網絡請求速度。preload會將JS/CSS進行解析添加到內存，造成一定的額外消耗。
preload 不支持 HTML
iOS系統preload特性並不支持HTML Document的提前加載。不過這一點對於我們影響不大，因為目前我們業務H5的HTML通常會做一定的服務端渲染邏輯，並不支持緩存策略。(例如聚合一部分的公共 JS)
多域名資源不共享
iOS系統中WebView針對不同域名H5使用的其他資源並不能共享。例如https://www.jd.com/index.html和https://www.jingxi.com/index.html雖然是同一個網頁，內部都有使用同樣的JS/CSS/圖片資源，但是基於iOS 系統中WebView緩存策略實現，每一個域名的資源使用獨立的空間管理，並不能共享使用需要重複下載。因為我們自身H5支持jd.com和jingxi.com雙域名訪問，所以我們在APP端添加了域名替換的邏輯，儘可能將我們自身的業務收斂到jingxi.com域名，提高緩存資源利用率。
提示：即使不使用離線包，這也是一個不錯的優化策略。
Android 系統
磁盤空間不足觸發Crash
部分設備在使用prefetch下載資源時，因為設備本身磁盤空間不足導致Crash。所以我們在資源下載前加了一個額外的磁盤空間檢查策略，當磁盤空間太低時不進行下載。
總結
prefetch 方案
我們通過利用系統瀏覽器自身提供的prefetch預加載資源能力和HTTP離線緩存能力，實現了一套相對輕量的離線包解決方案，H5首屏性能提升基本上和其他方案一樣(除了iOS系統上不支持HTML離線資源)。同時通過離線資源自動統計/自動更新的方式，不需要額外的離線包資源管理系統，減少後續的維護成本。
這套方案雖然在實現成本和維護成本上相對比較低，但是因為實現方式的選擇也存在一些不足需要後續完善。例如無法攔截網絡請求擴展更多能力，同時依賴瀏覽器自身的緩存策略也存在一些不可控，例如Android端瀏覽器內核過多，資源需要完全遵守HTTP緩存策略。同時離線資源自動統計/自動更新能力並不容易抽象出一套標準化的方案適用於不同公司的業務。但是技術實現方案通常都是在做各種權衡和取捨，這是我們認為目前相對低成本的一套實現方案。
離線包的價值
個人認為提前下載資源的離線包方式帶來的首屏加載收益並沒有那麼高。原因如下：1.提前下載過多離線資源也會帶來更多的網絡消耗。2.大部分頁面本身不具備離線使用的能力（需要網絡訪問接口）。3.離線包也只是優化第一次加載的速度，因為資源本身就可以設置HTTP的緩存策略避免重複下載。H5頁面首屏加載應該更多關注頁面本身的渲染性能，例如JS/CSS解析耗時，直出還是非直出，首屏接口速度等。
更有價值的在我們如何通過攔截網絡請求增強更多的能力，例如提供HTTPDNS，原生/H5複用圖片緩存等能力。
擴展鏈接
• WKWebView 請求攔截探索與實踐
• 評估關鍵渲染路徑
• 離線Hybrid容器如何做到接近100%秒開？
• prefetch特性支持
• preload特性支持
• WKWebView離線化方案——實現Service Worker API
