接下来基于客户端内 Web 页面加载过程,描述客户端现有性能指标代表的时机。
(1)客户端 WebView 回调
基于 Android WebView 的过程监控回调和页面框架能力,可以实现的性能监控包括:
其中,
onMainFrameFinished
取第一个非主请求 (HTML) 的资源被拦截的时机。对于绝大多数页面来说,此时已经完成主请求 (HTML) 的下载,并已经开始解析;可以粗略代表主请求流程结束。
(2)W3C Performance Timing
与客户端回调相比,W3C Performance Timing 提供了更细致的加载过程信息,但是不包含 WebView 开始初始化的时间点。下图中仅列出部分:
2. 各端单独采集的局限
(1)前端采集的局限
-
无法独立获取 WebView 开始初始化的时间点。
-
想获取最精确的加载完成时间点,主要依赖手动埋点。
(2)客户端采集的局限
SSR (服务端渲染) 和 CSR (客户端渲染),页面内容可消费的时间点不一致。
对 WebView 页面加载周期来说:
-
CSR 页面需在前端页面框架加载后再展示数据,内容请求完成并上屏,发生在页面加载完成之后
-
SSR 页面的首次内容上屏可携带首屏数据,因此在页面加载完成之前,页面内容已经可以被消费
客户端回调时机不够完整或过于“苛刻”,测不准“页面内容可消费”的时间点。
通过追溯客户端 onPageFinished 的回调时机,发现对应的 Blink 代码要求必须满足:页面解析完毕、 没有正在下载的资源等条件。
按照这个标准,一旦存在某个图片一直处在加载中,但页面框架的其他内容均已处理完毕,onPageFinished 回调也会等待图片加载完成才回调,与实际上的 “页面内容可消费” 时间点存在差异。
3. 指标设计方案
结合上述分析,可以确定:
-
最准确的页面加载完成时机来自前端
-
最准确的 WebView 初始化时机来自客户端
因此,完善的耗时测量需由客户端和前端协同完成。
(1)前端侧
前端自行完成结束时间点的设置,并从客户端获取 WebView 初始化时间点,统计上报打开耗时。
-
前端通过手动埋点或监听 DOM 节点数变更,获取加载完成时间点。
-
前端统计时调用客户端提供 JSAPI,获取以 WebView 初始化时间点作为起点的耗时。
-
并由前端完成加载耗时的计算和统计上报。
(2)客户端侧
作为一个补充方案,客户端可以通过 JavaScript 注入获取上述 W3C Performance Timing 中的 domInteractive 时间点,作为结束时间点。
- 前端
domInteractive
时,已完成所有页面展示必需资源的请求和处理
- 耗时的差异,可以体现任何页面的客户端通用优化效果
- 可以衡量SSR(服务端渲染) 页面的可消费耗时,和CSR(客户端渲染)页面的首帧耗时
webView.evaluateJavascript( script = “(function(){return performance.timing.domInteractive;})();”, callback = { value -> responseEndDuration = value.toLong() - getOnCreateTimestamp() } )
虽然 WebKit 负责维护 Performance Timing 的值,但是 WebView 并未提供接口获取上述时间点的值。
三、优化方案和效果
1. 优化方案概述
基于客户端内 Web 页面的加载流程,从 “WebView 初始化耗时优化”、“资源加载耗时优化”、“逻辑处理耗时优化” 三个方面,提出了 5 个优化项。
-
TBS (X5 内核) 环境预加载
-
WebView 实例池
-
主请求并行加载
-
Web 公共资源池
-
跟肤逻辑优化
各优化项在 Web 页面加载过程中的生效时机如下:
2. 优化手段说明
(1)WebView 初始化
经过前期分析,WebView 初始化耗时本身的耗时压缩空间比较有限。因此优化手段主要以初始化逻辑前置为主。例如,“WebView 实例池” 通过在应用位于后台、主线程卡顿影响不明显的时机进行 WebView 预初始化,置换启动 Web 页面时的初始化耗时。
(2)客户端自建缓存
为了实现前述各项资源加载优化,客户端需要独立于 WebView 的缓存机制,自建一个资源缓存。
自建缓存参考客户端常用的三级缓存机制,基于 WebView 的强生命周期,设计了 “冷-热缓存循环” 的缓存生命周期。
例如,在 WebView 初始化的同时,自建缓存把页面需要的资源从文件系统加载到内存;向 WebView 资源拦截回调输入字节流时,自建缓存一定从内存缓存中输出,输出完毕后即可立即从内存缓存中被清除。这一机制可以使内存缓存的淘汰更积极,字节流在内存中停留的时间更短,减少内存占用。
(3)公共资源内联
在完成公共资源池开发后,页面打开耗时出现了负优化的情况。经过分析,确定与资源拦截回调的性能瓶颈有关。
-
单线程模型导致读写性能下降
-
被拦截资源的数量越多,对性能的影响越容易被放大
因此,为了减少资源拦截回调的性能影响,从减少拦截次数的角度,引入了公共资源内联优化。
-
公共资源加载到热缓存后,转换为对应的 HTML 节点
-
主请求并行加载完成后,直接在主请求字节流中替换其对应的外联节点;替换后的新字节流返回 WebView
最后
开源分享:【大厂前端面试题解析+核心总结学习笔记+真实项目实战+最新讲解视频】
降
- 被拦截资源的数量越多,对性能的影响越容易被放大
因此,为了减少资源拦截回调的性能影响,从减少拦截次数的角度,引入了公共资源内联优化。
-
公共资源加载到热缓存后,转换为对应的 HTML 节点
-
主请求并行加载完成后,直接在主请求字节流中替换其对应的外联节点;替换后的新字节流返回 WebView
最后
开源分享:【大厂前端面试题解析+核心总结学习笔记+真实项目实战+最新讲解视频】