当前位置：首页 > 文章列表 > 文章 > 前端 > requestAnimationFrame实现60FPS异步更新技巧

requestAnimationFrame实现60FPS异步更新技巧

2026-05-29 23:57:50 0浏览收藏

为什么 requestAnimationFrame 能匹配 60FPS

现代浏览器通常以约 16.67ms（1000ms ÷ 60）为间隔触发一次重绘。requestAnimationFrame 会把回调函数排队到**下一个可用的渲染帧开始前**执行，且在该帧内完成 DOM 更新、样式计算、布局、绘制全过程。只要单次回调耗时 ≤16ms，就能维持流畅的 60FPS。

正确使用 requestAnimationFrame 更新 UI 的关键做法

只在需要时调用，避免连续无节制递归：不要在回调里无条件再次调用 rAF；应根据状态（如动画是否继续、数据是否变化）决定是否继续调度
批量读写分离：先读后写：避免在同一次 rAF 回调中交替读取 offsetTop/scrollTop 等布局信息和修改 class/style，否则触发“强制同步布局”（Layout Thrashing），大幅拖慢性能
把耗时操作移出 rAF 回调：复杂计算、大数据处理、网络请求等应放在 Web Worker 或用 setTimeout 分片，rAF 内仅做轻量级 DOM 更新
结合 IntersectionObserver 或 ResizeObserver 做按需更新：例如只对可视区域内的列表项触发动画，减少不必要的 rAF 调度

一个典型的安全更新模式示例

以下代码确保滚动中实时更新某元素位置，同时不卡顿：

let pendingUpdate = false;
const updateElement = () => {
  // 仅更新依赖当前滚动位置的样式，不读取 offsetTop 等
  element.style.transform = `translateY(${window.scrollY * 0.5}px)`;
};
const scheduleUpdate = () => {
if (!pendingUpdate) {
pendingUpdate = true;
requestAnimationFrame(() => {
updateElement();
pendingUpdate = false;
});
}
};
// 在 scroll、resize 等高频事件中节流调用
window.addEventListener('scroll', scheduleUpdate);

这里用标志位防止同一帧多次注册，且 updateElement 中只做 transform（合成层操作），不触发重排。

常见误区与替代方案对比

不用 setInterval(, 16)：无法对齐刷新节奏，可能造成错帧、丢帧，且页面后台运行时仍计时
避免混用 setTimeout 和 rAF 更新同一状态：时序不可控，易导致视觉闪烁或状态竞争
服务端渲染（SSR）+ hydration 后，首次 UI 更新也建议用 rAF 包裹：让 DOM 准备就绪后再触发首帧动画，避免 FOUC 或 layout shift

掌握 requestAnimationFrame 的本质——它是浏览器渲染流水线的“预约入口”，不是通用定时器。围绕帧预算（≤16ms）、避免强制重排、保持更新原子性，就能自然获得稳定 60FPS 的异步 UI 表现。

今天关于《requestAnimationFrame实现60FPS异步更新技巧》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！