在过去的几年里,浏览器在渲染性能方面取得了巨大进步,尤其是在移动设备上。以前,你无望为任何遥远复杂的事物实现流畅的帧速率,但现在只要你细心考虑,至少可以实现。
不过,对大多数人来说,我们能在自己的设备上合理地测试的内容与用户体验之间存在脱节。如果他们不能获得流畅的 60fps,那么他们的体验将会受到影响,最终他们将去其他地方,我们将陷入困境。此外,W3C 正在讨论一款可以帮助我们了解用户所见内容的新 API:Frame Timing API。
我和 Jake Archibald 最近录制了一段有关该 API 的视频概览,如果您更喜欢阅读相关内容,可以看一下:
Frame Timing API 的用法
毫无疑问,您可以使用 Frame Timing API 完成许多操作,而最重要的是,您可以衡量对您和项目重要的指标。即便如此,我也可以参考以下建议:
- 跟踪 JavaScript 和 CSS 动画的 fps。
- 跟踪页面滚动(或者您拥有的无限滚动列表)的流畅性。
- 根据设备的当前负载自动缩容节目效果。
- 对运行时性能指标的回归测试。
电梯间推销
该 API 目前在规范中的显示如下:使用该规范,您可以提取关于运行 JavaScript、样式和布局的渲染器线程时间的数据。(您可能听说过,渲染程序线程称为主线程;它跟其名是一样的。)
var rendererEvents = window.performance.getEntriesByType("renderer");
您得到的每条渲染程序线程记录大致如下所示:
{
sourceFrameNumber: 120,
startTime: 1342.549374253
cpuTime: 6.454313323
}
每条记录实质上是一个对象,其中包含一个唯一帧号、一个关于帧何时开始的高分辨率时间戳,以及另一个关于其所用 CPU 时间的对象。通过这些数组,您可以查看每个 startTime
值,并了解主线程的帧速率是否为 60fps;实质上,“每个帧的 startTime
在大约 16 毫秒的块中提升吗?”
除此之外,您还可以获取 cpuTime
,从而了解自己是在 16 毫秒的边界内是否舒适自如,还是没连上电线。如果 cpuTime
正好接近 16 毫秒的边界,就没有太多空间来完成垃圾回收等,并且 CPU 使用率较高时,电池消耗也会增加。
除了渲染程序线程之外,您还可以提取有关合成器线程时间的数据,绘制和合成发生在这些线程中:
var compositeThreadEvents = window.performance.getEntriesByType("composite");
每个线程还会附带一个源帧号,您可以使用该帧号将其与主线程的事件相关联:
{
sourceFrameNumber: 120,
startTime: 1352.343235321
}
由于浏览器中的合成通常运作方式,每条渲染器线程记录可能会存在多条此类记录,因此您可以使用 sourceFrameNumber
将这些记录重新关联起来。关于是否应该在这些记录中也包含 CPU 时间,也有一些讨论,因此,如果您非常想举报 GitHub 问题,可以大胆直言。
更多信息
此 API 尚未推出,但应该很快就会推出。在此期间,您可以阅读以下内容并执行以下操作:
- 阅读代码库上的说明文档。关于如何以最佳方式记录帧数据才能使其变得有意义,有很多细微差别,此处的解释者会给出一些指导。
- 查看规范的最新草稿。该规范比较精简,非常值得一读。
- 提交有关缺少功能或潜在问题。您知道自己想要衡量的指标,因此,如果您认为自己需要使用 API 执行某些无法实现的操作,请提供反馈。