时间旅行者的困境：React 调度器中的“漂移”与“补偿”
各位未来的前端架构师们，下午好！
今天我们不聊组件怎么拆分，也不聊 CSS 怎么写圆角。我们聊点更硬核的，更接近“底层逻辑”的东西。我们要聊的是时间。
想象一下，你是一个负责在火车站运送行李的搬运工。你的老板（React）告诉你：“嘿，把这三个箱子从 A 站运到 B 站，最好在 10:00 前完成。”
你看了看表，现在是 9:50。你心想：“没问题，我有 10 分钟。”
但是，就在你刚拿起第一个箱子的时候，车站停电了。或者更糟糕的是，你被拉去帮隔壁车站搬砖了。当你终于回到车站，重新拿起箱子时，已经是 10:15 了。
这时候，你手里拿着箱子，看着表，你会怎么做？
你会傻乎乎地对着老板大喊：“老板，我迟到了！我完不成了！” 然后把箱子扔在地上吗？
不。你会看着表，心想：“我迟到了 15 分钟。但我还有 3 个箱子要搬。如果我按原来的速度搬，我肯定完不成。但我现在赶时间，我得加把劲，或者……我得把时间‘压缩’一下。”
这就是我们今天要探讨的主题：React 调度器中的计时器漂移补偿。
在浏览器这个巨大的、混乱的、偶尔会抽风的机器里，时间并不是一条笔直的、匀速流逝的线。它是一条波浪线，甚至是一条锯齿线。当浏览器挂起、当垃圾回收（GC）接管主线程、当你的代码在执行一个巨大的循环时，React 的“任务表”就会发生“漂移”。
如果 React 只是机械地检查“现在是不是 10:00？”，那它就是个傻瓜。React 是个精明的调度员。它会在任务醒来的时候，计算“漂移量”，然后根据任务的紧急程度，重新计算它还需要多久才能完成任务。
来，让我们戴上安全帽，钻进 React 源码的深处，去看看这个“时间膨胀”的算法是如何工作的。
第一章：浏览器的时间膨胀与 React 的“契约”
首先，我们要明白 React 的任务是怎么跑起来的。React 不像 Java 那样有一个固定的执行周期。React 是“事件驱动”的。用户点击一下，React 运行一下；用户滚动一下，React 运行一下。
React 使用一个叫做 scheduler 的库（在 React 18 之前叫 react-scheduler）来管理这些任务。这个库的核心工作，其实就是“许诺”。
当你调用 scheduler.scheduleCallback 时，你实际上是在对浏览器说：“嘿，请在这个时间点 deadline 之前，叫醒我，让我跑一段代码。”
这个 deadline 是一个相对的时间点，比如“距离现在还有 50 毫秒”。React 会把这个 deadline 存起来，然后在下一个浏览器帧（大约 16.6ms）去检查。
但是！浏览器是个不可靠的伙伴。
- 垃圾回收（GC）攻击： 当内存不够时，浏览器会疯狂地扫描内存，这会阻塞主线程。React 以为它有 16ms 的时间，结果浏览器说：“抱歉，我正在擦地板，没空理你。”
- 标签页挂起： 你把浏览器切到后台，去吃个午饭。React 的任务全停了。
- 其他标签页的霸凌： 如果你开了 10 个 YouTube 视频，浏览器会疯狂抢占主线程来渲染视频。
结果就是：React 期望的时间（预期时间）和实际的时间（当前时间）发生了偏差。 这就是计时器漂移。
如果 React 不做任何补偿，会发生什么？
假设你有一个低优先级的任务（比如后台数据更新），它应该在 100ms 后执行。但是浏览器挂起了 500ms。React 醒来时，距离 100ms 已经过去了 500ms。
如果 React 还是按照“100ms 后执行”的逻辑，那这个任务早就过期了。如果 React 现在就立刻执行它，又可能会打断高优先级任务的执行。
所以，React 必须进行补偿。
第二章：补偿的核心算法——时间膨胀
React 的补偿算法其实非常优雅，它基于一个简单的数学概念：时间膨胀。
我们可以把它想象成一个“加速器”或“减速器”。当任务醒来时，React 会比较“预期时间”和“当前时间”。如果发现时间不够了（漂移发生了），React 就会根据任务的优先级，调整它的“时间流速”。
公式长这样（概念版）：
$$ T{new} = T{now} + (T{expected} – T{now}) times frac{P{current}}{P{task}} $$
听着有点晕？别急，我们翻译成人话。
- $T_{now}$：任务醒来的真实时间。
- $T_{expected}$：任务原本应该开始的时间。
- $P_{current}$：当前正在运行的任务的优先级（比如用户点击事件，这是高优先级）。
- $P_{task}$：被补偿的任务的优先级（比如后台更新，这是低优先级）。
这个公式的意思是：如果我现在是高优先级，我会觉得时间过得很快（膨胀系数变大）；如果我现在是低优先级，我会觉得时间过得很慢（膨胀系数变小）。
举个例子
假设任务 A 是一个低优先级任务（比如更新一个不显眼的统计数据），它的预期时间是 100ms。
场景 1：一切顺利
now= 0msexpected= 100ms- React 运行任务 A。
场景 2：浏览器挂起
now= 200ms（浏览器挂起了 100ms）expected= 100ms- 漂移量 = 100ms。
React 觉得：“糟糕，任务 A 被耽误了。但我现在正在处理一个高优先级任务（比如用户点击了按钮）。我不能让任务 A 立刻抢夺 CPU，但我也不能让它无限期地等下去。”
React 会计算一个新的 expected：
$$ 200 + (100 – 200) times frac{High}{Low} $$
因为 $High > Low$，括号里的结果是负数，乘以一个大于 1 的数，结果会更负。这意味着任务 A 的“预期时间”会被推得更远？不对，这里有个逻辑反转。
实际上，React 的逻辑是：“既然我迟到了，我就得想办法在剩余的预估工作量内完成。”
更准确的逻辑是：
如果任务 A 预计需要 work 单位的工作量，它原本有 time 时间。
现在它迟到了 delay 时间。
如果它还想在 time 时间内完成 work，它的工作速度必须变快。
速度 = 工作量 / 剩余时间。
所以，React 实际上是在压缩剩余的执行窗口。
让我们看源码（简化版）：
// React Scheduler 源码中的 runTask 逻辑
function runTask(task, currentTime) {
// 1. 获取任务的预期开始时间
const startTime = task.startTime;
// 2. 计算漂移
// 如果 currentTime > startTime，说明任务迟到了
const didTimeout = currentTime > startTime;
// 3. 计算剩余时间
// 如果没迟到，剩余时间就是 deadline - currentTime
// 如果迟到了，剩余时间就是 0（或者极小值，迫使立即执行）
let timeRemaining = didTimeout ? 0 : task.expirationTime - currentTime;
// 4. 核心补偿逻辑：时间膨胀
// 如果任务迟到了，我们不仅要执行它，还要根据当前任务的优先级调整它的“速度”
// 这里的逻辑稍微复杂一点，涉及 getCurrentPriorityLevel 和任务的 priority
// 但核心思想是：高优先级任务醒来后，会“吃掉”更多的时间，从而加速低优先级任务的流逝
if (didTimeout) {
// 如果任务过期了，我们怎么补偿？
// 我们不能直接执行，因为可能打断当前的高优先级任务
// 我们会把这个任务重新调度，但是给它一个更紧的 deadline
// 或者，如果当前任务优先级很高，我们会压缩这个任务的执行窗口
// 这是一个简化的示意
const timeSpent = currentTime - startTime;
const timeLeft = task.expirationTime - currentTime;
// 如果时间不够了，我们需要计算“加速比”
// 比如，原本有 100ms，现在只剩 50ms，但还得干 100ms 的活
// 那么我们需要 2 倍速
const speed = 1 + (timeSpent / timeLeft);
// 将计算出的速度应用到任务的调度上
// 具体实现中，这通过调整任务的 priority 或者 deadline 来体现
}
// 5. 执行任务
// 如果还有时间，执行；如果时间不够，切出去
const didTaskComplete = task.callback(currentTime, timeRemaining);
if (didTaskComplete) {
// 任务完成了，从队列里删掉
removeTaskFromQueue(task);
} else {
// 任务没完成，重新调度
// 这里的重新调度，会再次触发漂移补偿
scheduleTask(task, currentTime);
}
}第三章：源码深扒——advanceTimers 与 shouldYieldToHost
为了真正理解补偿，我们必须看看 scheduler 包里的两个核心函数：advanceTimers 和 shouldYieldToHost。
3.1 advanceTimers：唤醒沉睡的任务
当浏览器主线程终于有空闲时，React 会调用 advanceTimers。
// 简化版的 advanceTimers
function advanceTimers(currentTime) {
// 1. 遍历所有等待中的任务
// 注意：这里使用 while 循环，因为可能会连续唤醒多个任务
while (taskQueue.length > 0) {
const task = peek(taskQueue);
// 2. 检查任务是否到期
// 如果 当前时间 >= 任务的开始时间
if (task.startTime <= currentTime) {
// 3. 移除任务并执行
dequeue(taskQueue, task);
runTask(task, currentTime);
} else {
// 4. 如果第一个任务还没到时间，那就没别的任务能跑了
break;
}
}
}关键点来了！
当 runTask 被调用时，React 会传入 currentTime（也就是任务被唤醒的真实时间）。
如果任务是在 10:00 开始的，但浏览器挂起了，runTask 在 10:05 才被调用。
这时候，React 检查到 10:05 > 10:00。这意味着任务迟到了。
React 会进入“补偿模式”。
3.2 shouldYieldToHost：决定是否让出控制权
在执行任务时，React 需要决定是“一口气干完”还是“干一会儿就休息”。
function shouldYieldToHost() {
// 1. 获取当前时间
const currentTime = getCurrentTime();
// 2. 检查是否超出了浏览器的帧预算
// 比如，我们设定每一帧最多执行 5ms
if (currentTime >= frameDeadline) {
return true;
}
// 3. 如果没超时，检查是否有更高优先级的任务在等待
// 这就是为什么 React 要做补偿的原因之一
// 如果我们正在执行一个低优先级任务，但高优先级任务已经过期了
// 我们必须立刻让出 CPU 给高优先级任务
// 检查是否有高优先级任务到期
if (advanceTimers(currentTime)) {
return true;
}
// 4. 检查当前任务是否执行了太久
// 如果执行了太久，也要让出控制权，保证 UI 响应
if (didTimeout) {
return true;
}
return false;
}这里有一个微妙的逻辑：
如果 advanceTimers 发现有一个高优先级任务到期了，它会把这个任务“插队”到当前正在执行的任务之前。
这就形成了一个动态的优先级调整。
第四章：实战演练——构建一个“漂移补偿”模拟器
光说不练假把式。让我们写一个简化的 React 调度器，来模拟浏览器挂起的情况，并看看补偿算法是如何工作的。
我们假设：
- 我们有两个任务：A（高优先级，比如用户输入），B（低优先级，比如日志记录）。
- 浏览器在执行任务 B 时会挂起（模拟 GC）。
- 我们手动控制时间流逝。
class FakeBrowser {
constructor() {
this.currentTime = 0;
this.isSuspended = false;
this.suspendDuration = 0;
this.suspendTimer = null;
}
// 模拟浏览器挂起
suspend(ms) {
this.isSuspended = true;
this.suspendDuration = ms;
console.log(`[Browser] 挂起中... 持续 ${ms}ms`);
this.suspendTimer = setTimeout(() => {
this.isSuspended = false;
this.currentTime += ms; // 挂起结束后，时间继续流逝
console.log(`[Browser] 恢复运行。当前时间: ${this.currentTime}ms`);
}, ms);
}
}
// 模拟 React 调度器
class ReactScheduler {
constructor() {
this.taskQueue = [];
this.currentTime = 0;
this.frameBudget = 5; // 每帧最多执行 5ms
}
// 调度任务
schedule(task, priority, expectedStartTime) {
this.taskQueue.push({
id: task.name,
fn: task.fn,
priority: priority, // 1 = Low, 10 = High
expectedStartTime: expectedStartTime,
remainingWork: 100 // 假设每个任务需要 100ms 的计算量
});
// 按优先级排序，高优先级在前
this.taskQueue.sort((a, b) => b.priority - a.priority);
}
// 执行一个任务帧
runFrame(browser) {
if (browser.isSuspended) return;
// 1. 尝试唤醒任务
// 如果当前时间 >= 任务预期时间，就唤醒它
const taskToRun = this.taskQueue.find(t => this.currentTime >= t.expectedStartTime);
if (!taskToRun) {
// 没任务了，或者还没到时间
return;
}
console.log(`n[Scheduler] 醒来执行: ${taskToRun.id}`);
console.log(` 预期时间: ${taskToRun.expectedStartTime}ms`);
console.log(` 当前时间: ${this.currentTime}ms`);
console.log(` 漂移量: ${this.currentTime - taskToRun.expectedStartTime}ms`);
// 2. 计算补偿
// 核心逻辑：如果任务迟到了，我们需要计算“加速比”
// 加速比 = (原本的剩余时间) / (现在的剩余时间)
// 注意：这里的剩余时间是相对于 expirationTime 的，不是 expectedStartTime
let timeRemaining = 0;
let speed = 1;
if (this.currentTime > taskToRun.expectedStartTime) {
// 任务迟到了！
// 假设任务原本在 100ms 结束
const expirationTime = taskToRun.expectedStartTime + 100;
timeRemaining = expirationTime - this.currentTime;
// 如果时间不够了，我们需要加速
// 比如，原本有 100ms 剩余，现在只剩 50ms，但还得干 100ms 的活
// 那么我们需要 2 倍速
if (timeRemaining < taskToRun.remainingWork) {
speed = taskToRun.remainingWork / timeRemaining;
console.log(` ⚠️ 时间漂移! 速度加速: ${speed.toFixed(2)}x`);
}
}
// 3. 执行任务
// 我们模拟执行，但根据 speed 来消耗时间
// 如果 speed > 1，说明我们在“快进”
let workDone = this.frameBudget * speed;
if (workDone > taskToRun.remainingWork) {
workDone = taskToRun.remainingWork;
}
taskToRun.remainingWork -= workDone;
this.currentTime += this.frameBudget; // 真实时间流逝
console.log(` 剩余工作量: ${taskToRun.remainingWork.toFixed(2)}`);
// 4. 检查是否完成
if (taskToRun.remainingWork <= 0) {
console.log(` ✅ 任务 ${taskToRun.id} 完成`);
this.taskQueue = this.taskQueue.filter(t => t !== taskToRun);
} else {
// 5. 如果没干完，重新调度
// 关键点：重新调度时，我们会再次计算漂移和速度
this.schedule(taskToRun, taskToRun.priority, this.currentTime);
}
}
}
// --- 测试场景 ---
const browser = new FakeBrowser();
const scheduler = new ReactScheduler();
// 任务 A：高优先级，预计 100ms 开始，需要 50ms
scheduler.schedule({ name: 'Task A (High)', fn: () => {} }, 10, 100);
// 任务 B：低优先级，预计 100ms 开始，需要 100ms
scheduler.schedule({ name: 'Task B (Low)', fn: () => {} }, 1, 100);
console.log("=== 开始调度 ===");
// 模拟主循环
let loop = setInterval(() => {
if (scheduler.taskQueue.length === 0) {
clearInterval(loop);
return;
}
// 执行一帧
scheduler.runFrame(browser);
// 随机挂起浏览器，模拟漂移
if (Math.random() > 0.7 && scheduler.taskQueue.length > 0) {
browser.suspend(Math.floor(Math.random() * 20) + 10); // 挂起 10-30ms
}
}, 5); // 每 5ms 模拟一帧
代码解读
看上面的代码，你可能会发现几个有趣的现象：
- 任务 A 一直等到 100ms 才开始：因为它优先级高，且时间到了。
- 任务 B 在 100ms 开始，但浏览器马上挂起：
- 当任务 B 开始时，时间是 100ms。
- 浏览器挂起了 20ms。
- 当浏览器恢复时，时间是 120ms。
- 任务 B 的
expectedStartTime是 100ms，但currentTime是 120ms。 - 漂移量 = 20ms。
- 速度加速：
- 任务 B 还没完成（剩余 100ms）。
- 重新调度时，React 检测到时间不够了。
- 它计算
speed = 100 / (120 + 100 - 120)-> 速度 > 1。 - 在下一帧，任务 B 会以 2 倍的速度执行。
- 这就是时间膨胀补偿。
第五章：深入 Fiber 与 Deadline
上面的模拟器很简陋，React 的实现要复杂得多。React 18 引入了 Concurrent Mode（并发模式），这离不开 Fiber 架构和 deadline 对象。
5.1 Fiber 节点的时间属性
每个 Fiber 节点（React 的虚拟 DOM 树的节点）都携带了一些时间相关的属性：
function FiberNode(type, props, key, mode) {
// ... 其他属性
this.mode = mode;
// 调度相关
this.pendingLanes = 0; // 等待处理的位掩码
this.lanes = 0; // 当前节点的位掩码
this.childLanes = 0; // 子树的位掩码
// 时间相关
this.expirationTime = NO_TIME; // 这个任务何时过期
this.sortLanes = 0;
// ...
}5.2 requestWork 与 requestIdleCallback
React 使用 requestIdleCallback（或 setTimeout 的 polyfill）来获取 deadline。
function scheduleWork(root, expirationTime) {
// 1. 计算时间
const currentTime = getCurrentTime();
// 将 expirationTime 转换为 lane bits（位掩码）
const lanes = lanesToExpirationTime(expirationTime);
// 2. 更新根节点
root.pendingLanes |= lanes;
root.expiredLanes |= lanes;
// 3. 调度
// 如果没有在调度，就发起调度请求
if (!isScheduled) {
isScheduled = true;
// 核心调用：请求浏览器在 deadline 时执行 render
requestHostCallback(performConcurrentWorkOnRoot);
}
}5.3 performConcurrentWorkOnRoot 中的补偿逻辑
这是最核心的部分。当 performConcurrentWorkOnRoot 被调用时，React 会检查 deadline。
function performConcurrentWorkOnRoot(root) {
const currentTime = getCurrentTime();
// 1. 检查是否有高优先级任务需要插队
// 如果 root.expiredLanes > 0，说明有任务过期了
if (root.expiredLanes !== NoLanes) {
// 强制执行（同步模式）
renderRootSync(root);
} else {
// 2. 并发模式执行
// 计算剩余时间
const remainingTime = currentTime - renderExpirationTime;
// 检查是否应该让出控制权
if (remainingTime > 0) {
// 如果还有时间，就继续执行
// 这里的逻辑是：我们尽量多干点活，但不超过 deadline
renderRootConcurrent(root);
} else {
// 3. 时间不够了！
// 这里就是“漂移”发生的地方。
// 如果我们在 deadline 前没干完，React 会挂起，等到下一个 deadline 再次唤醒。
// 但下次唤醒时，如果 deadline 过期了，React 就必须切换到同步模式。
// 简单的补偿策略：
// 如果 deadline 到了，但任务没干完，React 会“挤压”接下来的时间。
// 这通过调整 root.expirationTime 来实现。
// 如果时间紧迫，expirationTime 会被设为 0（立即执行）。
}
}
}第六章：为什么我们不能直接用 setTimeout？
你可能会问：“React 调度器这么复杂，为什么不直接用 setTimeout(callback, 0)？”
这是一个非常好的问题。
- 精度问题：
setTimeout的精度受限于浏览器。通常最小是 4ms 或 10ms。在requestIdleCallback中，React 可以在每一帧的间隙执行任务，精度可以达到 5ms 级别。 - 任务优先级：
setTimeout只能设置延迟时间，不能设置优先级。React 需要能够随时打断一个低优先级的setTimeout，去执行一个高优先级的setTimeout。React 的调度器本质上是一个优先级队列。 - 时间漂移的动态调整：只有 React 自己知道什么时候挂起了，什么时候恢复了。
setTimeout不知道。React 必须在回调内部动态计算补偿。
第七章：哲学思考——过早优化是万恶之源？
在 React 的 scheduler 包中，你会发现大量的数学计算。为什么要这么做？
为了回答这个问题，让我们回到最初的问题：“为什么浏览器的时间会漂移？”
因为浏览器不是为 React 设计的。浏览器是为“原生应用”设计的。原生应用直接控制 CPU，时间就是线性的。而 Web 应用是运行在虚拟机里的，它必须分享资源。
如果你在 React 中写了一段极其耗时的代码（比如一个 10000 次循环的 for 循环），React 的调度器会试图把这段代码切分成小块。
// React 的切片逻辑
function workLoop() {
while (nextUnitOfWork !== null && !shouldYield()) {
nextUnitOfWork = performUnitOfWork(nextUnitOfWork);
}
}
function shouldYield() {
return getCurrentTime() >= frameDeadline;
}如果浏览器挂起了，frameDeadline 就不会更新。React 会以为时间还在流逝，于是拼命地执行 performUnitOfWork。
当浏览器恢复时，getCurrentTime() 突然跳到了未来。这时候，shouldYield() 会立即返回 true。React 会停下来，把控制权交还给浏览器。
这就是“时间膨胀”的副作用之一：如果浏览器挂得太久，React 会以为自己有无限的时间，从而执行完所有任务，导致页面在浏览器恢复时卡顿一下（因为所有计算都在一瞬间完成了）。
所以，React 的漂移补偿算法，本质上是在平滑这个过渡。
第八章：总结——时间管理大师
React 调度器中的计时器漂移补偿，是一个看似枯燥、实则精妙的设计。
它解决了一个核心矛盾：React 的任务期望与浏览器的现实之间的矛盾。
通过引入时间膨胀的概念，React 能够在任务醒来时，根据当前的优先级环境，动态调整任务的执行速度。这保证了：
- 高优先级任务（用户交互）永远不会被低优先级任务（后台更新）饿死。
- 低优先级任务（后台更新）即使被浏览器挂起，也能在恢复后得到合理的补偿，而不会因为太慢而被遗忘。
- 用户体验的连贯性。
下次当你点击按钮，页面瞬间响应，而你却感觉不到任何卡顿时，请感谢 React 的调度器。它就像一个精明的经纪人，在混乱的娱乐圈（浏览器）里，替你管理好每一个明星（任务）的时间表。
它知道什么时候该快进，什么时候该暂停，什么时候该插队。它不仅管理时间，它还管理期望。
好了，今天的讲座就到这里。不要忘记在你的代码里，也要学会“管理时间”。毕竟，代码写得好不好看是其次，能不能跑得快，那才是硬道理。
谢谢大家！