requestAnimationFrame无限循环引发1帧绘制延迟的原因及解决办法咨询

(a) 1帧延迟产生的具体原因 #

浏览器每帧的渲染流水线有固定执行顺序：先执行所有已注册的*requestAnimationFrame（下称rAF）*回调 → 样式计算 → 布局 → 绘制 → 合成输出到屏幕。
你所用的无限rAF循环逻辑，会在每次rAF回调执行时立刻注册下一个rAF回调，这个新注册的回调会被排入下一次渲染帧的rAF队列头部，让浏览器始终保持持续唤醒的渲染调度状态，这也是它能提升时序精度的核心原因。
1帧延迟的根源在于：当你在rAF回调执行完毕后的时段修改DOM，这个DOM变更不会触发紧急渲染流程，而是会被浏览器缓存，等待下一帧的rAF回调全部执行完毕后才会进入后续的渲染环节，相当于刚好跳过了最近的一个渲染窗口，所以多出了1帧的延迟。
你观察到配置了desynchronized: true的canvas无延迟，是因为这类canvas走独立于主线程渲染流水线的合成路径，不受rAF调度和主线程渲染队列的约束，Chrome、Edge、Opera对该特性支持完善，Firefox目前对该特性的支持还存在缺陷，所以仍有延迟。

(b) 兼容高精度时序与即时渲染的解决方案 #

• 方案1：将所有DOM更新操作统一放到rAF回调的最前端执行。你可以维护一个全局的渲染任务队列，每次rAF回调执行时优先清空队列里的DOM更新任务，再注册下一次rAF，这样DOM变更会和当前帧的rAF同步执行，紧接着进入渲染流程，不会产生额外延迟。示例代码如下：

// 全局渲染任务队列
const pendingRenderTasks = [];

function precisionRafLoop() {
  // 优先执行所有待处理的DOM更新
  while (pendingRenderTasks.length > 0) {
    const task = pendingRenderTasks.shift();
    task();
  }
  requestAnimationFrame(precisionRafLoop);
}

// 对外暴露的更新入口，所有DOM修改都通过该方法调用
function queueDomUpdate(updateFn) {
  pendingRenderTasks.push(updateFn);
}

// 使用示例
queueDomUpdate(() => {
  document.getElementById('stimulus_id').textContent = "NEW DISPLAY";
});

• 方案2：临时将DOM更新包裹在rAF回调中调度。如果你不想改造现有更新逻辑，可以在需要修改DOM时，直接将更新逻辑放到rAF回调中执行，同一帧内注册的所有rAF回调会按顺序在当前帧统一执行，不会被推迟到下一帧。示例代码：

// 需要更新DOM时直接用rAF包裹
requestAnimationFrame(() => {
  document.getElementById('stimulus_id').textContent = "NEW DISPLAY";
});

• 方案3：非canvas元素的高优先级渲染适配。如果需要对普通文本、UI元素实现和desynchronized canvas同等的低延迟渲染，可以将文本/UI内容预先渲染为位图，放到开启了desynchronized: true的canvas中绘制，即可复用canvas的独立合成路径能力，避开主线程渲染队列的延迟约束。
• 方案4：Firefox兼容处理。针对Firefox浏览器不支持desynchronized canvas的问题，你可以通过调整rAF循环的调度优先级，在需要执行DOM更新的前一帧，提前注册更新回调（Firefox对同一帧的rAF回调按注册顺序执行，提前注册的更新会优先执行），即可将延迟控制在16ms以内，不会出现翻倍的情况。

内容的提问来源于stack exchange，提问作者gaspar