一、WebView加载H5页面整体时间线(仅提取了重要时间线)
1、start -> 2. Activity onCreate 、webview实例化 -> 3、loadUrl/loadHtml -> 4、pageStart、js/html解析 -> 5、H5 DomContentLoaded event事件回调 -> 6、前端部分block渲染逻辑及网络处理 -> 7、前端dom首屏渲染事件回调 -> 8、pageFinish -> 9、页面展示
其中1~3为客户端事件节点、3~7为前端加载节点、8之后为客户端节点
通过上述时间线,可以清晰的看到一些常见的页面到达率/速度的定义,实际上页面真正渲染完成是在6位置。但市场上各公司采用的到达率的定义各不相同,一般有以下几种:
- 序号1、8位置进行打点;这种比较常见,主要是客户端代码较少。但是这种8的打点丢失率比较高,而且pageFinish回调是有可能多次调用的,其实并不是很准。实际时机也相对靠后
- 序号1、6位置进行打点;这种较准但是需要客户端以及前端配合,通过客户端及前端打点时增加同一字段(可在客户端产生随机ID,注入到js字段然后使用相同id打点)进行上报
- 序号1、5位置进行打点;这种操作是性价比最高的一种,纯客户端逻辑,较推荐。通过js注入方式hook 前端`DomContentLoaded` 事件,或者直接在activity destory时通过js注入捞取 `window.performance.timing` 的DomContentLoaded时间节点进行上报
更多前端节点可以通过浏览器console中输入以下命令查看:
window.performance.timing
想了解更多前端时间线可以点击此网址:PerformanceTiming - Web API 接口参考 | MDN
二、H5加快速度常见解决方案
-
H5页面自加速(H5为非三方时)
- 其实H5加速本身就是前端、客户端协作的一件事,如果前端页面为自己公司的页面,也可以从优化前端页面加载速度本身出发,这一点常常被忽略
- 前端速度Google其实有很通用的标准:Lighthouse(下图一是百度H5的报告)、performance(下图二位百度性能节点)
- 前端优化方案也有很多,比如:
- PWA(service worker)
- base64首屏加速
- 骨架屏
-
WebView实例缓存池(代表:头条、百度,很多公司都在处理)
- 通过池管理webview,减少webview实例化时间(android原生webview冷启300~500ms,热启webview100~200ms)
- 提前对webview进行预热,提价加载对应的js前端框架
-
拦截图片资源,使用初始底图显示,然后异步更新h5图片(代表:头条)
- 头条样例:Android H5秒开方案调研—今日头条H5秒开方案详解 - 简书
- 解决的问题:防止图片网络请求,阻塞webview线程加载资源
-
自定义离线缓存,解决WebView缓存size瓶颈
- 默认webview cache size 小于4.4 10M,大于4.4 20M :https://android.googlesource.com/platform/external/webkit/+/jb-mr2-release/Source/WebKit/android/WebCoreSupport/WebCache.cpp
- 通过WebView拦截回调,自定义拦截资源加载,自定义实现资源、索引二级缓存。可使用okhttp代理,但是大数据量可能有性能问题(数据请求串行执行),或者原生webview使用的db方式管理缓存,更快速。好处是cache规则不需要自己管理,可快速接入
- 需要注意的是需要兼容处理Http的过期策略(headers: Last-Modified、ETag、Cache-Control 、Expires等),否则则会出现页面不更新或者更新不及时、生产环境加载正常线上加载失败页面错乱等问题
-
离线包方式。前端除时效性较高资源其他资源离线打包,减少即时网络请求(代表:结合业务场景若干)
- 需要处理动态域名,解决跨域问题
- 离线包单包、多包问题
- 对前端打包有侵入性
-
WebView内核优化(代表:腾讯、百度,成本大不适用于小公司)
- 腾讯x5,官网是说可优化速度,但本人未做过调研
- 内核层面自定义缓存管理
-
Html提前到第1步开始下载,本地和网络做diff,差量更新(代表:腾讯)
- 腾讯开源框架:https://github.com/Tencent/VasSonic/blob/master/assets/sonic%E5%8F%91%E5%B1%95%E5%8E%86%E7%A8%8B.md
- 缺点:业务侵入性太大。需要后端、前端、native整体改造
-
预加载/预热资源
- 提前在闲时进行资源的局部、全部预加载,方式可根据自己的技术方案进行处理
- 优势:大幅度提升显示速度
- 缺点:
- 需要根据机型性能管理内存、磁盘缓存
- 需要管理预加载时机,尽量闲时预加载
- 对数据的时效性也要把关
-
网络请求提前。数据提前在步骤1时提前加载,步骤7时直接使用。如下图所示
- 优势:可和步骤1~6并发处理
- 缺点:和h5业务耦合性比较大,需要处理极端情况。需客户端及前端耦合多,后续维护成本会很大,要根据业务评估可行性,一般不推荐
上述方案中所提到的大厂方案技术网址:
- 美团:WebView性能、体验分析与优化 - 美团技术团队
- 腾讯:VasSonic
- 头条:Android H5秒开方案调研—今日头条H5秒开方案详解 - 简书
- 百度:百度APP-Android H5首屏优化实践
欢迎有问题、结论评论补充。以上具体方案实现细节有兴趣的可以私聊沟通