前言
對于電商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
復用圖片快取等能力,
擴展鏈接
? WKWebView 請求攔截探索與實踐
? 評估關鍵渲染路徑
? 離線Hybrid容器如何做到接近100%秒開?
? prefetch特性支持
? preload特性支持
? WKWebView離線化方案——實作Service Worker API
轉載請註明出處,本文鏈接:https://www.uj5u.com/qianduan/554466.html
標籤:HTML5
下一篇:返回列表