关于丢帧和 requestAnimationFrame 的混淆

Question

请随意指出我的以下理解是否错误：假设我们的显示刷新率为60hz（我知道情况并非总是如此，但我们假设它是60hz），那么网页将每秒刷新屏幕60次，如果一切顺利。这意味着渲染以 16 毫秒的间隔（大约）发生，对吗？因此，我们的 JavaScript 中执行时间超过 16 毫秒的任何内容都会给用户带来卡顿的体验。所以我的问题是：

1. 假设我们有一个函数handleScroll，从开始到结束执行需要 100 毫秒。我们将其添加到addEventListener('scroll', handleScroll). 每当事件触发时，由于渲染周期中跳过/丢弃6 帧，scroll用户是否会遇到卡顿体验？因为 100 毫秒 / 16 毫秒 = 6.25？我知道一个任务在主线程上花费很长时间，它会停止所有其他任务直到完成，但在这里我想获得一些定量分析或定性分析方法来解决此类性能问题。具体来说，我想了解（粗略地）这样的回调会丢失多少帧（如果刷新率为 60hz）
2. 我认为requestAnimationFrame告诉浏览器在渲染下一帧之前运行回调，所以我看到人们提到它可以防止动画丢帧。但我不清楚它会如何帮助解决这个问题，因为我们传入的回调requestAnimationFrame仍然会运行完成，所以如果回调花费超过 16 毫秒，我们将不可避免地错过下一帧，对吗？

Answer 1

1. 是的，在这种情况下，您的射击速度将handleScroll远低于 60 fps - 取决于您的handleScroll回调正在执行的操作，您的用户可能会遇到一些卡顿。

2. requestAnimationFrame会尽力维持60fps，但不保证60fps。根据可用的 CPU、GPU、内存和其他限制，它的运行速度可能会慢得多。

请注意，即使它确实以 >60fps 运行，也会为您提供（正如您所指出的）16-17 毫秒的帧预算来执行回调操作。

因此，如果您的回调需要 100 毫秒执行，那么即使使用requestAnimationFrame. Chrome 的性能开发工具 可以帮助您确定导致动画延迟的原因，但您需要优化回调以使其运行时间少于 17 毫秒，以防止丢帧。

查看这篇文章以获得更深入的分析