QQ音乐客户端Web页面通用性能优化实践

基于本次优化的背景，本次优化提出以下两方面的目标：增强通用性、减少前端改造成本。

二、指标设计

在展开优化思路和实施的同时，需要建立衡量优化效果的性能指标。

1. 客户端现有性能指标数据

接下来基于客户端内 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

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数前端工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Web前端开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上前端开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注：前端）

最后

今天的文章可谓是积蓄了我这几年来的应聘和面试经历总结出来的经验，干货满满呀！如果你能够一直坚持看到这儿，那么首先我还是十分佩服你的毅力的。不过光是看完而不去付出行动，或者直接进入你的收藏夹里吃灰，那么我写这篇文章就没多大意义了。所以看完之后，还是多多行动起来吧！

可以非常负责地说，如果你能够坚持把我上面列举的内容都一个不拉地看完并且全部消化为自己的知识的话，那么你就至少已经达到了中级开发工程师以上的水平，进入大厂技术这块是基本没有什么问题的了。

目、讲解视频，并且会持续更新！**

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注：前端）

[外链图片转存中…(img-QeTYPrXn-1713551566592)]

最后

今天的文章可谓是积蓄了我这几年来的应聘和面试经历总结出来的经验，干货满满呀！如果你能够一直坚持看到这儿，那么首先我还是十分佩服你的毅力的。不过光是看完而不去付出行动，或者直接进入你的收藏夹里吃灰，那么我写这篇文章就没多大意义了。所以看完之后，还是多多行动起来吧！

可以非常负责地说，如果你能够坚持把我上面列举的内容都一个不拉地看完并且全部消化为自己的知识的话，那么你就至少已经达到了中级开发工程师以上的水平，进入大厂技术这块是基本没有什么问题的了。

资料领取方式：戳这里前往免费领取