HTML requestAnimationFrame实现逐帧动画教程

`requestAnimationFrame` 是浏览器原生支持的逐帧动画核心机制，它通过精准对齐显示器刷新率（如60Hz）、自动后台节流、杜绝错帧掉帧等优势，全面超越 `setTimeout` 实现真正流畅、省电且高性能的动画；但其强大能力需正确驾驭——必须手动闭环调用、依托高精度时间戳实现与帧率无关的匀速运动、规避强制同步布局操作，并合理利用合成层优化渲染路径；掌握这些关键实践，才能让 canvas 绘图、CSS 变换、SVG 动画等场景既视觉丝滑，又逻辑严谨。

requestAnimationFrame 为什么比 setTimeout 更适合逐帧动画

因为 requestAnimationFrame 由浏览器调度，自动对齐显示器刷新周期（通常是 60Hz），而 setTimeout 只按毫秒计时，容易错帧、掉帧或触发重排抖动。它还具备后台标签页节流能力——页面不可见时暂停调用，省电且不浪费资源。

常见错误现象：setTimeout(..., 16) 看似模拟 60fps，但实际执行时间受 JS 主线程阻塞影响，可能连续两次回调挤在同一个刷新周期里，也可能跳过一帧；requestAnimationFrame 则保证「每帧最多执行一次」，且时机可控。

• 必须在每次回调结束前再次调用 requestAnimationFrame，否则动画只跑一帧
• 不要在回调里做大量 DOM 计算或 layout 强制同步操作（如读取 offsetTop），否则拖慢帧率
• 若需控制动画节奏（如 30fps），不能靠丢帧实现，而应结合时间戳做逻辑节流

如何正确启动并持续驱动 requestAnimationFrame 动画

核心是形成闭环调用链：回调函数内部必须显式再次调用 requestAnimationFrame，否则动画立即终止。这不是自动循环，而是手动延续。

function animate(timestamp) {
  // 更新状态、计算位移等
  updatePosition(timestamp);
  render();
<p>// 关键：主动请求下一帧
requestAnimationFrame(animate);
}
requestAnimationFrame(animate); // 启动第一帧</p>

使用场景：适用于 canvas 绘图、CSS transform 动画、SVG 属性更新等需要精确帧控制的场合。不推荐用于纯 CSS 过渡（应优先用 transition 或 @keyframes）。

• 避免在回调中直接修改多个元素的 style.left 等触发 layout 的属性
• 用 transform + will-change: transform 替代位置重排类更新
• 如果动画需暂停/恢复，保存当前 requestId 并用 cancelAnimationFrame 控制

如何用时间戳实现与刷新率无关的匀速运动

requestAnimationFrame 回调传入的时间戳（DOMHighResTimeStamp）是单调递增的高精度时间，单位为毫秒，精度远高于 Date.now()。它能帮你消除帧率波动带来的速度不一致问题。

例如：目标移动 100px/秒，不管实际是 58fps 还是 62fps，都应保持相同物理速度。

let lastTime = 0;
function animate(timestamp) {
  if (!lastTime) lastTime = timestamp;
  const delta = timestamp - lastTime; // 毫秒差
  lastTime = timestamp;
<p>// 每秒移动 100px → 每毫秒 0.1px
position += 0.1 * delta;
element.style.transform = <code>translateX(${position}px)</code>;</p><p>requestAnimationFrame(animate);
}</p>

• 不要用 delta > 16 做“帧间隔判断”，这会引入误差；时间戳本身就是对齐刷新率的依据
• 首次调用时 timestamp 可能为 0 或极小值，务必初始化 lastTime
• 若需固定步长逻辑（如每 100ms 执行一次物理更新），用时间累积而非帧数计数

兼容性与性能陷阱：哪些设备或情况会让 requestAnimationFrame 失效

现代浏览器均支持 requestAnimationFrame，但行为差异集中在节流策略和精度上：iOS Safari 在后台标签页中可能完全冻结回调；某些安卓 WebView 旧版本存在时间戳跳变或重复问题；低功耗模式下部分设备会降频至 30fps 甚至更低。

性能影响关键点在于回调函数执行时长。若单帧耗时 > 16ms，浏览器无法在下一个刷新周期前完成绘制，就会丢帧——此时你看到的是卡顿，但 requestAnimationFrame 本身仍在调用，只是被浏览器排队延迟了。

• 用 Chrome DevTools 的 Rendering 面板开启 FPS meter，实时观察是否稳定 60fps
• 避免在动画帧中调用 getComputedStyle、offsetHeight 等强制同步 layout 的 API
• 复杂动画建议拆分为独立层（transform: translateZ(0) 或 will-change），交由合成器处理

真正难的是把「视觉流畅」和「逻辑准确」分开：渲染可以插值补偿，但物理模拟、输入响应、音画同步这些必须严格依赖时间戳，而不是帧序号。这点很容易被忽略。

本篇关于《HTML requestAnimationFrame实现逐帧动画教程》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！