如果我的以下理解有误，请随时指出:假设我们的显示刷新率为 60hz(我知道并非总是如此，但我们假设它是 60hz)所以网页每秒刷新屏幕 60 次如果一切顺利。这意味着渲染以 16 毫秒的间隔(大约)发生，对吗？因此，我们的 JavaScript 中执行时间超过 16 毫秒的任何内容都会给用户带来不便的体验。所以我的问题是:
handleScroll从开始到结束执行需要 100 毫秒。我们将其添加到 addEventListener('scroll', handleScroll) .是不是真的每当scroll事件触发，用户将体验到自 以来的卡顿体验6帧在渲染周期中被跳过/丢弃？因为 100 毫秒/16 毫秒 = 6.25？我知道一个任务在主线程上需要很长时间，它会停止所有其他任务直到它完成，但在这里我想得到一些 定量 对此类性能问题进行定性分析的分析或方法。具体来说，我想了解(大致)这样的回调将丢弃多少帧(如果刷新率为 60hz)requestAnimationFrame告诉浏览器在渲染下一帧之前运行回调，所以我看到人们提到它可以防止帧被丢弃以进行动画处理。但我不清楚自从我们传入 requestAnimationFrame 的回调函数后，它将如何提供帮助。仍然会运行到完成，所以如果回调花费超过 16 毫秒，我们将不可避免地错过下一帧，对吗？ 最佳答案
handleScroll远低于 60 fps - 取决于您的 handleScroll回调正在执行，您的用户可能会遇到一些卡顿。requestAnimationFrame会尽量保持60fps，但不保证60fps。根据可用的 CPU、GPU、内存和其他限制，它可能会运行得更慢。请注意，即使它确实以 >60fps 的速度运行，这也会为您(如您所指出的)提供 16-17 毫秒的帧预算，其中
执行您的回调操作。
因此，如果您的回调需要 100 毫秒
执行，那么你甚至无法获得流畅的 60fps 动画
使用
requestAnimationFrame . Chrome 的 performance dev
tools可以帮助您确定导致动画延迟的原因，但这取决于
你优化你的回调在不到 17 毫秒内运行，以防止
丢帧。
Check out this article for a more in depth breakdown
关于javascript - 关于丢帧和 requestAnimationFrame 的困惑，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/69078974/