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也能“动起来”，但它们在动画场景下，真的不是最佳选择，甚至可以说是“糟糕”的选择。
核心原因在于，setTimeout和setInterval的执行时机是不确定的。它们是基于JS事件循环的，你设置的延迟时间只是一个“最小延迟”，浏览器并不能保证你的回调函数会在那个精确的时间点执行。更重要的是，它们与浏览器的渲染周期是完全脱节的。想象一下，你的动画逻辑在浏览器刚完成一次绘制之后才执行，那么这次更新就得等到下一次绘制周期才能显示出来，中间就白白浪费了一帧的时间。这就像是你拍电影，演员的动作和摄影机的快门完全不同步，结果就是画面卡顿、不连贯，也就是我们常说的“掉帧”或“卡顿”。
而且，setTimeout和setInterval在性能上也非常粗暴。它们不管你的页面是否可见，是否在后台，都会按照你设定的频率去执行，这会无谓地消耗CPU和GPU资源，尤其是在移动设备上，会明显感觉到发热和电量下降。我记得有一次，一个同事在页面上放了个基于setInterval的跑马灯，结果用户反映手机很快就没电了，查了半天才发现是这个小小的跑马灯在后台也疯狂运行。这可不是我们希望看到的。
所以，从流畅度、性能和用户体验的角度看，requestAnimationFrame是专门为动画而生的，它解决了setTimeout/setInterval在动画领域的所有痛点。
requestAnimationFrame在实际项目中可能遇到的挑战和优化策略
尽管requestAnimationFrame如此强大，但在实际项目中，它也不是万能药，我们依然会遇到一些挑战，需要一些策略来应对。
一个常见的问题是动画的帧率不稳。虽然rAF努力同步浏览器刷新，但如果你的回调函数里做了太多耗时的计算，或者用户设备本身性能不佳，浏览器可能无法在下一个刷新周期内完成所有计算和绘制，从而导致丢帧。我就遇到过在老旧设备上，一个复杂粒子动画从60FPS直接掉到20FPS的情况。
针对这个问题，我们的优化策略是：
性能监测： 在开发阶段，使用浏览器的性能工具（如Chrome DevTools的Performance面板）或者简单的FPS计数器来监控动画的帧率。如果发现帧率不稳定，就要深入分析回调函数内部是否有性能瓶颈。避免主线程阻塞： 将耗时的计算（比如复杂的物理模拟、大量数据处理）放到Web Worker中去执行，只把最终的结果传回主线程来更新DOM或Canvas。动画优化： 减少DOM操作，使用CSS transform和opacity进行动画，因为它们能触发GPU加速。对于Canvas动画，避免重复绘制不变的区域，或者使用离屏Canvas进行预渲染。
另一个挑战是动画的状态管理，尤其是在用户切换标签页、最小化窗口或者网络请求导致页面卡顿等情况下，动画可能会中断或者表现异常。比如一个计时器动画，如果用户切换到其他标签页，回来后时间可能就不对了。
应对这种挑战，我们需要更精细的状态管理：
暂停/恢复逻辑： 在requestAnimationFrame回调中，可以根据页面的可见性状态（document.hidden或document.visibilityState）来暂停或恢复动画。当页面不可见时，取消当前的rAF循环，当页面重新可见时，再重新启动，并根据暂停的时长来调整动画的当前状态，确保动画连贯。时间戳的精确利用： 始终使用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的高级应用场景和潜在误区
requestAnimationFrame的强大，使其成为了许多高级Web交互和图形应用的核心。
高级应用场景：
游戏循环（Game Loop）： 这是最典型的应用。无论是2D Canvas游戏还是3D WebGL游戏，rAF都是驱动游戏逻辑更新和画面渲染的引擎。它能确保游戏在最佳的帧率下运行，并且在后台时自动暂停，非常符合游戏的需求。物理模拟（Physics Simulations）： 如果你需要实现复杂的物理效果，比如粒子系统、布料模拟、重力弹跳等，rAF可以提供稳定的时间步长，让你精确地计算物体在每一帧的位置和状态。滚动动画（Scroll-based animations）： 很多沉浸式网页设计中，元素会随着用户滚动而动态变化。虽然CSS scroll-snap和scroll-timeline在某些场景下更优，但对于复杂的、需要JS控制的滚动视差或元素入场动画，rAF能提供更精细的控制和更流畅的效果。复杂UI过渡和自定义动画库： 当CSS动画无法满足你的需求，或者你需要构建一个通用的动画库时，rAF是底层的基础。你可以基于它封装出各种缓动函数、序列动画、并行动画等高级功能。
潜在误区：
过度依赖rAF，忽视CSS动画： 并不是所有动画都必须用rAF。对于简单的过渡效果（如悬停变色、菜单展开），CSS transition和animation通常是更好的选择。它们由浏览器原生优化，性能通常更高，代码也更简洁。我看到过一些新手，什么动画都用rAF手写，结果代码又长又复杂，还没CSS动画流畅。选择合适的工具才是王道。回调函数中执行耗时操作： 这是个大坑。requestAnimationFrame的回调函数是在主线程上执行的，如果你的回调函数里有大量DOM操作、复杂计算或者同步网络请求，它会阻塞主线程，导致整个页面卡顿，rAF的优势荡然无存。记住，rAF只是提供了执行动画逻辑的最佳时机，至于逻辑本身是否高效，那是你的责任。不正确地取消rAF导致内存泄漏或不必要的计算： 如果你启动了rAF循环，但在动画结束或组件销毁时没有调用cancelAnimationFrame，那么即使动画不再需要，回调函数可能仍然在后台被调用，导致内存泄漏或者不必要的计算。这在单页面应用（SPA）中尤其常见，组件卸载了，但动画还在跑。务必记住，有始有终，requestAnimationFrame和cancelAnimationFrame要成对使用。混淆timestamp的用途： 有些开发者可能会错误地将timestamp理解为动画的开始时间或者一个固定的时间间隔。实际上，timestamp是当前帧的渲染时间，你通常需要计算与上一帧的时间差（deltaTime）来更新动画状态，这样才能实现帧率无关的动画。如果你只是简单地累加一个固定值，那么在不同帧率的设备上，动画速度就会不一致。
总之，requestAnimationFrame是现代Web动画的基石，理解并正确使用它，能让你的网页动画达到一个全新的高度。它需要我们对浏览器的渲染机制有更深的理解，但带来的回报是显而易见的。
以上就是HTML5的requestAnimationFrame有什么优势？如何使用？的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1568307.html
微信扫一扫 
支付宝扫一扫 
