视差效果介绍和使用(2)

DevTools 在单个框架中显示大型绘制和多个事件触发的布局。
要记住的重要一点是，要达到 60fps（与 60Hz 的典型显示器刷新率相匹配），我们只需超过 16 毫秒即可完成所有工作。 在第一个版本中，我们每次收到滚动事件时都会执行视觉更新，但正如我们在之前的文章中讨论的那样，使用 requestAnimationFrame 和滚动性能 ，这与浏览器的更新计划不一致，所以我们要么错过帧，要么在每个帧中做太多的工作。 这很容易给您的网站带来不自然和不自然的感觉，从而导致用户失望和小猫不开心。
让我们将更新代码从滚动事件移到一个requestAnimationFrame回调并简单地在滚动事件的回调中捕获滚动值。 我们的第二个演示 展示了这一点。
如果您重复滚动测试，您可能会注意到轻微的改进，尽管不多。 原因是我们通过滚动触发的布局操作并不是那么昂贵，但在其他用例中确实可能如此。 现在至少我们 一个布局 在每一帧

DevTools 在单个框架中显示大型绘制和多个事件触发的布局。
我们现在可以每帧处理 1 个或 100 个滚动事件，但至关重要的是，我们只存储最新的值，以便在 requestAnimationFrame回调运行并执行我们的视觉更新。 关键是您已经从每次收到滚动事件时都尝试强制视觉更新转变为请求浏览器为您提供适当的窗口来执行这些更新。 你不甜吗？
这种方法的主要问题，requestAnimationFrame与否，是因为我们基本上为整个页面设置了一层，并且通过移动这些视觉元素，我们需要大量（且昂贵）的重绘。 通常来说，绘画是一个阻塞操作（尽管这种情况正在改变 ），这意味着浏览器不能做任何其他工作，而且我们经常超出框架的 16 毫秒预算，事情仍然很卡顿。

选项 2：使用 DOM 元素和 3D 变换

除了使用绝对位置，我们还可以采用另一种方法，即对元素应用 3D 变换。 在这种情况下，我们看到应用了 3D 变换的元素为每个元素赋予了一个新层，并且在 WebKit 浏览器中，它通常还会导致切换到硬件合成器。 相比之下，在选项 1 中，我们为页面设置了一个大图层，当发生任何变化时需要重新绘制该图层，并且所有绘制和合成都由 CPU 处理。