React 渲染过程中的时间戳建模：探究 Scheduler 内部如何通过 performance.now 实现纳秒级任务过期计算

各位，把手里的咖啡放一放，把那个正在疯狂刷新的页面停下来。

今天我们要聊的不是 React 的 Hooks 怎么用，也不是 JSX 是怎么被编译的，我们要聊的是 React 的“心脏”——也就是 Scheduler 模块。在这个模块里，时间不是用来计时的，是用来“算账”的。

想象一下，你的浏览器是一个巨大的、极度忙碌的厨房。React 是那个大厨，而 Scheduler 就是那个拿着秒表、精打细算的领班。如果大厨在切洋葱的时候突然停下来去炒菜，洋葱就会烂掉；如果他在炒菜的时候去切洋葱，整桌菜就会凉掉。

Scheduler 的核心任务，就是利用高精度时间戳，计算出“切洋葱”和“炒菜”的最佳时间差。如果这个差值算错了，你的页面就会卡顿；如果算得太紧，浏览器就会崩溃。而这一切的基石，就是 performance.now()。

准备好了吗？我们要开始解剖时间了。

---

第一章：为什么 Date.now() 是个“老古董”？

在深入 Scheduler 之前，我们必须先解决一个看似简单、实则致命的问题：我们怎么知道现在是几点？

在 JavaScript 的早期，大家都在用 Date.now()。这玩意儿就像你爷爷的怀表。它告诉你“现在是 2023 年”，但它不知道“现在是 2023 年 10 月 5 日的下午 3 点 0 分 0.001 秒”。

Date.now() 返回的是自 1970 年 1 月 1 日以来的毫秒数。它的精度受限于系统时钟的更新频率。在某些老旧系统或者高负载服务器上，Date.now() 可能会跳变，或者它的精度只有几十毫秒。这对于需要极其精确调度的 React 来说，简直就是灾难。

Enter performance.now()。

performance.now() 是现代浏览器提供的“原子钟”。它返回一个高精度的时间戳，单位是毫秒，但它不是从 1970 年算起的，它是从“页面加载的那一刻”开始算起的。

为什么这很重要？

因为 React 需要计算的是相对时间，而不是绝对时间。

假设你有一个任务，它需要在 100 毫秒后执行。

• 使用 Date.now()：你记录下 start = Date.now()，然后在循环里检查 if (Date.now() - start > 100)。如果系统时钟被 NTP 服务器修正了（比如从 1000ms 变成了 1005ms），你的计算就会出错。你可能会提前执行，或者永远不执行。
• 使用 performance.now()：你记录下 start = performance.now()。不管系统时钟怎么跳，performance.now() 总是连续增长的。它就像一条永远不会回头的单行道，保证了时间的绝对线性。

代码示例 1：高精度计时器的对决

console.log('--- Date.now() 测试 ---');
let dateStart = Date.now();
let dateEnd = Date.now();
console.log(`Date.now() 区间: ${dateEnd - dateStart} ms`);

console.log('--- performance.now() 测试 ---');
let perfStart = performance.now();
let perfEnd = performance.now();
console.log(`performance.now() 区间: ${perfEnd - perfStart} ms`);

// 注意观察，Date.now() 可能会因为系统时钟调整而产生巨大的时间跳跃
// 而 performance.now() 总是非常平滑，且精度极高（现代浏览器通常在微秒级）

在 React 的源码中，你会看到这样的定义：

// scheduler/src/forks/Clock.js
let now;
if (typeof __REACT_DEVTOOLS_GLOBAL_HOOK__ !== 'undefined' && 
    typeof __REACT_DEVTOOLS_GLOBAL_HOOK__.renderInterrupts === 'function') {
  // 开发环境下使用更精确的计时
  now = function () {
    return __REACT_DEVTOOLS_GLOBAL_HOOK__.renderInterrupts();
  };
} else {
  // 生产环境使用 performance.now()
  now = function () {
    return performance.now();
  };
}

这就是 Scheduler 的“眼睛”。它不依赖上帝（系统时钟），它只依赖自己。

---

第二章：时间建模的艺术——从“绝对”到“相对”

有了 performance.now()，我们就能开始建模了。但 Scheduler 做的事情比简单的“等待 X 毫秒”要复杂得多。它面临着一个经典的工程问题：如何在有限的时间里，尽可能多地处理任务？

这就引入了时间戳建模的核心概念：过期时间。

通常，我们会给一个任务设定一个“延迟”。比如，用户输入了一个搜索词，我们想 300ms 后再执行搜索，以节省性能。这个 300ms 就是延迟。

但是，Scheduler 并不关心“延迟”。Scheduler 关心的是什么时候必须执行。

公式：
$$ text{ExpirationTime} = text{startTime} + text{delay} $$

这里的 startTime 不是任务开始执行的时间，而是任务被加入调度队列的时间。

举个例子：
假设现在是 performance.now() = 1000ms。
我们有一个任务，设定延迟为 300ms。

1. 计算过期时间： 1000 + 300 = 1300ms。
2. 放入堆： Scheduler 把 1300 这个数字扔进它的“任务池”里。
3. 等待： Scheduler 什么都不做，它只是看着时间流逝。
4. 唤醒： 当 performance.now() 变成 1300ms 时，Scheduler 醒来，大喊一声：“嘿，那个 300ms 延迟的任务过期了！快给我！”

为什么这样建模？

因为 React 不仅要处理延迟任务，还要处理“紧急任务”。

• 紧急任务（如点击按钮）：React 需要立即响应。它的延迟可能是 0。
• 低优先级任务（如非关键的数据计算）：React 可以让它晚点跑。

通过比较 performance.now() 和任务的 ExpirationTime，Scheduler 可以瞬间判断出：“现在这个任务必须马上做，还是可以再睡一会儿？”

---

第三章：数据结构——为什么是堆？

如果你是个新手，你可能会想：“我直接用数组不就行了？[1300, 1200, 1400]，然后排序一下？”

别傻了，React 每秒要处理成千上万个状态更新。每次排序都是 $O(N log N)$。如果是每秒 60 帧的动画，每帧都要排序？那你的浏览器还没开始渲染，CPU 就烧了。

Scheduler 需要一种结构，既能快速插入新任务，又能快速取出最早过期的任务。

这个结构就是：最小堆。

在计算机科学中，最小堆就像是一个“按时钟排序”的队列。堆顶永远是最小的元素。

代码示例 2：一个极简的 React Scheduler 堆操作

虽然 React 的源码用的是更底层的 C++ 或优化过的 JS，但逻辑是一样的。

class TaskQueue {
  constructor() {
    this.heap = [];
  }

  // 插入任务（入堆）
  add(task) {
    // 简单的插入逻辑，实际 React 会优化内存
    this.heap.push(task);
    this.bubbleUp(this.heap.length - 1);
  }

  // 弹出最早过期的任务（堆顶）
  getNext() {
    if (this.heap.length === 0) return null;
    const min = this.heap[0];
    const end = this.heap.pop();
    if (this.heap.length > 0) {
      this.heap[0] = end;
      this.sinkDown(0);
    }
    return min;
  }

  // 辅助函数：上浮（为了保持堆序性质）
  bubbleUp(n) {
    const element = this.heap[n];
    while (n > 0) {
      let parentN = Math.floor((n + 1) / 2) - 1;
      let parent = this.heap[parentN];
      if (element.expirationTime >= parent.expirationTime) break;
      this.heap[parentN] = element;
      this.heap[n] = parent;
      n = parentN;
    }
  }

  // 辅助函数：下沉
  sinkDown(n) {
    const length = this.heap.length;
    const element = this.heap[n];
    while (true) {
      let child2N = (n + 1) * 2;
      let child1N = child2N - 1;
      let swap = null;
      let child1, child2;

      // 比较子节点
      if (child1N < length) {
        child1 = this.heap[child1N];
        if (child1.expirationTime < element.expirationTime) {
          swap = child1N;
        }
      }

      if (child2N < length) {
        child2 = this.heap[child2N];
        if (
          (swap === null && child2.expirationTime < element.expirationTime) ||
          (swap !== null && child2.expirationTime < child1.expirationTime)
        ) {
          swap = child2N;
        }
      }

      if (swap === null) break;
      this.heap[n] = this.heap[swap];
      this.heap[swap] = element;
      n = swap;
    }
  }
}

看懂了吗？每次我们插入一个任务，我们只需要做 $O(log N)$ 的操作。每次我们要取最早过期的任务，只需要看堆顶。这就是纳秒级计算的基础——高效的数据结构。

---

第四章：纳秒级调度的“呼吸”节奏

有了时间戳，有了堆，接下来就是最激动人心的部分：Scheduler 到底什么时候醒来？

你不能让 Scheduler 每一微秒都去查一次堆，那 CPU 就要报警了。你也不能让它睡一整天，那用户点击按钮半天没反应，用户就会把你的网站卸载。

Scheduler 的策略是混合模式：RAF + Idle。

1. RAF (requestAnimationFrame)： 浏览器提供了一个 API，它承诺在下一帧渲染开始前调用回调。这意味着每 16.6 毫秒（60fps）一次。这是“高精度”的节拍器。
2. Idle (requestIdleCallback)： 浏览器提供的 API，在主线程空闲时调用。这是“偷懒”的时间，用来处理低优先级的任务。

代码示例 3：Scheduler 的核心循环逻辑

let deadline = 0;
let isPerformingWork = false;
let currentTask = null;

function schedule() {
  // 如果已经在工作了，就别重复调用了
  if (isPerformingWork) {
    return;
  }
  isPerformingWork = true;

  // 1. 找出最早过期的任务
  const nextTask = taskQueue.getNext();
  if (!nextTask) {
    // 如果没有任务，就挂起
    isPerformingWork = false;
    return;
  }

  // 2. 计算当前时间
  const currentTime = performance.now();

  // 3. 关键判断：时间到了吗？
  if (currentTime >= nextTask.expirationTime) {
    // 如果时间到了，必须执行
    currentTask = nextTask;
    performTask(currentTask);
  } else {
    // 如果时间没到，我们需要等待
    // 但是我们不能傻等，我们要利用浏览器的空闲时间
    requestIdleCallback(handleIdleWork, { timeout: nextTask.expirationTime - currentTime });
  }
}

function handleIdleWork(deadline) {
  // 如果 deadline.timeRemaining() > 0，说明浏览器还有空闲时间
  if (deadline.timeRemaining() > 0) {
    schedule(); // 继续调度下一个任务
  } else {
    // 时间到了，或者浏览器不空闲了，把控制权交还给主线程
    // React 会根据 currentTask 的优先级决定是继续还是暂停
  }
}

这里有个细节：deadline.timeRemaining()。这是 requestIdleCallback 传给回调的一个对象。

假设你有两个任务：

1. 任务 A：延迟 500ms（高优先级）。
2. 任务 B：延迟 2000ms（低优先级）。

• T=0ms: 任务 A 入队，过期时间 500ms。任务 B 入队，过期时间 2000ms。
• T=0ms: Scheduler 看了一眼，现在 0ms，A 还没过期（500ms > 0ms）。B 还没过期。
• T=0ms: requestIdleCallback 被调用。浏览器说：“行，我在 T=500ms 之前有空闲时间给你。”
• T=100ms: 浏览器渲染了一帧。主线程忙碌。requestIdleCallback 的回调没被触发。
• T=500ms: 时间到了！任务 A 过期了。Scheduler 立即停止空闲等待，执行任务 A。
• T=550ms: 任务 A 执行完毕。Scheduler 再次检查任务 B。现在 550ms，B 的过期时间是 2000ms，还没到。Scheduler 再次调用 requestIdleCallback，设定超时时间为 1450ms。

这就是纳秒级过期计算的精髓：精确计算差值。

---

第五章：React 的魔法——useTransition 与时间预算

现在我们知道了 Scheduler 是怎么算时间的，那 React 是怎么用这个能力的？这就不得不提 useTransition。

useTransition 的核心就是给任务分配一个“时间预算”。

在 React 18 之前，所有状态更新都是“紧急”的。比如你输入文字，React 必须立刻渲染，哪怕你输入的速度很快。这导致了输入延迟（输入卡顿）。

React 18 引入了 startTransition。当你把一个状态更新标记为 isTransitioning 时，Scheduler 就知道：“嘿，这个任务虽然很重要，但它不是最最紧急的。我有 4ms 的时间给它。”

代码示例 4：模拟 useTransition 的内部逻辑

function startTransition(isTransition, updateFunction) {
  // 1. 记录开始时间
  const startTime = performance.now();

  // 2. 将任务放入队列，但给予一个较长的过期时间（比如 250ms）
  // 之所以给长过期时间，是为了在浏览器空闲时慢慢做，而不是卡住主线程
  const task = {
    expirationTime: startTime + 250, // 时间预算
    priority: isTransition ? 'transition' : 'urgent',
    fn: updateFunction
  };

  // 3. 加入堆
  taskQueue.add(task);

  // 4. 触发调度
  schedule();
}

场景模拟：

用户在搜索框输入 “React”。

1. Urgent Task (输入框内容): 延迟 0ms。Scheduler 必须在 0ms 内执行。用户能看到自己输入的每一个字。
2. Transition Task (搜索结果列表): 延迟 250ms。Scheduler 把它放进堆里，设置过期时间为 now + 250。

时间线：

• T=0ms: 用户输入 ‘R’。Urgent Task 执行。界面显示 ‘R’。
• T=1ms: 用户输入 ‘e’。Urgent Task 执行。界面显示 ‘Re’。
• …
• T=10ms: 用户输入 ‘a’。Urgent Task 执行。界面显示 ‘Rea’。
• T=15ms: Transition Task 入队。过期时间 = 265ms。
• T=16ms: 用户输入 ‘c’。界面显示 ‘React’。
• T=17ms: 浏览器空闲了！requestIdleCallback 触发。Scheduler 检查堆：Urgent Task 是空的（刚才执行完了）。Transition Task 的过期时间是 265ms，现在才 17ms，没过期。
• T=18ms: 继续空闲。Scheduler 继续等待。
• T=20ms: 浏览器空闲。Scheduler 检查：现在 20ms，Task 过期时间 265ms。没过期。继续等待。
• …
• T=265ms: 任务过期！React 开始渲染搜索结果列表。

在这个过程中，performance.now() 的精度保证了用户输入的每一个字符（Urgent Task）都得到了即时反馈，而搜索列表（Transition Task）则在浏览器稍微空闲的间隙被渲染了。

这就是 React 的并发模式——在时间的缝隙中跳舞。

---

第六章：纳秒级溢出与边界情况

作为一个资深专家，我不能只讲美好的场景。我们必须谈谈“坑”。

performance.now() 返回的是一个双精度浮点数。它大约有 15-17 位的有效数字。虽然这已经非常长了，但在极端情况下，时间可能会发生溢出。

在 React 的源码中，有一个非常精妙的处理：expirationTime 的计算方式。

React 并不直接使用 startTime + delay。因为它使用了时间乘法来压缩数值范围。

expirationTime 的单位是“ms”，但它被乘以一个系数（比如 5）。这样，即使时间到了 2^31 毫秒（大约 24 天），它也不会溢出 32 位整数。这是底层的 C++ 优化，但在 JS 层面，我们依然可以看到这种时间压缩的影子。

另外，还有一个问题：如果 performance.now() 的精度不够怎么办？

虽然现代浏览器支持微秒级精度，但旧浏览器可能只有 10ms。如果任务是在 5ms 后过期，而 performance.now() 只能精确到 10ms，那 Scheduler 可能会误判。

React 的 Scheduler 采用了一种“提前量”策略。
它不会等到 expirationTime 刚到的那一微秒才执行。它会稍微提前一点点执行，比如在 expirationTime - 1ms 的时候就检查。这就像是你设定闹钟是 7:00，你不会等到 7:00:00:001 才起床，你会在 6:59:59:999 就起来。

代码示例 5：处理时间溢出的边界检查

function checkTaskExpiration(currentTime, task) {
  // 1. 计算过期时间
  const expirationTime = currentTime + task.delay;

  // 2. 防止溢出检查（伪代码，实际在源码中）
  // 如果 currentTime 是正数，delay 也是正数，但加起来溢出了
  if (currentTime > 0 && expirationTime < currentTime) {
    // 这是一个巨大的延迟，或者时间系统出了问题
    // React 会把任务标记为“立即过期”
    return Infinity; 
  }

  // 3. 比较当前时间与过期时间
  if (currentTime >= expirationTime) {
    return 'expired';
  }
  return 'pending';
}

---

第七章：源码视角——那个名为 shouldYield 的函数

最后，让我们把镜头拉近，看看 React 源码中那个决定生死的函数：shouldYield。

在 Scheduler 的核心循环中，有一个机制叫 yield（让步）。这意味着即使任务没做完，也要把主线程的控制权交还给浏览器，让浏览器有机会去渲染画面或者响应用户输入。

shouldYield 的逻辑非常简单，但极其重要：

function shouldYield(currentTime) {
  // 1. 获取当前帧的截止时间
  // React 设定了一个最大预算，比如 5ms（用于紧急任务）或者 25ms（用于非紧急任务）
  const frameDeadline = currentTime + frameDeadlineValue;

  // 2. 如果当前时间超过了截止时间，说明这一帧已经满了
  // 或者，用户正在交互（鼠标移动、键盘敲击），React 必须让出控制权
  return currentTime >= frameDeadline || isUserInteracting;
}

这里有个哲学问题：什么是“渲染完成”？

对于 React 来说，渲染完成不是指 React 代码跑完了。而是指 React “准备好” 下一帧的画面了。

如果在渲染过程中，用户突然点击了屏幕，React 必须立刻停止当前的渲染，去处理点击事件。这就是 isUserInteracting 的作用。

总结一下这个循环：

1. performance.now() 告诉我们现在是几点。
2. 我们计算任务的 expirationTime。
3. 我们用最小堆维护这些时间戳。
4. 在每一帧开始时，我们检查 shouldYield。
5. 如果时间到了，或者用户动了，我们就 yield。
6. 如果任务过期了，我们就 performWork。

---

结语：时间就是金钱，时间就是性能

好了，各位。

我们今天从 Date.now() 的老黄历聊到了 performance.now() 的原子钟，从简单的数组排序聊到了复杂的最小堆算法，从 requestIdleCallback 的空闲时间聊到了 useTransition 的并发魔法。

React 的 Scheduler 并不是什么黑魔法，它只是极其精巧地利用了浏览器提供的高精度计时 API，配合数据结构算法，在极短的时间内（微秒级）做出了复杂的决策。

它就像一个不知疲倦的管家，时刻盯着时钟，计算着每一个任务的剩余时间，在浏览器最需要呼吸的时候，悄悄地把控制权交出去，只为了给你呈现一个流畅、丝滑的 UI。

下次当你看到 0.5s 的加载动画，或者输入框里的文字跟得上你的手速时，请记住，那不仅仅是 React 的功劳，更是 Scheduler 对那一纳秒、那一微秒时间的完美把控。

现在，去检查一下你的代码，看看有没有那种“不管三七二十一，一上来就全量渲染”的臭毛病吧。优化时间，就是优化生命。

（全场鼓掌）