requestAnimationFrame:为什么动画要用它而不是 setInterval?
各位同学、开发者朋友们,大家好!今天我们来深入探讨一个在前端开发中极其重要但常常被忽视的话题——requestAnimationFrame(简称 rAF)与 setInterval 的对比。如果你正在做网页动画、游戏开发或者任何需要流畅视觉反馈的交互功能,那么你一定不能错过今天的分享。
一、引子:动画的本质是什么?
我们先从最基础的问题开始:什么是动画?
动画的本质是连续显示一系列静态图像(帧),从而产生“动起来”的错觉。这种错觉依赖于人类视觉系统的特性——当画面切换速度足够快时(通常每秒16-60帧),大脑就会自动将其感知为平滑运动。
在浏览器中实现动画的核心目标就是:
- 尽可能高频率地更新 UI
- 保持帧率稳定(理想情况下 60 FPS)
- 不阻塞主线程,不影响用户体验
这时候问题来了:如何才能做到这一点?很多人第一反应是用 setInterval 或 setTimeout 来定时刷新页面内容。但这真的是最优解吗?让我们一步步揭开真相。
二、setInterval 的局限性:看似简单实则危险
2.1 基础使用示例(错误示范)
假设我们要做一个简单的元素移动动画:
let position = 0;
const element = document.getElementById('box');
function moveBox() {
position += 5;
element.style.left = position + 'px';
}
// ❌ 错误做法:固定间隔调用
setInterval(moveBox, 16); // 理想帧时间 ≈ 16ms (60 FPS)
乍看之下好像没问题?确实能动起来。但问题在于:
| 问题 | 描述 |
|---|---|
| ✅ 定时精度差 | 浏览器并非严格按16ms执行,可能因系统负载、GC、事件循环延迟等波动 |
| ⚠️ CPU浪费严重 | 即使用户切到其他标签页或页面不可见,依然继续运行,占用资源 |
| 🔥 可能卡顿 | 如果某次执行耗时较长(如DOM操作复杂),后续帧会堆积,导致“跳帧”甚至掉帧 |
| 🧠 不符合浏览器优化机制 | 浏览器有专门的动画调度器(如合成层、GPU加速),而 setInterval 打破了这一机制 |
举个例子,当你打开 Chrome DevTools 的 Performance 面板录制这段代码时,你会发现:
- 每帧执行时间不稳定(有时30ms,有时8ms)
- 页面隐藏后仍持续运行(CPU占用未下降)
- 动画过程中偶尔出现明显卡顿
这正是 setInterval 的致命缺陷:它是一个“硬编码”的定时器,完全无视浏览器自身的渲染节奏和性能状态。
三、requestAnimationFrame:真正的动画引擎
3.1 是什么?怎么用?
requestAnimationFrame 是浏览器提供的原生 API,专为动画设计。它的核心思想是:
“请在下一次重绘之前调用我。”
换句话说,rAF 把动画的控制权交给了浏览器——由浏览器决定何时执行你的回调函数,以保证最佳的帧率和性能表现。
✅ 正确写法示例:
let position = 0;
const element = document.getElementById('box');
function animate(time) {
position += 5;
element.style.left = position + 'px';
// 关键:必须再次调用 requestAnimationFrame
requestAnimationFrame(animate);
}
// 启动动画
requestAnimationFrame(animate);
注意几个关键点:
- 回调函数接收一个参数
time(当前时间戳,单位毫秒) - 必须在每次回调中再次调用
requestAnimationFrame形成递归循环 - 动画结束后要手动停止(后面讲)
3.2 为什么更优?三大优势详解
| 优势 | 解释 |
|---|---|
| ✅ 自动适配屏幕刷新率 | rAF 会根据设备屏幕刷新率自动调整调用频率(通常是 60Hz / 16ms) |
| ✅ 页面不可见时自动暂停 | 当标签页切换、浏览器最小化或页面失去焦点时,rAF 会自动暂停,节省CPU和电量 |
| ✅ 更精准的帧同步 | 浏览器内部做了优化(如合成层、硬件加速),避免不必要的重排/重绘 |
我们可以用一个小实验来验证这个差异:
实验代码:对比两种方式的帧率稳定性
<div id="box" style="width: 50px; height: 50px; background: red; position: absolute; left: 0;"></div>
<button onclick="startSetInterval()">Start setInterval</button>
<button onclick="startRAF()">Start requestAnimationFrame</button>
<button onclick="stopAll()">Stop All</button>
<script>
let intervalId = null;
let rafId = null;
let startTime = null;
function startSetInterval() {
stopAll();
startTime = performance.now();
let count = 0;
intervalId = setInterval(() => {
const now = performance.now();
if (now - startTime > 1000) { // 1秒统计一次
console.log(`setInterval: ${count} frames in 1s`);
count = 0;
startTime = now;
}
count++;
document.getElementById('box').style.left = Math.random() * window.innerWidth + 'px';
}, 16);
}
function startRAF() {
stopAll();
startTime = performance.now();
let count = 0;
function animate(time) {
const now = performance.now();
if (now - startTime > 1000) {
console.log(`requestAnimationFrame: ${count} frames in 1s`);
count = 0;
startTime = now;
}
count++;
document.getElementById('box').style.left = Math.random() * window.innerWidth + 'px';
rafId = requestAnimationFrame(animate);
}
rafId = requestAnimationFrame(animate);
}
function stopAll() {
if (intervalId) clearInterval(intervalId);
if (rafId) cancelAnimationFrame(rafId);
}
</script>
运行上述代码并点击两个按钮分别测试,你会发现:
| 方式 | 平均帧数(约) | 是否受页面可见性影响 | 是否稳定 |
|---|---|---|---|
| setInterval | 45–55 FPS | ❌ 是,持续运行 | ❌ 不稳定(抖动明显) |
| requestAnimationFrame | 58–60 FPS | ✅ 否,自动暂停 | ✅ 极其稳定 |
这就是为什么现代动画库(如 React Motion、GSAP、Three.js)都默认使用 requestAnimationFrame!
四、进阶技巧:控制动画生命周期 & 性能优化
4.1 如何优雅地停止动画?
很多初学者会忘记取消 rAF,导致内存泄漏或逻辑混乱:
let rafId = null;
function animate(time) {
// 动画逻辑...
if (someCondition) {
cancelAnimationFrame(rafId); // ✅ 必须调用
return;
}
rafId = requestAnimationFrame(animate);
}
rafId = requestAnimationFrame(animate);
⚠️ 特别提醒:不要直接赋值 rafId = null,因为 cancelAnimationFrame 需要传入原始 ID。
4.2 使用时间戳进行精确控制(而非计数)
有些开发者喜欢用计数器来判断动画进度,比如:
let frameCount = 0;
function animate(time) {
frameCount++;
if (frameCount > 60) { // 1秒后停止
cancelAnimationFrame(rafId);
}
// ...
}
这是有问题的!因为帧率不一定是恒定的,尤其在低端设备上可能只有 30 FPS。
✅ 推荐做法:使用时间戳计算动画进度:
let startTime = performance.now();
const duration = 1000; // 动画总时长1秒
function animate(time) {
const elapsed = time - startTime;
const progress = Math.min(elapsed / duration, 1);
// 根据 progress 更新位置、颜色等
element.style.transform = `translateX(${progress * 100}px)`;
if (progress < 1) {
rafId = requestAnimationFrame(animate);
} else {
console.log("Animation finished!");
}
}
这样无论帧率如何变化,动画都能准确完成。
4.3 结合 CSS Transitions 和 Transform 的最佳实践
虽然 rAF 强大,但在某些场景下可以结合 CSS 过渡提升性能:
.box {
transition: transform 0.5s ease-in-out;
}
function triggerTransition() {
element.style.transform = 'translateX(100px)';
// 不需要 rAF,浏览器会自动处理过渡效果
}
✅ 适用场景:
- 简单位移、缩放、旋转等
- 不需要逐帧干预的动画
- 性能要求不高时
❌ 不适用:
- 复杂路径动画(如贝塞尔曲线轨迹)
- 需要实时响应用户输入(如拖拽)
- 需要与其他 JS 逻辑联动(如粒子系统)
所以记住一句话:能用 CSS 就用 CSS,不能用再上 rAF!
五、常见误区澄清(避坑指南)
| 误区 | 正确理解 |
|---|---|
| ❌ “rAF 比 setInterval 快” | ❌ 不对!rAF 不是更快,而是更智能、更节能、更贴合浏览器行为 |
| ❌ “我在 rAF 中加了个 setTimeout” | ❌ 千万不要这么做!破坏了 rAF 的一致性,可能导致帧丢失 |
| ❌ “rAF 只适合动画” | ❌ 错!它可以用于任何需要同步浏览器重绘的任务,比如实时图表更新、游戏循环、WebGL 渲染等 |
| ❌ “rAF 无法跨浏览器兼容” | ❌ 已广泛支持(IE9+),可通过 polyfill 补充低版本兼容性 |
六、总结:为什么你应该优先选择 requestAnimationFrame?
| 维度 | setInterval | requestAnimationFrame |
|---|---|---|
| 帧率控制 | 固定间隔,易抖动 | 自适应屏幕刷新率,稳定高效 |
| 资源消耗 | 持续运行,浪费资源 | 页面不可见时自动暂停,节能环保 |
| 用户体验 | 易卡顿、延迟 | 流畅自然,接近原生体验 |
| 开发难度 | 简单直观 | 略复杂但值得掌握 |
| 生态支持 | 通用但过时 | 现代动画标准,主流框架底层依赖 |
✅ 结论:
- 对于任何涉及动画、交互式图形、游戏开发的项目,务必优先使用
requestAnimationFrame setInterval应仅限于非动画类任务(如轮询数据、心跳检测等)- 掌握 rAF 是成为高级前端工程师的重要一步
七、延伸阅读建议
如果你想进一步深入学习,请参考以下资料:
- MDN Web Docs – requestAnimationFrame
- Google Developers – Animation with requestAnimationFrame
- CSS Tricks – A Look at requestAnimationFrame
- High Performance JavaScript by Nicholas C. Zakas — 第六章详细讲解动画性能优化
好了,今天的讲座就到这里。希望你能带着新的认知回到工作中,写出更优雅、更高效的动画代码!如果还有疑问,欢迎留言讨论,我们一起进步!