Javascript OnScroll 性能对比

Question

更新：类似的问题有一个很好的答案，展示了如何以一种有用的方式使用 requestAnimationFrame 和滚动： scroll events: requestAnimationFrame VS requestIdleCallback VS passive event listeners

---

假设我想在我的网站上添加一些由滚动触发的昂贵操作。例如，我在 jsfiddle 中使用了视差效果。

现在我一直在读，它一定不能直接绑定到事件，有时后面跟着 sn-ps 是为了更好。只是一些例子：

1. Attaching JavaScript Handlers to Scroll Events = BAD!
2. How to develop high performance onScroll event?
3. How to make faster scroll effects?
4. 60FPS onscroll event listener

他们所说的基本上是不要这样做：

  // Bad guy 1
  $(window).scroll( function() {
    animate(ex1);
  });

或者这个

  // Bad guy 2
  window.addEventListener('scroll', onScroll, false);
  function onScroll() {
    animate(ex2);
  }

但是使用超时、间隔、requestAnimationFrame 之类的，例如：

  // Good guy
  $(window).scroll( function() {
   scrolling1 = true;
  });

  setInterval( function() {
    if (scrolling1) {
      scrolling1 = false;
      animate(ex3);
    }
  }, 50 );

因此，我将在上面链接中找到的选项添加到 jsfiddle 中，该 jsfiddle 尝试通过为每种方法添加计数器来比较它们，如下所示：

  // Test
  $(window).scroll( function() {
    counter = counter + 1;
    // output result of counter
    animate(ex1);
  });

最好检查完整的jsfiddle

结果：一切顺利进行的计算次数大致相同。如果我能忍受波涛汹涌的影响，也许我可以保护一些资源。与我阅读的所有内容相比，这对我来说似乎是合乎逻辑的！

第一个问题： 我错过了什么还是这是一个有效的测试？如果它无效，我该如何正确测试？ 编辑：澄清一下，我想测试一下上述方法是否能节省性能。

第二个问题： 如果它是有效的，为什么每个人都对 onscroll 感到紧张？如果流畅的动画需要对整个站点进行 5000 次计算，那么无论如何都无法更改它？

（嗯，有时我会使用检查来确定对象是否在视口中，但老实说，我什至不知道这些检查是否没有被阻止的代码本身那么昂贵，特别是如果它们涉及五个不同的offset、windowHeight、scrolltTop、getBoundingClientRect 和 outerHeight 等变量...)

Answer 1

所以，@SirPeople 已经正确回答了你的第一个问题，这确实是一个很好的测试来查看 animate 函数被调用的频率，但它是一个不好的测试来比较不同 sn-ps 的性能。

这是执行的性能记录：

函数animate 一点也不贵。我拍了一张性能记录（下一张图片），它显示在我查看的一次迭代中它花费了 0.64 毫秒到 1.29 毫秒（第 1-5 点）。并且一旦函数完成，重绘完全不需要时间（第 6 点），这可能是因为页面几乎没有内容。当我们查看时间时，我们可以看到所有五个动画函数和重绘都发生在不到 10 毫秒的时间内，这意味着在正常情况下，我们可以获得流畅的 60fps 动画（第 7 点）。

此外，如果我们想比较 onscroll 事件侦听器，我们需要单独测试每个侦听器并比较结果。如果其中一个监听器真的阻塞了，它会对整个页面产生影响，如果没有性能调试，你将不知道它是哪一个。

我做了两个 jsfiddles window.scroll 和 RAF。而且，令我惊讶的是，似乎没有任何区别。

为什么人们会关心这个？

正如您在上面链接的 jsfiddles 中看到的，如果事件处理程序变得太大，整个页面将会滞后。

现在呢？

我自己不是表演大师，但是：

• 也许其他解决方案之一是正确的
• 我们可以将您的事件侦听器标记为被动，尽管在我的test 中它并没有真正改善 https://developers.google.com/web/updates/2016/06/passive-event-listeners
• 我们可以通过移除视差效果来优化事件监听器
• 还有一个叫做 Intersection Observer 的新东西，它应该更快，我没有测试它 https://developer.mozilla.org/en-US/docs/Web/API/Intersection_Observer_API

Answer 2

我不完全确定我是否正确地回答了你的问题和你的所有陈述，但我会尽力给你一个答案：

• 是我遗漏了什么还是这是一个有效的测试？如果无效，如何正确测试？

如果您正在测量函数被调用的次数，这是一个有效的测试，这当然取决于浏览器，所以，如果 GPU 增强以及您的问题中已经评论的其他一些基准参数.

如果我们认为测量正确，那么可以说通过使用超时或 requestAnimationFramework 可以节省时间，因为我们基本上遵循debouncing or throttling 的原则。基本上，我们不想请求或调用一个函数的次数超过需要的次数。在计时器的情况下，我们将排队较少的函数调用，而在requestAnimationFrame 的情况下，因为它在重新绘制之前将调用排队并按顺序执行它们。在超时时，如果计算量很大，可能会发生重叠。

我在why using requestAnimationFrame 中找到了更好的答案，解释了浏览器中动画的主要问题，例如剪切、闪烁或跳帧。它还包括一个很好的演示。

我认为你的测试方法是正确的，你也应该正确解释它，也许因为你的硬件和你的引擎，调用接近于相同的数字，但正如所说，去抖动和节流是一种性能缓解。

Here also one more article supporting not attach handlers to window scroll from Twitter。 （免责声明：本文来自 2011 年，浏览器以不同方式处理滚动优化）。

• 为什么每个人都对 onscroll 感到紧张？如果流畅的动画需要在整个站点上进行 5000 次计算，那么无论如何都无法更改它？

我不认为性能受到影响，但是对于上述动画问题，您的滚动调用可能会导致用户体验最差，或者即使您的计时器不同步，您仍然可以获得同样的“性能”问题。人们只是建议保存呼叫以滚动，因为： 人类的视觉持久性不需要超高的帧率，因此尝试更频繁地显示图像是没有用的。 对于更复杂的计算或繁重的动画，浏览器已经在进行优化，就像您检查过的那样，与 2、3 或 6 年前您公开的文章相比，有些 browsers had optimize this things。