如何优化 requestAnimationFrame 中的 JavaScript 逻辑以达成 120Hz 渲染

小伙伴们对文章编程感兴趣吗？是否正在学习相关知识点？如果是，那么本文《如何优化 requestAnimationFrame 中的 JavaScript 逻辑以达成 120Hz 渲染》，就很适合你，本篇文章讲解的知识点主要包括。在之后的文章中也会多多分享相关知识点，希望对大家的知识积累有所帮助！

requestAnimationFrame 默认达不到120Hz，因其帧率受显示器刷新率、浏览器调度及JS执行耗时共同制约；单帧超8.3ms即掉帧，需用Performance面板定位强制布局、高频DOM操作等性能瓶颈。

为什么 requestAnimationFrame 默认达不到 120Hz？

requestAnimationFrame 本身不决定帧率，它只是“在下一帧绘制前通知你”。实际帧率由显示器刷新率、浏览器调度策略和你的 JS 执行耗时共同决定。即使设备支持 120Hz，只要单帧 JS 逻辑超过 ~8.3ms（1000 ÷ 120），就会掉帧——浏览器会跳过某些回调，导致视觉卡顿或动画不顺滑。

如何定位哪段逻辑拖慢了 rAF 循环？

别猜，用 DevTools 的 Performance 面板录制一次 1–2 秒的动画过程，重点关注 Scripting 区域里每个 requestAnimationFrame 回调的执行时长。特别注意：

• 是否在回调里反复调用 getBoundingClientRect()、offsetTop 等触发强制同步布局（Layout Thrashing）的属性
• 是否在每帧都新建数组、对象或调用 JSON.parse() 等高开销操作
• 是否在 rAF 中执行了未节流的 DOM 写入（如连续改 10 个元素的 style.transform）

哪些写法能稳住 120Hz？

核心原则：把「可预测」和「可复用」的部分提前做，把「必须每帧算」的部分压到最低。实操建议：

• 用 transform 和 opacity 做动画，避免触发布局重排；CSS 动画优先于 JS 计算后写 style
• 把 DOM 查询（如 document.querySelector()）提到 rAF 外，缓存为变量；不要在回调里反复查节点
• 用 requestIdleCallback 拆分非关键计算（如数据预处理、日志上报），避免挤占 rAF 时间片
• 对高频更新的状态（如鼠标位置、滚动偏移），用 throttle 或 debounce 控制采样频率，而非每帧都读 event.clientX
• 避免在 rAF 中调用 console.log、alert 或任何 I/O 操作——它们在 DevTools 开着时尤其致命

要不要用 Web Worker 处理 rAF 中的计算？

可以，但要看场景。如果某段逻辑稳定耗时 > 3ms（比如物理模拟、路径插值、图像像素处理），且不依赖 DOM，就值得移到 Web Worker。注意：

• Worker 和主线程通信有开销，别每帧发 120 次消息；批量传数据 + 使用 Transferable 对象（如 ArrayBuffer）减少拷贝
• Worker 返回结果后，仍需在 rAF 回调中应用——别让 Worker 结果等待下一轮 rAF 导致延迟一帧
• 移动端 Safari 对 Worker 支持较弱，且部分设备上 Worker 调度本身就不够稳定，上线前务必真机测

120Hz 不是靠“加 rAF”实现的，而是靠让每一帧的 JS 执行尽可能短、确定、无副作用。最容易被忽略的是「隐式布局触发」——哪怕只读一个 scrollHeight，也可能让整帧从 2ms 拉长到 15ms。

理论要掌握，实操不能落！以上关于《如何优化 requestAnimationFrame 中的 JavaScript 逻辑以达成 120Hz 渲染》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！