需要开发者反馈 - Frame Timing API

Paul Lewis

在过去的几年里,浏览器在渲染性能方面取得了巨大进步,尤其是在移动设备上。以前,你无望为任何遥远复杂的事物实现流畅的帧速率,但现在只要你细心考虑,至少可以实现。

不过,对大多数人来说,我们能在自己的设备上合理地测试的内容与用户体验之间存在脱节。如果他们不能获得流畅的 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 尚未推出,但应该很快就会推出。在此期间,您可以阅读以下内容并执行以下操作: