requestAnimationFrame为何比setTimeout更流畅？

Question

为什么使用 `requestAnimationFrame` 比 `setTimeout` 实现动画更流畅？在相同延迟下，两者视觉表现有何本质区别？是否仅因 `requestAnimationFrame` 自动同步屏幕刷新率（如60Hz）而更优？其背后的浏览器渲染机制、重绘时机以及节流策略如何影响动画性能？在低帧率或页面不可见时，`requestAnimationFrame` 是如何优化资源消耗的？

Answer 1

一、为什么使用 requestAnimationFrame 比 setTimeout 实现动画更流畅？

1. 基础认知：setTimeout 与 requestAnimationFrame 的基本差异

在前端动画开发中，setTimeout 和 requestAnimationFrame (rAF) 都可用于控制动画的执行节奏。然而，两者在实现机制上存在本质区别：

• setTimeout：基于时间延迟调度，开发者设定一个毫秒级延迟（如 16.7ms 对应 60fps），浏览器尽可能在该时间后执行回调。
• requestAnimationFrame：由浏览器主动调用，在下一次重绘前执行回调，其执行时机与屏幕刷新率同步。

尽管两者都可以设置为约每 16.7ms 执行一次，但视觉表现却可能大相径庭。

2. 视觉表现的本质区别：帧对齐与撕裂问题

即使 setTimeout(fn, 16) 看似模拟了 60fps 的节奏，但由于其执行不受浏览器渲染周期约束，可能导致以下问题：

对比维度	setTimeout	requestAnimationFrame
执行时机	独立于渲染周期	紧随浏览器重绘前
帧对齐	可能错位	自动对齐刷新周期
画面撕裂风险	高	低
资源占用（不可见时）	持续消耗 CPU	自动暂停
节流策略	无内置节流	浏览器智能调度

3. 浏览器渲染机制与 rAF 的协同原理

现代浏览器遵循典型的渲染流水线：

1. JavaScript 执行
2. 样式计算（Recalculate Style）
3. 布局（Layout）
4. 绘制（Paint）
5. 合成（Composite）
6. 提交帧到 GPU 显示

requestAnimationFrame 的回调被注册在“样式计算”之前，确保 DOM 变更能及时进入当前帧的渲染流程。而 setTimeout 回调可能插入在任意阶段，若发生在“绘制”之后，则需等待下一个刷新周期，造成帧延迟。

4. 节流策略与性能优化机制

浏览器对 rAF 实施了多层级的节流与节能策略：

• 页面不可见时暂停：当标签页处于后台或隐藏状态（visibilityState === 'hidden'），rAF 回调不会被执行，避免不必要的计算。
• 低帧率设备适配：在 90Hz 或 120Hz 屏幕上，rAF 自动以更高频率调用；而在低端设备上则匹配实际可维持的帧率。
• VSync 同步：通过操作系统 VSync 信号驱动，确保每一帧都在显示器刷新间隔内完成提交，避免画面撕裂。

5. 深入剖析：rAF 并非仅因同步刷新率而更优

虽然“同步屏幕刷新率”是 rAF 的核心优势之一，但其优越性远不止于此：

• 时间戳精度：rAF 回调接收高精度时间戳（DOMHighResTimeStamp），可用于精确计算动画进度，避免累积误差。
• 批处理优化：多个 rAF 回调在同一帧中合并执行，减少重复布局与重绘。
• 与 CSS 动画/过渡协同：浏览器可将 JS 动画与 CSS 动画统一调度，提升整体渲染效率。

6. 实际代码对比示例

// 使用 setTimeout 的动画（不推荐）
let start = null;
function timeoutAnimation(timestamp) {
    if (!start) start = timestamp;
    const progress = timestamp - start;
    element.style.transform = `translateX(${Math.min(progress / 10, 200)}px)`;
    if (progress < 2000) {
        setTimeout(() => timeoutAnimation(performance.now()), 16);
    }
}

// 使用 requestAnimationFrame 的动画（推荐）
function rafAnimation(timestamp) {
    if (!start) start = timestamp;
    const progress = timestamp - start;
    element.style.transform = `translateX(${Math.min(progress / 10, 200)}px)`;
    if (progress < 2000) {
        requestAnimationFrame(rafAnimation);
    }
}
requestAnimationFrame(rafAnimation);
    

7. Mermaid 流程图：rAF 与渲染周期的协同关系

graph TD
            A[requestAnimationFrame 注册] --> B{浏览器下一次重绘前?}
            B -- 是 --> C[执行 rAF 回调]
            C --> D[更新 DOM / 样式]
            D --> E[进入标准渲染流水线]
            E --> F[提交帧至屏幕]
            B -- 否 --> G[排队等待下一帧]
            G --> C
            H[页面隐藏] --> I[rAF 自动暂停]
            J[设备低性能] --> K[rAF 降频调用]

8. 高阶场景下的性能考量

在复杂动画系统中，rAF 还支持以下高级特性：

• 帧丢失检测：通过前后时间戳差值判断是否发生卡顿，动态调整动画逻辑。
• 优先级调度：配合 IntersectionObserver 实现视口内动画优先渲染。
• 与 Web Workers 协同：在 Worker 中使用 requestAnimationFrame（通过 OffscreenCanvas）实现主线程解耦。

9. 兼容性与降级策略

尽管现代浏览器广泛支持 rAF，但在老旧环境仍需兼容处理：

const rAF = window.requestAnimationFrame ||
           window.webkitRequestAnimationFrame ||
           function(callback) {
               return setTimeout(() => callback(performance.now()), 1000 / 60);
           };

const cancelRAF = window.cancelAnimationFrame ||
                  window.webkitCancelAnimationFrame ||
                  clearTimeout;
    

10. 总结性思考：从机制到架构的演进

选择 requestAnimationFrame 不仅是技术细节的优化，更是对现代浏览器渲染模型的理解体现。它代表了一种“声明式调度”思维——将控制权交给浏览器，使其根据系统负载、能效策略和用户感知进行最优决策。相比之下，setTimeout 属于“命令式轮询”，容易打破渲染一致性，导致性能瓶颈。