基于 prefetch 的 H5 离线包方案 | 京东云技术团队
前言
对于电商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
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
复用图片缓存等能力。
扩展链接
• 评估关键渲染路径
版权声明: 本文为 InfoQ 作者【京东科技开发者】的原创文章。
原文链接:【http://xie.infoq.cn/article/fe5bb456a64469623ffc208fd】。文章转载请联系作者。
评论