各位前端界的“炼金术士”们，大家好！
今天我们要聊的，是 React 源码中一个非常迷人、也非常关键的部分——时间切片。想象一下，你正在开一辆法拉利，但限速只有 10km/h，你会怎么做？你会换挡，一脚油门踩到底，然后立刻松开，再踩，再松开。这就是 React 并发模式的核心哲学：在每一帧里，尽可能多干活，如果干完了或者时间不够了，就停下来喘口气，把主线程还给浏览器去渲染界面。
而这一切的指挥官，就是 shouldYield 函数。
这哥们儿到底怎么知道“时间不够了”？它是怎么判定当前帧的剩余时间是否充足的？今天，我们就把 React 的调度器（Scheduler）像剥洋葱一样剥开，看看它到底在搞什么鬼。
第一章：浏览器的心跳与 RAF
首先，我们要理解“帧”这个概念。现代显示器通常以 60Hz 的频率刷新，意味着每一秒钟屏幕会闪烁 60 次。这意味着，每一帧的时间是固定的：1000ms / 60 ≈ 16.6ms。
这 16.6ms 是个什么概念？如果 React 在这 16.6ms 里干完了所有活，那页面就是丝滑的；如果 React 在这 16.6ms 里卡住了，还在算那个复杂的斐波那契数列，那页面就会卡顿，用户就会看到掉帧。
React 想要实现并发，就必须知道“当前帧还剩多少时间”。它不能随便写个 setTimeout(..., 0)，因为 setTimeout 的精度不够，而且它不跟浏览器的刷新频率同步。React 必须用浏览器最准的闹钟：requestAnimationFrame (RAF)。
RAF 是什么？它是浏览器专门为动画和重绘预留的 API。只要浏览器准备渲染下一帧，RAF 的回调就会触发。
让我们先看一段伪代码，感受一下 RAF 是怎么工作的：
// 这是一个极其简化的 RAF 循环
function renderLoop(deadline) {
// deadline 就是时间片！
console.log('当前帧开始，剩余时间：', deadline.timeRemaining());
// 假设我们要处理 1000 个任务
for (let i = 0; i < 1000; i++) {
// 做点工作...
doSomeWork();
// 关键点来了：这里我们需要检查是否该让出控制权了
if (shouldYield(deadline)) {
console.log('时间不够了，我去喝杯咖啡，下一帧再干！');
requestAnimationFrame(renderLoop); // 请求下一帧继续
return; // 直接返回，把主线程还给浏览器
}
}
console.log('所有任务搞定！');
requestAnimationFrame(renderLoop);
}
requestAnimationFrame(renderLoop);看到没？deadline 对象是 React 调度器的核心。它不仅告诉我们“还剩多少时间”，还告诉我们“我能不能早点醒过来”（didTimeout 属性）。
第二章：performance.now() 的精度魔法
但是，React 并没有直接用浏览器的 deadline，因为浏览器对 deadline.timeRemaining() 的支持并不一致，而且在某些老旧浏览器里，这个方法可能不存在。
React 的调度器（在 Scheduler 包里）自己造了一个轮子。它怎么知道时间呢？它用的是 performance.now()。
这个 API 是什么神仙？它返回的是一个高精度时间戳，单位是毫秒，精度可以达到微秒级（甚至更高）。它不是从页面加载开始算的，而是从 performance.now() 调用那一瞬间开始算的。
React 在每一帧开始的时候，会记录一个 startTime：
// Scheduler 源码中的简化逻辑
let startTime = performance.now();
function workLoop(deadline) {
// ... 处理任务 ...
// 核心计算：当前时间 - 开始时间 = 已用时间
// 剩余时间 = 16.6 - 已用时间
const timeRemaining = 16.6 - (performance.now() - startTime);
if (timeRemaining <= 0) {
// 时间耗尽，必须挂起
return;
}
}React 的调度器非常狡猾，它不仅仅依赖 RAF 的回调。因为 RAF 的回调触发频率是固定的（60fps），但 React 的任务可能需要更高的频率触发（比如 120fps，或者 4fps）。
于是，React 还用到了另一个黑科技：MessageChannel。
第三章：MessageChannel 与双缓冲
MessageChannel 是浏览器提供的两个“管道”之间的通信机制。一个在主线程，一个在“调度线程”。
React 的调度逻辑是这样的：
- RAF 机制：每 16.6ms 触发一次。它负责监控时间，如果发现时间快用完了，就挂起当前任务，把控制权交还给浏览器。这是“宏观控制”。
- MessageChannel 机制：这是一个“微观唤醒”。如果当前帧里有一个高优先级任务（比如用户点击了按钮，需要立刻响应），RAF 可能还没来得及触发，或者 RAF 触发时高优先级任务还没排到队。这时候，React 会通过
MessageChannel发送一个消息，强制主线程醒来去处理这个高优先级任务。
所以，shouldYield 的判定，其实是结合了这两者的结果。
第四章：shouldYield 的源码解剖
好了，理论铺垫得差不多了，让我们直接上干货。在 React 源码的 Scheduler 包中，shouldYield 的实现逻辑是这样的。
注意，React 源码为了跨浏览器兼容，封装了很多层。我们来看最核心的 unstable_shouldYield 函数（在 React 18+ 中通常对应 shouldYield）。
function unstable_shouldYield() {
// 1. 获取当前时间
const currentTime = performance.now();
// 2. 计算这一帧已经过去了多久
// frameDeadline 是 React 在每一帧开始时计算并存储的一个截止时间点
// 它通常被设置为 (currentTime + frameInterval) 的值，其中 frameInterval 通常是 5ms (为了留出 16ms 给浏览器渲染)
const timeElapsed = currentTime - currentFrameTime;
// 3. 更新当前帧的开始时间
currentFrameTime = currentTime;
// 4. 核心判定逻辑
// 如果时间已经超过了截止时间，说明本帧的任务太多了，必须让出主线程
return timeElapsed > frameDeadline;
}这里有一个非常关键的细节：frameDeadline。
React 不会傻傻地等到 16.6ms 才停下来。它会在每一帧开始时，就设定一个“截止时间”。这个截止时间通常是当前时间加上一个很小的值（比如 5ms）。
为什么要预留 5ms？因为光算完 React 的逻辑是不够的，浏览器还需要时间去合成层、去绘制像素、去执行垃圾回收（GC）。如果 React 算到 15ms，浏览器再算 1ms，那这一帧就超了，用户就会看到掉帧。
所以，shouldYield 的判定公式可以简化为：
function shouldYield(deadline) {
// 假设我们设定的每帧预算是 5ms
// deadline.timeRemaining() 返回的是浏览器估计的剩余时间
// 如果剩余时间 <= 0，说明本帧已经超时了
return deadline.timeRemaining() <= 0;
}第五章：实战演练——模拟一个 React 调度器
为了让你彻底明白，我们来手写一个简化版的 React 调度器。不依赖任何第三方库，只用原生 JS。
// 1. 定义任务队列
let taskQueue = [];
let currentTask = null;
// 2. 定义 shouldYield
function shouldYield() {
// 获取当前剩余时间
const timeRemaining = performance.now() - lastStartTime;
// 我们设定一个阈值，比如 5ms
// 如果已经用掉了 5ms，就认为时间不足
return timeRemaining > 5;
}
// 3. 模拟任务
function workTask(id) {
console.log(`正在处理任务 ${id}`);
// 模拟一些耗时操作
for (let i = 0; i < 1000000; i++) {
// 什么都不做，纯计算
Math.random() * Math.random();
}
}
// 4. 调度循环
function schedulerLoop() {
if (!currentTask) {
if (taskQueue.length > 0) {
currentTask = taskQueue.shift();
lastStartTime = performance.now(); // 重置这一帧的开始时间
} else {
return; // 队列空了，结束
}
}
// 执行当前任务的一部分（切片执行）
// 假设每个任务执行 1000 次循环
for (let i = 0; i < 1000; i++) {
workTask(currentTask);
// 每次执行完一部分，就检查一下时间
if (shouldYield()) {
console.log(`任务 ${currentTask} 暂停，主线程让渡给浏览器渲染...`);
// 把当前任务放回队列头部（或者保持原位，取决于调度策略）
// 这里我们简单地把它放回队首，或者直接返回
// 真正的 React 会把 currentTask 放回队列，然后请求下一帧
return;
}
}
console.log(`任务 ${currentTask} 完成`);
currentTask = null;
schedulerLoop(); // 递归调用，继续下一个任务
}
// 启动调度器
console.log("调度器启动...");
taskQueue = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10];
schedulerLoop();运行这段代码，你会发现，控制台会输出“正在处理任务…”，然后突然停顿一下，打印“主线程让渡给浏览器渲染…”，然后继续下一个任务。这就是 shouldYield 的魔力！
第六章：深入细节——deadline 对象的“双面性”
在 React 的源码中，shouldYield 接收的 deadline 对象非常特殊。它不仅告诉你“还剩多少时间”，还告诉你“你是不是被催了”。
function workLoop(deadline) {
while (nextUnitOfWork) {
// ... 执行工作 ...
// 判定
if (shouldYield(deadline)) {
break;
}
}
if (!nextUnitOfWork && !deadline.didTimeout) {
// 如果没有更多工作，且没有被超时打断，则挂起
requestIdleCallback(workLoop);
} else if (deadline.didTimeout) {
// 如果被超时打断，说明上一帧没干完，这一帧必须赶紧把剩下的干了
workLoop(deadline);
}
}这里有个非常有意思的逻辑分支：
didTimeout === false：这说明是浏览器正常调用（RAF 触发）。React 感到时间充裕，或者刚好用完，它就会挂起，把控制权交给浏览器去渲染。这是低优先级任务（比如后台更新数据）的常态。didTimeout === true：这说明浏览器那边“超时”了！用户等得不耐烦了，或者浏览器觉得这一帧已经晚了，强行唤醒了主线程。这时候，React 不能再休息了，必须立刻把剩下的任务干完，哪怕下一帧要掉帧也要把任务做完。这是高优先级任务（比如用户点击按钮）的常态。
第七章：为什么不用 setTimeout？
你可能会问：“既然要切时间片，为什么不用 setTimeout(fn, 0) 呢？”
这是一个非常经典的问题。答案是：精度不够，且不可控。
setTimeout(fn, 0) 的执行频率取决于浏览器的定时器粒度。在 PC 端通常是 4ms，在移动端可能是 10ms 或更高。这意味着你可能会每 10ms 切换一次任务，而不是每 16ms。这会导致 React 的计算量忽大忽小，且无法精确控制每一帧的负载。
而 requestAnimationFrame 是浏览器强制同步的。无论你的电脑多快，RAF 都会严格按照 60Hz（或显示器刷新率）触发。这让 React 的调度非常稳定，就像是在刻度尺上切披萨，每一片的大小都差不多。
第八章：源码中的“时间片”计算
让我们再深挖一下 React 源码中的 Scheduler 实现。在 src/Scheduler.js 中，你会看到这样的逻辑：
// 计算时间片的逻辑
function getCurrentTime() {
return performance.now();
}
// 计算优先级
function computePriorityLevel() {
// ...复杂的优先级计算逻辑...
}
// 核心调度函数
function scheduleCallback(priorityLevel, callback, options) {
// ...
const startTime = getCurrentTime();
// 计算截止时间
// 如果是高优先级，时间片可能很短；如果是低优先级，可能很长
const delay = options.delay;
const deadlineTime = startTime + (delay || 0);
const expirationTime = deadlineTime;
// 将任务放入队列
// ...
}注意那个 expirationTime（过期时间）。React 不仅仅看“当前帧剩多少时间”，它还看“这个任务还有多久过期”。
如果 shouldYield 返回 true，React 会把当前任务挂起，并记录下“任务还没干完，下次还要继续干”。当下一帧 RAF 触发时，React 会再次检查：“哎，这个任务还没过期，那我继续干！”
第九章：shouldYield 与渲染的博弈
这是一个非常微妙的平衡艺术。
如果 shouldYield 判定太严格（比如剩余 1ms 就 yield），那么 React 会在每一帧开始时频繁地挂起和恢复，导致大量的函数调用开销，反而降低性能。
如果 shouldYield 判定太宽松（比如剩余 15ms 才 yield），那么 React 就会霸占主线程，导致浏览器无法及时渲染，用户看到的就是“计算中…然后突然跳出一个界面”。
React 的调度器通常会在每帧开始时预留 5ms 给浏览器渲染。也就是说，shouldYield 的阈值大约是 5ms。
// 源码中的典型实现
function shouldYield() {
// 这里的 frameDeadline 是在 requestAnimationFrame 回调中计算出来的
return performance.now() > frameDeadline;
}第十章：总结——调度器的智慧
好了，让我们来总结一下 shouldYield 是如何判定时间的。
- 它依赖
performance.now()：这是最精准的时钟，让我们知道“现在”是几点。 - 它依赖
requestAnimationFrame：这是浏览器的闹钟，告诉它“下一帧什么时候来”。 - 它计算时间差：
当前时间 - 帧开始时间。 - 它对比阈值：如果时间差超过了预留的渲染时间（通常是 5ms），它就认为“时间不够了”。
- 它结合
didTimeout：如果浏览器催它，它就得拼命干。
React 的 shouldYield 就像一个精明的管家。它看着墙上的钟（RAF），手里拿着秒表（performance.now），看着一堆家务活（任务队列）。它心里有个数：“主人要在 16ms 后出门，我得在 5ms 后把客厅打扫好，剩下的 11ms 我可以慢慢擦窗户，但绝不能把沙发搬走。”
这就是 React 并发模式背后的数学之美。它没有魔法，只有对时间的精确计算和对主线程的敬畏。每一行 if (shouldYield()) 的背后，都是为了让你的网页在疯狂计算数据的同时，依然能流畅地滚动、点击和闪烁。
所以，下次当你看到 React 页面在处理大量数据时依然不卡顿，记得感谢那个默默计算的 shouldYield 函数。它就像一个不知疲倦的忍者，在每一帧的缝隙中，为你偷来了流畅的体验。