告别定时器抽帧：requestAnimationFrame 渲染原理与工程实践

第一次在项目里认真琢磨 requestAnimationFrame，是因为一个滚动播放卡片堆叠的 H5 页面。在安卓旧手机上，用 setInterval 驱动每次步进的动画，总有一种“哒哒哒”的抽帧感，甚至在快速滑动时直接撕裂出半屏空白。当时同事指着屏幕里一道横向的割痕说：“你这不是动画，是在闹鬼。”后来排查到问题就出在定时器上——它根本不关心屏幕什么时候能绘制，抢着跑、抢着停，画面自然就乱了。换成 requestAnimationFrame 之后，那台卡到怀疑人生的千元机，居然被救回来大半，滚动播放终于像有了呼吸节奏一样顺滑。从那以后，凡是跟绘制、动画、帧率控制沾边的需求，我几乎不再考虑用定时器当主力驱动。

我一直觉得 requestAnimationFrame 属于那种“看着简单，但真想讲透却不容易”的浏览器 API。网上很多文章要么只甩一句“它比 setTimeout 更适合动画”，要么贴一段官方定义就草草收尾。如果你今天想搞明白的不只是一个 API 签名，而是它背后到底为什么能解决这些问题、浏览器在里面做了什么工作、实际开发中要用到什么程度才叫“会用”，那这篇拆解应该能帮你把整个链路一次盘清楚。

1. 先从“人眼要看的流畅”这件事说起

1.1 你需要的不是更快，而是恰到好处

屏幕能呈现动态画面，靠的是不断刷新显示内容。绝大多数显示器的刷新率是 60Hz，也就是一秒内能刷新 60 次画面，每一次刷新被称为一帧，帧与帧之间的间隔大约是 16.67 毫秒。这是什么概念？你去买显示器、手机时看到的“60Hz”“90Hz”“120Hz”，就是这个刷新的频率。

人眼对连续画面的感知并不是越流畅越好，而是只要屏幕帧数足够稳定、时序足够均匀，就会自动脑补成连贯运动。反过来，哪怕某一段的帧数很高，但如果中途突然卡掉几个帧，或者某几帧间隔忽长忽短，人眼会非常敏锐地捕捉到这种“不流畅感”。你回忆一下看手机时偶尔遇到的掉帧，是不是会有“抖了一下”的感觉？本质上就是帧间隔不齐造成的。

动画的本质，是让元素属性在单位时间内发生可感知的连续变化。从渲染技术上来看，浏览器每一帧都要经过脚本执行、样式计算、布局、绘制、合成这些过程。所以一个合适的前端动画驱动循环，应该是跟着显示器的节奏走。显示器请求一帧，你就更新一帧，不多跑也不少跑。它的核心目标不是“跑得最快”，而是“每一步都恰好赶在那一帧渲染之前完成更新”。requestAnimationFrame 这个 API 想解决的核心问题，就是替你找到这个“渲染之前”的准确时机。

1.2 为什么 setInterval 驱动动画容易翻车

可能有人会想：既然setInterval可以每隔16.7ms执行一次回调，不就是60fps吗？但在真实浏览器里，原因比这个模拟复杂得多。

setInterval 的计时是基于主线程任务队列的，它只保证“下一次回调任务被推入队列的最早时间点到了”，根本不知道这一帧浏览器渲染有没有结束、主线程是不是空闲、屏幕此刻有没有在刷新。于是你常常会遇到三类问题：

• 回调任务的执行时机落在帧与帧的渲染间隙，造成本帧样式更新后还没有等到绘制机会，下一帧又来了，多帧的更新挤压在一起，表现为“跳帧”。
• 主线程繁忙时，定时器回调可能会被连续延后几次，然后就突然一起执行好几轮，导致动画一瞬间跑一大截，也就是所谓的“burst”，随后又断片，观感极差。
• 即使你设定的是 16.7ms，但浏览器定时器本身的最小精度、系统时钟漂移、后台标签页的节流策略都会影响真实的触发间隔。

浏览器其实还有个非常现实的问题：如果页面切换到了后台标签页，为了保证性能，定时器会被大幅度节流，有的浏览器直接降到每秒一次甚至暂停。你想想，如果一张轮播图是靠 setInterval 驱动的，用户切走标签再切回来，轮播状态和显示内容可能是错乱的。而 requestAnimationFrame 就聪明得多——页面一旦不可见，浏览器会自动暂停调用；回到可见状态后，再接着从当前状态继续跑。这种机制对动画本身是巨大保护，能防止无意义的计算消耗，也能避免回归页面时“闪一下跳N步”的尴尬。

1.3 你自己写循环为什么做不到精准

也许你还会想：不用 setInterval，我在 while 循环里自己跑一个时间轴不就行了？确实有人这样写过。但问题在于，JavaScript 是单线程语言，如果你用同步阻塞的方式在一个循环里不断改样式、强制计算布局，这期间用户无法点击、页面无法滚动、浏览器无法重绘，所有操作体验全部卡死。

而且动画更新是一个异步的、与渲染配合的活动，它需要的是“每一帧只画一帧的状态”，而不是一股脑把所有中间态都算出来。自己写一个 while 循环把 0 到 100% 的全部中间状态瞬间算完，对用户毫无价值，因为真正能被看到的只有每一帧渲染出来的那一帧状态。

所以，动画驱动需要的是“一次一帧、持续交付”的异步循环机制。浏览器需要在每次绘制前给你留一个更新状态的机会，而 requestAnimationFrame 就是浏览器提供给你的那个官方“入场券”。

2. requestAnimationFrame 到底在浏览器的哪一层工作

2.1 它和浏览器渲染管线的关系

想要真正理解 rAF，必须从浏览器渲染管线说起。一次典型的一帧渲染过程，往往包括下面几个阶段：

1. 处理输入事件（触摸、点击、滚动）
2. 执行 JavaScript 回调（比如 rAF 回调、定时器任务等这部分在主线程排队）
3. 计算样式（Style）
4. 布局（Layout）
5. 绘制记录（Paint）
6. 合成（Composite）并把帧交给 GPU

requestAnimationFrame 的回调被执行的位置非常有讲究，它通常发生在每一帧渲染流程里的 “开始一帧的脚本阶段” 之前，准确说是在样式计算和布局之前。所以你在 rAF 回调里修改 DOM 样式，理论上还能赶在本次渲染提交前被合并进去，不会产生额外的布局抖动。这也是它被称为“渲染帧回调”的原因——它的存在就是为渲染服务的。

想象一下你站在一个工厂流水线旁边：屏幕每次开始处理一帧时，会喊一声“谁要改东西，现在赶紧说”，这时所有 rAF 回调都会被唤醒，大家在这一帧开始前统一报上这次要更新什么，然后流水线安静走完样式、布局、绘制。对比 setTimeout 的做法：它不是等流水线喊集合，而是自己在随机时间点冲进车间，有时候到得早了，得干等一会儿；有时候到得晚了，上一批零件已经焊死了，只能和下一批混在一起。结果就是画面节奏杂乱。

2.2 rAF 和事件循环、任务队列的密切配合

浏览器主线程上跑着一个类似“排队叫号”的机制，也就是事件循环。所有 JavaScript 任务都在这个循环里排队执行。但 rAF 回调并不是普通任务队列里的普通任务，它跟事件循环有着更紧密的配合关系。

浏览器在做一帧渲染前，会在“渲染帧步骤”里检查当前当帧存不存在待执行的 rAF 回调。如果有，就逐个执行；如果回调里又注册了新的 rAF，那它不会在本次渲染帧内再次执行，而是会被安排到下一帧。这个设计保证了一帧内的执行次数是可控的，不会死循环式地把当前帧卡死。同时它也意味着浏览器会尽量保证 rAF 回调能随当前帧一起输出，而不是像 setTimeout 那样被粗暴地压到后面。

而且 rAF 还有一个很厉害的特性：它天然和显示器的 VSync 信号同步。绝大多数设备上，rAF 回调的触发频率会与屏幕刷新率保持一致。显示器每次刷新前，浏览器都会先执行 rAF 回调，之后再进行渲染提交。也就是说，你看到的动画，在理论上每一帧都是“最新状态”的呈现，而不是数据改好之后等了好久才被画上去的状态。

2.3 多显示器和高刷新率场景下的表现

也许你会问：那如果用户显示器是 120Hz，rAF 是不是就每分钟执行 120 次？对，这正是它的优势之一。因为 rAF 每次执行频率是由当前屏幕环境决定的，你做动画时根本不需要去探测屏幕刷新率再手动适配。在 60Hz 屏幕上它每秒跑约 60 次，在 120Hz 屏幕上它每秒跑约 120 次。这意味着业务代码完全不需要关心刷新率差异，交给 rAF 自适应就好。

这一点对游戏类前端项目尤其重要。比如一个用 Canvas 实现的小游戏，如果固定用 16.7ms 间隔跑物理更新，在 120Hz 刷新率的设备上反而会出现运动跟不上显示节奏的问题；如果用 rAF 驱动，让每一帧显示时的物体位置都更新一次，玩家看到的就是完全贴合屏幕刷新速度的流畅运动。这也是 rAF 在游戏开发、可视化大屏、高帧率交互场景中广受欢迎的原因之一。

3. 用 rAF 写动画的基本姿势与工程化思路

3.1 最简单的 rAF 循环是长什么样的

一个最简单的 requestAnimationFrame 循环是这样写的：

javascript复制function tick() {
  // 更新动画状态
  update();

  // 请求下一帧
  requestAnimationFrame(tick);
}

requestAnimationFrame(tick);

这个循环的核心结构是：在回调里做状态更新，然后在回调末尾再请求下一次回调。第一次通过调用 requestAnimationFrame(tick) 启动整个过程。这种“链式递归”的方式保证了每一帧恰好只执行一次 tick，避免了 setInterval 面临的重叠执行问题——前一个 tick 没结束之前，下一个 tick 不会被排队执行。

但要注意，如果动画里涉及按时间变化的数值，单纯每帧加一个固定步长是有风险的。因为帧与帧之间的真实间隔并不严格等于 16.67ms，如果设备掉帧、主线程繁忙，两次 tick 之间的真实间隔可能变成 30ms、40ms，这时如果还按固定步长累加，动画速度就会时快时慢，看到的效果就是一顿一顿的。

3.2 基于时间差驱动的正确姿态

要想做出稳定速度的动画，标准做法是让时间决定进度，而不是让帧数决定进度。你可以在每次回调里读取当前时间，用“当前时间减去上一帧时间”得到真实的时间差，然后以这个时间差为基准计算位移、旋转、透明度等参数。

javascript复制let lastTime = 0;
const speed = 200; // 每秒移动200像素

function tick(time) {
  const delta = lastTime ? (time - lastTime) / 1000 : 0; // 转为秒
  lastTime = time;

  // 本帧应该移动的距离 = 速度 × 时间差
  const step = speed * delta;
  element.style.transform = `translateX(${currentX + step}px)`;

  requestAnimationFrame(tick);
}

requestAnimationFrame(tick);

回调里拿到的 time 参数，是 DOMHighResTimeStamp，精度高达微秒级，它表示当前帧开始的时间。这个参数不用自己通过 Date.now() 去获取，rAF 会直接传给你。使用基于时间差驱动的好处很明显：即使中间掉了几帧，动画依然会按“真实经过的时间总量”去更新位置，不会因为丢帧而让整体动画变慢。这也是我在写轮播卡片堆叠 H5 时采用的方案——用时间差推进 transform 的百分比，让不同性能的手机最终消耗的总时间一致，动画看起来都在同样的节奏上。

3.3 改造定时器惯性思维

很多刚从 setTimeout 迁徙到 rAF 的人会有个惯性：在 rAF 回调里判断时间再决定要不要更新，可其实回调本身就已经是“刷新帧时机”了，普通情况下不需要再做时间过滤，每帧都更新即可。

还有一种常见情况是动画/逻辑分离。比如一个拖拽组件，你需要把“事件监听”和“视觉更新”拆开：鼠标移动事件触发时不直接改 DOM，而是把鼠标位置记录下来，然后通过 rAF 每帧读取最新坐标并更新元素位置。这样即使鼠标移动事件一秒钟触发 200 次，视觉更新依然被压缩在 60 帧以内，大大减少了布局抖动。

javascript复制let mouseX = 0;
let mouseY = 0;
let rafId = 0;
let started = false;

function onMouseMove(e) {
  mouseX = e.clientX;
  mouseY = e.clientY;
  if (!started) {
    started = true;
    requestAnimationFrame(render);
  }
}

function render() {
  element.style.transform = `translate(${mouseX}px, ${mouseY}px)`;
  rafId = requestAnimationFrame(() => {
    // 每帧都会更新位置，但鼠标如果没再动，也没关系，继续跑就行
  });
  started = false;
  // 恰当的写法应该是这里再次请求下一帧，并保持 started 状态
}

我后来更推荐的做法，是直接维护一个全局循环控制标志。事件处理函数里只更新数据，不直接发起 rAF。一个统一的循环函数在启动后一直跑，每一帧去读取最新数据并更新画面。这种模式的好处是集中管理、不会出现多个 rAF 回调互相抢占渲染时机的场景。视觉上结构也更干净。

4. 超越基础：rAF 在实际项目里的进阶用法

4.1 用它组合第三方动画库

很多人都以为，用了 jQuery animate、GSAP、Anime.js 这类动画库后就不需要自己管理 rAF 了。这个理解不全对。实际上现代动画库底层大概率都是基于 rAF 实现的，它们只是帮你封装了循环管理、缓动算法、补间逻辑而已。

但如果你自己写一些组件，又想接入 GSAP 控制某些步骤，那你就得理解 rAF 和库内部时间轴的关系。比如做页面滚动进入某个区域时启动一个 canvas 粒子动画，你可以通过 IntersectionObserver 来触发启动条件，然后在回调里手动 requestAnimationFrame。库里的动画循环跟你自己起的 rAF 是两条平行线，各自更新各自的属性。只要都遵循“每帧更新”的原则，它们就可以共存。

如果要在自己的组件里控制动画执行、暂停、继续，建议封装一个 scheduler 用来统一管理 rAF 的启动和销毁。不要把 requestAnimationFrame 散在组件各个业务方法里，不然很容易漏取消，最后组件卸载了，动画还在后台空跑。

4.2 协调 React/Vue 的状态更新

如果你平时用 React 或 Vue 写业务，可能会有个疑问：既然框架已经有响应式状态更新机制了，我再手动起一个 rAF 循环去改 DOM，是不是不符合框架设计？确实，如果直接通过 rAF 去操作 DOM 属性，容易绕开框架的虚拟 DOM 管理，造成状态漂移。

更合理的做法是区分“业务状态”和“视觉状态”。由 rAF 驱动的，最好是纯粹的视觉状态，而不是藏在组件 store 里的业务状态。比如一个跟随鼠标移动的视觉光标，它本身不需要进入业务状态管理，可以完全由 rAF 和 transform 驱动。又比如 Lottie 动画实例、Canvas 画布内部的粒子运动，这些内容属于渲染层自管状态，与 React/Vue 的组件状态树没有必然联系，正好合适用 rAF 驱动。

如果真的要在 React 里逐帧更新某个内容，应该怎么办？合理姿势是绕开 setState 高频更新。React 的批量更新机制不适合 60fps 的高频渲染。你可以通过 ref 直接操作某个 DOM 的属性（如 transform），或者把数据更新写在外部的一个事件系统里，然后通过一个很低频的 setState 去同步 UI。

以 Vue 为例，如果是在 Canvas 里做粒子动画，组件内部 draw 循环直接操作 canvas 2d context，每次 draw 结束后通过 requestAnimationFrame 请求下一帧。Vue 只负责创建 canvas 节点和销毁组件时取消动画循环。业务数据用普通对象存储，不进响应式系统。这样避免了大量响应式依赖收集的性能损失。

4.3 游戏循环里如何用 rAF 做固定步长更新

写小游戏、物理模拟时，会遇到一个非常经典的问题：帧率不固定时，物理模拟的步长不同会导致模拟不稳定。不同手机上帧率差异大，有些帧间隔 10ms，有些 30ms。如果每帧都在物理引擎里跑一次，结果就是不同设备上同一局游戏的体验完全不同。

这个问题和 rAF 本身结合时，需要一个额外的设计模式：固定时间步长累加器（fixed timestep accumulator）。

思路是：不管 rAF 每次回调之间的真实时间隔多久，你都把时间先累加起来，然后按照固定的模拟步长（比如 1/60 秒）去拆解这中间的时间，每凑够一个步长就执行一次物理更新。这样物理模拟永远以固定步长推进，而渲染则保持在设备刷新允许的范围内进行显示。拿一份饼干来类比：你一小时要吃一块饼干，但时间并不能完全均匀地切成 60 份，于是你干脆攒时间，攒够 16.67ms 就咬一口，剩下的留在盘子里继续攒。

大致伪代码如下：

javascript复制const step = 1000 / 60;
let accumulator = 0;
let lastTimestamp = 0;

function frame(timestamp) {
  if (!lastTimestamp) lastTimestamp = timestamp;
  accumulator += timestamp - lastTimestamp;
  lastTimestamp = timestamp;

  while (accumulator >= step) {
    updatePhysics(step / 1000);
    accumulator -= step;
  }

  render();
  requestAnimationFrame(frame);
}

requestAnimationFrame(frame);

这个模式下，updatePhysics 永远以统一的步长被调用，不管屏幕刷新率是 60 还是 120，物理规律保持一致，不会因为帧率不同而出现“这台手机飞得快，那台手机飞得慢”的问题。render 则保持每帧只调用一次，仅负责把当前世界状态画上去。

要注意：while 循环里的上限保护是个关键点，比如当页面卡了几百毫秒再切回来，accumulator 会积攒出极多的待执行步数，如果全执行会让画面瞬间崩溃。常见做法是限制单帧最多迭代几次，超出部分直接丢弃，防止“死亡螺旋”。

5. 性能优化与后台生命周期管理

5.1 rAF 是自动节能的动画引擎

浏览器对 rAF 有个内置机制：当页面处于不可见状态（比如切到别的标签页，或最小化窗口）时，rAF 会直接被暂停调用，直到页面恢复可见才会继续。这意味着，你不需要自己监测页面可见性再暂停动画。这在性能上帮了很大的忙——一张跑在后台的大屏可视化动画，如果没有这个机制，就会持续空转消耗 CPU 和电池电量。

但另一个需要开发者自己留意的点在于：如果页面重新可见时，你的动画逻辑依赖 lastTime 进行时间差计算，你可能要额外处理“长时间挂起后恢复”的情况。比如你在后台待了 5 分钟，回来时 rAF 给出的时间差可能是 5 分钟，如果你直接拿这个时间差去更新位置，动画会瞬间跳转一大截。这是非常经典的时间差动画坑。

解法是限制单帧时间差大小，一般设定一个最大阈值，例如 100ms。超过阈值就按阈值处理，可以让动画避免在从后台切换回来时出现“闪现”的诡异跳变。

javascript复制let lastTime = 0;

function tick(time) {
  const rawDelta = lastTime ? (time - lastTime) / 1000 : 0;
  const delta = Math.min(rawDelta, 0.1); // 限制最大步长
  lastTime = time;
  // ...
  requestAnimationFrame(tick);
}

5.2 用 cancelAnimationFrame 维持组件生命周期

很多刚用 rAF 的开发者会漏掉取消操作。组件或模块销毁时如果不调用 cancelAnimationFrame，循环会继续执行，浪费资源，还可能导致已经销毁的 DOM 被操作，进而报错。这是很常见的隐患，尤其在使用单页框架时，页面组件切走以后，动画循环经常还在后台偷偷跑。

正确的做法是每次启动时把 rAF 返回的 id 存下来，在销毁时用 cancelAnimationFrame(id) 取消。如果担心局部污染，可以把这些变量封装成一个独立 scheduler 模块：

javascript复制const scheduler = {
  rafId: 0,
  active: false,
  callback: null,

  start(cb) {
    this.callback = cb;
    this.active = true;
    const tick = (time) => {
      if (!this.active) return;
      this.callback(time);
      this.rafId = requestAnimationFrame(tick);
    };
    this.rafId = requestAnimationFrame(tick);
  },

  stop() {
    this.active = false;
    cancelAnimationFrame(this.rafId);
  },
};

这样可以非常方便地在 framework 生命周期里调用。比如 Vue 的 onUnmounted、React 的 useEffect cleanup，就是最适合调用 scheduler.stop() 的位置。

5.3 渲染频率比较：rAF、setTimeout、FPS 表

为了更直观，我整理了一张我在做前端动画性能分享时经常用的对比表：

这张表背后其实藏着一个更重要的意识：rAF 是用来配合渲染的调度器，而不是普通的定时器。所以，当你拿到一个跟连续视觉更新相关的任务时，第一反应应该是“用 rAF 去驱动”，而不是“用 setInterval 去模拟”。这两个出发点完全不同，写出来的代码维护难度也完全不同。

6. 深入调试：rAF 在真实页面里怎么观测

6.1 用 Performance 面板看 rAF 的回调频率

你如果在 Chrome DevTools 的 Performance 面板录制一段动画，可以看到一层叫“Animation Frame Fired”的事件。这就是浏览器渲染帧调度器中 rAF 回调的执行标记。展开 Event Log 后，可以把它和 FPS 曲线、主线程任务叠加分析，找到某一帧里超过预期耗时的长任务。

我调试滚动卡片堆叠动画时，就靠这个发现了一个隐藏的性能大坑：框架组件的响应式依赖更新阻塞了主线程，导致 rAF 回调被延迟，帧率从 60 掉到 20。正是因为能看到 rAF 回调事件与长任务之间的时间线关系，排查方向直接指向组件更新策略。

所以建议你先养成用 Performance 面板观察 rAF 频率的习惯，别只听肉眼感受。肉眼觉得卡，但说不清卡在哪，面板能告诉你掉帧在时间线上的具体位置。

6.2 用 rAF 自己做 FPS 统计

想要快速拿到页面实时帧率，可以自己借助 rAF 的 time 参数做个轻量 FPS 计：

javascript复制let frameCount = 0;
let lastFpsTime = 0;
let currentFps = 0;

function measureFps(time) {
  frameCount++;
  if (time - lastFpsTime >= 1000) {
    currentFps = frameCount;
    frameCount = 0;
    lastFpsTime = time;
  }
  requestAnimationFrame(measureFps);
}

requestAnimationFrame(measureFps);

这个 FPS 计可以作为动画开发期的调试小工具。它不是一个精确的仪表，但绝对能告诉你“页面当前到底有没有稳定在 60”。当我在做高性能 Canvas 粒子系统时，会把这个 FPS 计渲染在画布右上角，直观验证不同粒子数量下的性能表现。

6.3 排查掉帧时的第一反应清单

如果在动画实际体验中还是觉得不流畅，通常按下面的顺序排查：

1. 看 rAF 回调里有没有主动触发强制同步布局的代码（比如读取 offsetWidth 后马上改宽度）。
2. 看回调里是否在做高复杂度的计算，比如大量数组遍历、频繁字符串拼接、触发布局属性修改。
3. 看主线程是否存在大量长任务，比如一次性解析巨大的 JSON、执行高耗时网络数据处理。
4. 看页面是否存在大量需要绘制合成的图层，尤其是 hover、阴影、滤镜等容易触发频繁重绘的属性。
5. 看内存是否有持续增长的趋势，如果回调里不断产生闭包对象、数组或字符串，又没有合理释放，绘制会随着时间推移越来越卡。

这套清单基本覆盖了我日常调试的 80% 场景。只要逐条排查完，动画性能问题很难藏得住。

7. 常见误用与工程化避坑

7.1 直接在 useEffect 里开循环忘掉清理

在 React 项目里，useEffect 中写了一个 rAF 循环，但依赖数组设置为空数组，组件卸载时没有清理。这种误用非常典型。因为组件卸载后，循环继续访问已经卸载的 DOM，控制台不断警告，但代码逻辑上不会立刻崩溃，等路由切换几次后，性能就会急剧下降。

推荐的写法是：

javascript复制useEffect(() => {
  let rafId;
  const tick = (time) => {
    // do something
    rafId = requestAnimationFrame(tick);
  };
  rafId = requestAnimationFrame(tick);

  return () => cancelAnimationFrame(rafId);
}, []);

这个模式的核心在于：启动动画时马上把 id 存到闭包变量里，卸载时通过同一个变量取消。一次启动配一次清理，生命周期闭环才算完成。

7.2 rAF 里做高耗时任务不如拆帧做

有人会觉得 rAF 回调每帧执行一次，那我把复杂的遍历直接放在 rAF 回调里不就行了？事实不然。如果回调本身超过 16.7ms 才执行完，那当前帧必然产生卡顿，整个渲染流程都会被拖慢。在处理大数据量渲染时，更应该采用“拆帧”方式，把一次高耗时任务拆成多个小片，分布到多帧中执行。

比如要对一个包含数千个元素的数组做 Canvas 绘制，不要在一帧里把几千个元素全部画完，可以在每帧只画一部分元素，多帧后完成全部刷新。这种做法虽然让整体渲染时间变长，但避免了单帧卡顿，用户观感上更平滑。

7.3 别再到处起匿名循环

一个页面如果同时有多个模块各自调用 requestAnimationFrame，就会造成浏览器同时维护多个渲染帧回调。虽然浏览器可以调度这些回调在同一帧内执行，但多个回调之间可能产生冲突，比如各自对同一个 DOM 做不同属性修改，导致视觉跳变。

正确思路是收敛循环。页面最好只有一个可复用动画循环调度器，各个动画模块以注册的方式加入这个调度器，由调度器统一驱动。它的本质是设计上的一切渲染更新请求都收敛到门口排队，帧开始后由调度器按注册顺序逐个调用。这样的结构既方便调试，也方便统一做暂停、恢复、销毁，避免出现“每个角落都在暗自发飞”的失控局面。

8. 锦上添花：rAF 与体验细节的配合

除了主流程动画，rAF 在很多小细节上能帮你提升质感。比如页面滚动时的视差背景运动，如果用 scroll 事件直接操作，会导致滚动过程中频繁触发布局和绘制，边滚动边卡。更稳的方案是在 scroll 事件里只更新一个 scrollY 变量，然后用 rAF 在每帧统一更新视差元素的位置。这样视觉变化和你滚动操作是分帧同步的，跟手度反而更好。

再比如加一个页面加载进度条，用 rAF 驱动进度数值平滑增长到 100%，比 setInterval 模拟的进度走势自然得多。又比如后台表格中某个数值在跳动，你希望它能够有平滑的“数字过渡”效果，也可以借助 rAF 做数字补间。

这里提供一个小工具：一个通用的数字缓动函数。当某个数值从 oldValue 变成 newValue，它会在一定时间内做一次匀速或缓动动画，数值变化中间态由 rAF 驱动显示。这种小技巧在数据大屏、驾驶舱报表里非常常见。

javascript复制function animateNumber(from, to, duration, onUpdate) {
  const startTime = performance.now();

  const tick = (time) => {
    const elapsed = Math.min((time - startTime) / duration, 1);
    const eased = 1 - Math.pow(1 - elapsed, 3); // easeOutCubic
    const current = from + (to - from) * eased;
    onUpdate(Math.round(current));

    if (elapsed < 1) {
      requestAnimationFrame(tick);
    }
  };

  requestAnimationFrame(tick);
}

animateNumber(0, 100, 1500, (value) => {
  document.querySelector('.counter').textContent = value;
});

这类小功能因为逻辑简单，也不依赖大型动画库，手动用 rAF 管理最合适，代码量不大但体验提升明显。

9. 关于 rAF 的杂谈与个人经验

我在日常开发里，已经把它当成一个默认选项：只要涉及高频视觉更新，第一选择就是 requestAnimationFrame；如果需要可靠的定时延时，我用 setTimeout 或 setInterval；如果是需要跟服务器同步状态、定期拉取数据，我会用定时器加可视性检测的组合。

有些人对 rAF 有个误解，觉得它只能做动画，实际上它辅助的是所有“视觉变化”场景。从滚动效果、拖拽跟随到 canvas 游戏，从骨架屏到协作白板里的光标位置更新，w88 top 10使用它之后，性能问题一般都能大步减少。它的价值，是帮忙把频率限制在“眼睛需要”的粒度，而不是无限追求更快的更新。

另外，如果你想了解后续是否还有更先进的替代者，目前还真没有。Web Animations API
倒是有机会统一一部分动画开发方式，但底层的帧调度机制和 rAF 依然紧密绑定。未来不管框架如何变化、渲染方式如何升级，对“每一帧都应该在正确时间更新一次”的需求不会变。rAF 这一个 API 背后的设计思想，会长期体现在浏览器渲染生命周期的核心设计中。

至于前端项目里到底应该什么时候使用 rAF，我的判断标准其实很简单：如果这个操作的结果，最终要变成屏幕上某一帧里可看到的像素变化，那就应该有 rAF 的参与。看起来这句话有点绝对，但你只要照着实践一段时间，会非常自然地判断出哪些代码应该交给定时器、哪些应该交给 rAF。而这种分寸感，其实就是前端开发里那类“看起来不难，实则关键”的经验沉淀。希望这篇拆解能帮你把这个小小的 API 理解得透透的，在实际项目里少踩几个坑，多做出几个流畅的页面。