前言
對於電商APP
來講,使用H5
技術開發的頁面佔比很高。由於H5
加載速度非常依賴網絡環境,所以爲了提高用戶體驗,針對H5
加載速度的優化非常重要。離線包
是最常用的優化技術,通過提前下載H5
渲染需要的HTML/JS/CSS
資源,加載時直接使用本地緩存資源避免額外的網絡請求提高加載速度。本文主要是介紹團隊在離線包技術方案上的探索,以及基於prefetch
的離線包實現方案如何減少維護成本和開發成本。
現有方案
離線包技術發展到現在已經比較成熟。離線包技術主要是分爲兩部分,一部分是客戶端離線包容器,另一部分是線上離線包平臺。
離線包容器
資源請求攔截
- 攔截H5
資源請求,當存在本地緩存資源時直接返回使用
資源緩存
- 資源下載、資源緩存策略、增量更新策略
離線包平臺
資源管理
- 配置H5
頁面對應的離線資源、公共離線資源、CDN
存放離線資源包
發佈系統
- 實時發佈、灰度能力、版本控制
下面先介紹一下常見的技術實現方式:
資源請求攔截方式
Android
Android
實現相對比較統一,主要是通過WebView
自帶的shouldInterceptRequest
API 攔截資源請求,返回對應的離線資源即可實現離線包
功能。
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協議
- 因爲WKURLSchemeHandler
API 本身的設計,只能攔截自定義協議並不支持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 Timing
API,自動計算出需要下載的離線包資源及時更新。
如何判定首屏資源
使用瀏覽器自帶的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-200ms
302跳轉耗時。
接口預拉取
同時也提供了接口預拉取的能力,可以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
複用圖片緩存等能力。