使用“Frames”进行Web检查器分析：当时间轴上没有任何内容时，找到性能问题的原因。

Question

我刚刚观看了Google I/O会议的Jank Busters：构建高性能Web应用程序，演讲者解释了如何使用Chrome Web检查器时间轴中的新“框架”视图。

这是我在正在开发的页面上滚动时得到的一个示例记录：

正如您所看到的，某些帧存在巨大的延迟，但时间轴中没有明显的原因（黄色“计时器触发”事件之间存在大的间隔）。 我该如何排除性能问题以持续增加帧速率？

- Sophie Alpert

---

那是哪个版本的Chrome？我有20.0.1132.57，但在时间轴选项卡下看不到框架部分。 - Mark

现在我在22 (dev channel)上。不确定它是否在21中。 - Sophie Alpert

Answer 1

你的示例看起来并不太糟糕。你的代码运行速度很快，浏览器只会以60fps渲染，因此它会花费一些时间（最高达16ms）等待下一次渲染循环。

以下是Chrome Dev Tools Timeline面板中Frames视图的一个特别令人担忧的快照。

根据文档：

• 灰色区域表示未被DevTools检测的活动，Chrome团队致力于将此区域尽可能缩小
• 清晰的区域表示在显示刷新周期之间的空闲时间，通常不会有问题，特别是如果该区域达到60fps线，因为这只是Chrome在等待在监视器的垂直同步上交付帧

底部条形图中几乎看不见的黄色和绿色区域表明事件处理、绘画和合成都运行得非常快——足够快到落在表示30fps阈值的水平线下，并且大部分时间都比60fps阈值更快（未显示线）。

要了解更多信息，请打开开发者工具选项并检查：

启用此选项后，您将在'RECORDS'栏中看到灰色区域：

每个灰色区域显示渲染线程被占用的时间段。如果您看到许多间隙，则浏览器可能受到GPU限制。

Chrome工程师Nat Duca在这篇文章中提供了更多信息：

GPU限制通常来自两个方面：

1. 具有-webkit-filter和preserve3D元素属性的元素会消耗GPU资源，类似于饥饿的东西。
2. 拥有太多大的图层。

图层？使用“显示组合图层边框”查看它们。大多数人遇到问题的地方并不是图层数量，而是图层的面积。

经验法则：大多数计算机设计为可以在主屏幕上每个像素上触摸约4次。举一个非常简单的例子，一台两年前的MacBook Air是根据其液晶显示器的尺寸进行配置的。当您插入一个具有多个图层的30英寸显示器时，它就开始受到GPU限制。

这为什么很重要？[手势，]当我们绘制屏幕时，一个图层会触摸一个像素。如果一个图层的大小与窗口大小相同，例如，您拥有一个width = 100％ height = 100％的div，并带有-webkit-transform：translateZ（0），那么您将触摸屏幕的每个像素一次。因此，统计您的图层面积，如果超过监视器面积的4倍，则可能无法进入空间[因为您受到GPU限制]。

检查GPU限制的好方法是将窗口大小每个维度减小1/2。如果速度仍然很慢，则可能发生其他事情...如果速度变快，则您可能正在受到GPU的限制。

在我的情况下（如上图所示），我仍在试图找出什么导致灰色条纹。代码没有改变，性能曾经很好。可能是Chrome的新版本（今天我运行的是31.0.1650.57 m）由于某种原因与此代码的性能表现不佳。再次说明，灰色区域表示渲染线程正忙于非记录代码，因此很难确定发生了什么。

- Drew Noakes

---

这种现象在新的ChromeDev工具时间轴UI（无帧视图）中会是什么样子？它是否会导致requestAnimationFrame在帧结束之前被一致调用？我开始认为我的GPU受限了，但我在不同的机器/操作系统上看到了这种行为。 - Stanislaw Osinski

Answer 2

我建议您使用http://pagespeed.googlelabs.com

它基本上会向您展示页面加载时发生了什么，以便您知道在哪里进行工作...（我还认为在某些情况下可能会错过某些信息）

此外，您应该对页面进行内存分析，以查看某些对象加载到内存中需要多长时间。

- Chibueze Opata

---

我曾经使用过Page Speed - 在我看来，Chrome已经在慢慢地将所有的Page Speed功能直接集成到Web Inspector中。这个扩展很有用，但我不认为它能提供更多关于这个特定情况的见解。 - Sophie Alpert

页面速度很快，但它更注重尽快加载页面，而上面显示的时间轴则涉及在页面运行期间发生的操作，也许是响应用户事件或动画计时器。 - Drew Noakes