使用requestAnimationFrame实现动画：间隔法与手动计算elapsed time，哪种性能更佳？

嘿，这个问题问到点子上了！很多人刚开始用rAF做动画的时候都会纠结这两种方式，我来给你理清楚它们的差异：

性能表现：计算elapsed time的方案完胜 #

你的猜测刚好反过来啦——结合setTimeout的方式其实性能更差，原因有这几点：

• 浏览器刷新同步问题：requestAnimationFrame()本身就是浏览器为动画专门设计的API，它会和浏览器的重绘周期（通常是60fps，即每16.6ms一次）完美同步，只在浏览器准备好重绘的时候执行回调，避免无效计算。而setTimeout()的回调时机由JS任务队列决定，和浏览器重绘完全不同步，经常会出现“浏览器刚重绘完，setTimeout又触发rAF导致额外计算绘制”，或者“浏览器要重绘了，setTimeout回调还没到导致丢帧”的情况，额外增加CPU/GPU负担。
• 定时器额外开销：setTimeout()需要浏览器维护定时器队列，每次触发都有额外的调度成本，而计算elapsed time的方式只依赖rAF的原生调度，没有多余开销。

各自的优势分析 #

1. 结合setTimeout的方案：仅适用于极端小众场景 #

这种方案几乎没有核心优势，唯一可能的使用场景是强制限制动画帧率（比如想让动画固定在30fps运行，刻意降低CPU占用），但现在也有更好的替代方式——比如在计算elapsed time时累计时间，当累计到33ms（30fps间隔）才更新一次动画，效果一致且性能更优。

而且这个方案的缺点很突出：

• 动画卡顿、速度不稳定：setTimeout的精度有限（不同浏览器/设备可能有1-10ms误差），加上任务队列阻塞，会导致实际帧率波动大，动画看起来忽快忽慢。
• 浪费系统资源：和浏览器重绘不同步，会触发不必要的计算和绘制，增加设备功耗。

2. 自行计算elapsed time的方案：推荐的标准实现 #

这是W3C推荐的动画实现方式，优势一大堆：

• 极致流畅：基于实际流逝的时间计算动画进度，比如你想让元素1秒内移动100px，不管浏览器有没有丢帧，每帧都会根据elapsedTime = 当前时间 - 上一帧时间计算应移动的距离，保证动画速度始终准确，不会因帧率波动而变化。
• 性能最优：完全贴合浏览器重绘周期，只在必要时执行计算，最大限度降低CPU/GPU占用，在低性能设备上表现尤其明显。
• 兼容性与可维护性好：主流浏览器都完美支持requestAnimationFrame()，这种写法是行业通用的标准实现，后续维护成本更低。

举个简单的代码示例，直观感受差异：

// 计算elapsed time的标准写法
let lastTime = 0;
function animate(currentTime) {
  const elapsedTime = currentTime - lastTime;
  lastTime = currentTime;
  
  // 根据流逝时间更新动画（每秒移动100px）
  element.style.left = `${parseFloat(element.style.left) + (elapsedTime / 1000) * 100}px`;
  
  requestAnimationFrame(animate);
}
requestAnimationFrame(animate);

这种写法不管浏览器帧率是60fps还是因卡顿降到30fps，元素都会以稳定的速度移动，而setTimeout写法很容易出现速度波动的问题。

内容的提问来源于stack exchange，提问作者lampshade