requestanimationframe（raf）是实现流畅动画的关键机制，1. 它与浏览器刷新周期同步，避免画面撕裂和跳帧；2. 在页面不可见时自动暂停以节省资源；3. 提供高精度时间戳实现帧率无关动画。通过在每次重绘前调用回调函数，raf确保动画帧与屏幕刷新同步，形成自然流畅的视觉效果。相比settimeout/setinterval，它能更高效地调度动画逻辑，尤其在性能和节能方面表现突出。使用时需注意性能监测、避免主线程阻塞、合理管理动画状态，并结合visibilitychange事件控制动画启停，同时应根据场景选择css动画或raf以达到最佳效果。
requestAnimationFrame，在我看来，它就是浏览器动画领域的“幕后英雄”，它最核心的优势在于能够让动画与浏览器的刷新周期完美同步，从而带来极致流畅的视觉体验，同时还能智能地节省系统资源。简单来说，它让你的动画不再“卡顿”，也让用户的设备更“省电”。
谈到前端动画，我们总会追求那种行云流水般的感觉，而requestAnimationFrame（简称rAF）正是实现这一目标的关键。它不是一个简单的计时器，而更像一个由浏览器精心调度的动画管家。
它的第一个也是最重要的优势，就是与浏览器绘制同步。你知道吗，显示器是有刷新率的，比如60Hz，这意味着它每秒刷新60次画面。如果你的动画更新频率和浏览器绘制新画面的频率不同步，就容易出现画面撕裂（tearing）或者跳帧（jank），看起来就像动画卡了一下。rAF的厉害之处在于，它会在浏览器下一次重绘之前调用你提供的回调函数，确保你的动画帧正好赶上浏览器的刷新，这样每一帧都能被完整、及时地显示出来，动画自然就流畅了。这就像是乐队指挥，确保所有乐器都在同一拍子上演奏。
立即学习“前端免费学习笔记（深入）”；
再者，rAF在性能和电量优化方面表现出色。当你用setTimeout或setInterval做动画时，即使标签页被最小化或者切换到后台，它们可能还在傻傻地运行，白白消耗CPU和GPU。但rAF就聪明多了，如果你的页面不在当前激活的标签页，或者被最小化了，浏览器会暂停rAF的回调，直到页面重新激活。这不仅减少了不必要的计算，也大大降低了设备的电量消耗，对于移动设备尤其重要。我个人觉得，这种智能暂停机制简直是天赐之物，尤其是在我开发一些需要长时间运行动画的工具时，用户体验和设备续航都能得到兼顾。
还有一点，rAF提供了高精度的时间戳。每次回调函数被调用时，它都会传入一个DOMHighResTimeStamp，这个时间戳表示从页面加载到现在的时间，精度非常高。这对于实现帧率无关的动画（即动画速度不依赖于设备的具体帧率）至关重要。你可以根据两次回调之间的时间差来计算动画的步进，而不是固定地移动一个像素值，这样无论用户设备是60帧还是120帧，动画看起来的速度都是一致的。
那么，如何使用它呢？其实非常简单，核心就是window.requestAnimationFrame(callback)。
一个最基本的连续动画循环是这样的：
let startTime = null;
let element = document.getElementById('myElement');
let position = 0;
const speed = 0.1; // 像素/毫秒
function animate(timestamp) {
if (!startTime) startTime = timestamp;
const elapsed = timestamp - startTime;
// 根据时间差更新动画状态
position = (elapsed * speed) % window.innerWidth; // 让元素从左到右循环移动
element.style.transform = `translateX(${position}px)`;
// 继续请求下一帧
requestAnimationFrame(animate);
}
// 启动动画
requestAnimationFrame(animate);
// 如果需要停止动画，可以这样：
// let animationId;
// function animateLoop(timestamp) {
// // ...动画逻辑...
// animationId = requestAnimationFrame(animateLoop);
// }
// animationId = requestAnimationFrame(animateLoop);
// cancelAnimationFrame(animationId);这里需要注意的是，requestAnimationFrame本身只执行一次回调。要实现连续动画，你需要在回调函数内部再次调用requestAnimationFrame，形成一个递归循环。而当你想停止动画时，可以使用cancelAnimationFrame并传入之前requestAnimationFrame返回的ID。
这个问题我被问过无数次，每次我都会强调，虽然setTimeout和setInterval也能“动起来”，但它们在动画场景下，真的不是最佳选择，甚至可以说是“糟糕”的选择。
核心原因在于，setTimeout和setInterval的执行时机是不确定的。它们是基于JS事件循环的，你设置的延迟时间只是一个“最小延迟”，浏览器并不能保证你的回调函数会在那个精确的时间点执行。更重要的是，它们与浏览器的渲染周期是完全脱节的。想象一下，你的动画逻辑在浏览器刚完成一次绘制之后才执行，那么这次更新就得等到下一次绘制周期才能显示出来，中间就白白浪费了一帧的时间。这就像是你拍电影，演员的动作和摄影机的快门完全不同步，结果就是画面卡顿、不连贯，也就是我们常说的“掉帧”或“卡顿”。
而且，setTimeout和setInterval在性能上也非常粗暴。它们不管你的页面是否可见，是否在后台，都会按照你设定的频率去执行，这会无谓地消耗CPU和GPU资源，尤其是在移动设备上，会明显感觉到发热和电量下降。我记得有一次，一个同事在页面上放了个基于setInterval的跑马灯，结果用户反映手机很快就没电了，查了半天才发现是这个小小的跑马灯在后台也疯狂运行。这可不是我们希望看到的。
所以，从流畅度、性能和用户体验的角度看，requestAnimationFrame是专门为动画而生的，它解决了setTimeout/setInterval在动画领域的所有痛点。
尽管requestAnimationFrame如此强大，但在实际项目中，它也不是万能药，我们依然会遇到一些挑战，需要一些策略来应对。
一个常见的问题是动画的帧率不稳。虽然rAF努力同步浏览器刷新，但如果你的回调函数里做了太多耗时的计算，或者用户设备本身性能不佳，浏览器可能无法在下一个刷新周期内完成所有计算和绘制，从而导致丢帧。我就遇到过在老旧设备上，一个复杂粒子动画从60FPS直接掉到20FPS的情况。
针对这个问题，我们的优化策略是：
transform和opacity进行动画，因为它们能触发GPU加速。对于Canvas动画，避免重复绘制不变的区域，或者使用离屏Canvas进行预渲染。另一个挑战是动画的状态管理，尤其是在用户切换标签页、最小化窗口或者网络请求导致页面卡顿等情况下，动画可能会中断或者表现异常。比如一个计时器动画，如果用户切换到其他标签页，回来后时间可能就不对了。
应对这种挑战，我们需要更精细的状态管理：
requestAnimationFrame回调中，可以根据页面的可见性状态（document.hidden或document.visibilityState）来暂停或恢复动画。当页面不可见时，取消当前的rAF循环，当页面重新可见时，再重新启动，并根据暂停的时长来调整动画的当前状态，确保动画连贯。timestamp参数来计算动画的进度，而不是依赖外部的Date.now()或累加时间。这样即使动画暂停或浏览器调度有延迟，动画的逻辑也能基于实际的渲染时间前进，保证动画的逻辑一致性。let animationFrameId = null;
let lastTimestamp = 0;
let animationProgress = 0; // 动画的逻辑进度
function startAnimation() {
function animateLoop(timestamp) {
const deltaTime = timestamp - lastTimestamp;
lastTimestamp = timestamp;
// 根据deltaTime更新动画进度，确保动画速度不受帧率影响
animationProgress += deltaTime * 0.01; // 举例：每毫秒进度增加0.01
// 实际的动画逻辑，例如更新元素位置
// element.style.transform = `translateX(${animationProgress}px)`;
animationFrameId = requestAnimationFrame(animateLoop);
}
if (!animationFrameId) { // 避免重复启动
lastTimestamp = performance.now(); // 首次启动时初始化lastTimestamp
animationFrameId = requestAnimationFrame(animateLoop);
}
}
function stopAnimation() {
if (animationFrameId) {
cancelAnimationFrame(animationFrameId);
animationFrameId = null;
}
}
// 监听页面可见性变化
document.addEventListener('visibilitychange', () => {
if (document.hidden) {
stopAnimation();
} else {
startAnimation();
}
});
// 页面加载时启动动画
startAnimation();requestAnimationFrame的强大，使其成为了许多高级Web交互和图形应用的核心。
高级应用场景：
scroll-snap和scroll-timeline在某些场景下更优，但对于复杂的、需要JS控制的滚动视差或元素入场动画，rAF能提供更精细的控制和更流畅的效果。潜在误区：
transition和animation通常是更好的选择。它们由浏览器原生优化，性能通常更高，代码也更简洁。我看到过一些新手，什么动画都用rAF手写，结果代码又长又复杂，还没CSS动画流畅。选择合适的工具才是王道。requestAnimationFrame的回调函数是在主线程上执行的，如果你的回调函数里有大量DOM操作、复杂计算或者同步网络请求，它会阻塞主线程，导致整个页面卡顿，rAF的优势荡然无存。记住，rAF只是提供了执行动画逻辑的最佳时机，至于逻辑本身是否高效，那是你的责任。cancelAnimationFrame，那么即使动画不再需要，回调函数可能仍然在后台被调用，导致内存泄漏或者不必要的计算。这在单页面应用（SPA）中尤其常见，组件卸载了，但动画还在跑。务必记住，有始有终，requestAnimationFrame和cancelAnimationFrame要成对使用。timestamp的用途： 有些开发者可能会错误地将timestamp理解为动画的开始时间或者一个固定的时间间隔。实际上，timestamp是当前帧的渲染时间，你通常需要计算与上一帧的时间差（deltaTime）来更新动画状态，这样才能实现帧率无关的动画。如果你只是简单地累加一个固定值，那么在不同帧率的设备上，动画速度就会不一致。总之，requestAnimationFrame是现代Web动画的基石，理解并正确使用它，能让你的网页动画达到一个全新的高度。它需要我们对浏览器的渲染机制有更深的理解，但带来的回报是显而易见的。
以上就是HTML5的requestAnimationFrame有什么优势？如何使用？的详细内容，更多请关注php中文网其它相关文章！
HTML怎么学习？HTML怎么入门？HTML在哪学？HTML怎么学才快？不用担心，这里为大家提供了HTML速学教程(入门课程)，有需要的小伙伴保存下载就能学习啦！
广告Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号
786
收藏
