前言
對于電商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
轉載請註明出處，本文鏈接：https://www.uj5u.com/qiye/554468.html
標籤：其他
下一篇：返回列表