javascript如何实现动画_requestanimationframe的优势是什么

因为setTimeout/setInterval不与屏幕刷新同步，易掉帧卡顿且后台仍运行；requestAnimationFrame则按刷新节奏执行、提供精准时间戳、需递归调用，并适合需JS实时干预的动画场景。

为什么不用 setTimeout 或 setInterval 做动画

因为它们不和屏幕刷新节奏同步，容易掉帧、卡顿，甚至在页面不可见时还在跑，浪费 CPU。浏览器每秒刷新约 60 次（即 16.67ms 一帧），而 setTimeout(fn, 16) 只是“尽量”隔 16ms 执行，并不能保证准时——实际执行时间受任务队列、JS 主线程阻塞影响很大。

• 动画逻辑可能被延迟到下一帧甚至更晚，造成视觉撕裂或跳变
• 标签页切到后台时，多数浏览器会把 setTimeout 降频到 1s 以上，但动画仍会“假性运行”，恢复时疯狂补帧
• 无法获知当前帧的精确开始时间，难以做时间差校准（比如 easing 计算）

requestAnimationFrame 怎么用才对

它不是“启动一次就完事”的函数，而是一个需要手动递归调用的机制：每次回调执行完，如果还想继续动画，就得再调一次 requestAnimationFrame。

function animate(timesta
mp) {
  // timestamp 是该帧开始时的高精度时间戳（DOMHighResTimeStamp）
  const elapsed = timestamp - startTime;
  element.style.transform = `translateX(${easeInOutCubic(elapsed / duration) * 200}px)`;
if (elapsed < duration) {
requestAnimationFrame(animate); // 关键：主动续订
}
}
let startTime = performance.now();
requestAnimationFrame(animate);

• timestamp 参数比 Date.now() 更准，且不受系统时间修改影响
• 不要在回调里直接写 element.style.left = ...，优先用 transform，避免触发重排（reflow）
• 如果动画要暂停/取消，需保存 requestAnimationFrame 返回的 ID，并调用 cancelAnimationFrame(id)

相比 CSS 动画，requestAnimationFrame 适合什么场景

CSS 动画声明式、性能好，但控制粒度粗；requestAnimationFrame 适合需要 JS 实时干预的动态过程。

• 鼠标跟随、拖拽反馈、滚动视差等依赖用户输入的动画
• 物理模拟（如弹簧、碰撞）需要每帧计算位置加速度
• 动画过程中要读取 DOM 尺寸或样式（比如根据容器宽度动态调整动画参数）
• 需要精确控制播放/暂停/倒放/跳转到某一进度（CSS animation-play-state 和 animation-delay 都不够灵活）

容易忽略的兼容性与陷阱

现代浏览器都支持 requestAnimationFrame，但它的行为细节常被低估。

• 在 iOS Safari 中，如果页面有 overflow: scroll 的容器，快速滚动时可能触发 requestAnimationFrame 被节流，导致动画“卡住”——此时可监听 scroll 事件 + passive: false，或改用 IntersectionObserver 触发时机
• 不要在 requestAnimationFrame 回调里做大量计算或 DOM 查询，否则可能超 16ms，直接丢帧；复杂逻辑建议用 Web Worker 或拆分到多帧
• 若动画基于时间（而非帧数），务必用传入的 timestamp 计算差值，而不是靠 ++frameCount —— 否则在低帧率设备上会变慢

真正难的不是调用这个函数，而是设计好状态更新节奏、避免隐式重排、处理好跨设备帧率差异。这些细节没压住，再“正确”的调用也救不了动画体验。