React 时间分片与物理阈值：一场关于“不卡顿”的极限拉扯
各位听众，大家好！
我是你们那个在凌晨三点还在跟浏览器报错死磕的资深前端工程师。今天我们不聊那些花里胡哨的 UI 库，也不聊那些为了省两行代码而写出的屎山代码。今天，我们要深入 React 的“内脏”，去聊聊它是如何在这个单线程、极其暴躁的 JavaScript 引擎里，通过时间分片这种技术手段，试图把那些看起来像“大象”一样的计算任务，切成“蚂蚁”一样的大小，塞进浏览器这个“只能干活的流水线”里的。
准备好了吗？我们要开始解剖了。
第一章：主线程的暴脾气
首先，我们要理解一个物理事实：JavaScript 是单线程的。
这就好比你的电脑只有一个大脑，而且这个大脑还是个“死脑筋”。当浏览器主线程在执行 JavaScript 代码时，它就不能干别的。比如，它不能去渲染下一帧的动画，不能去处理用户的鼠标点击事件，甚至不能去收发网络数据包。
这时候，如果你在 React 里写了一个 useEffect，里面搞了一个 for (let i = 0; i < 10000000; i++) { ... }。这就像是让那个死脑筋的大脑一口气背下一本《新华字典》。
结果是什么？大脑会死机。
在浏览器里，这就叫 Jank（卡顿）。用户的屏幕会瞬间冻结，那个可怜的旋转的加载圈会转得比蜗牛还慢，甚至直接变成白屏。因为主线程被你的死循环占满了，它没时间去画下一帧。
所以，React 以前是怎么做的？它就像个不懂变通的强迫症，非要把一棵树（虚拟 DOM 树）一次性算完。如果树太深、节点太多，主线程就罢工了。这就是所谓的“同步渲染”。
第二章：Fiber 架构——给大脑装上“暂停键”
React 16 以后，引入了 Fiber 架构。很多同学看到这个词就头大，觉得是玄学。其实没那么玄乎。
你可以把 Fiber 理解为 React 内部的一个调度系统，或者更通俗点说，它是给 React 的渲染过程装上了“暂停键”和“恢复键”。
以前的 React 渲染：
开始渲染 -> (执行 1, 2, 3...10000) -> 渲染完成
现在的 React 渲染（Fiber）：
开始渲染 -> 执行节点1 -> (等等，时间到了) -> 暂停 -> (浏览器去画个图) -> (过一会) -> 恢复 -> 执行节点2 -> (等等，时间到了) -> 暂停 -> ...
这个“暂停”和“恢复”的间隔，就是我们要深入分析的物理阈值。
第三章：什么是物理阈值？
这是今天的重头戏。所谓的“物理阈值”，并不是 React 想出来的，而是由浏览器硬件和人眼感知共同决定的物理极限。
1. 16ms 法则（帧预算）
现代显示器通常是 60Hz 的，意味着每秒钟屏幕刷新 60 次。每一帧的刷新时间就是 1000ms / 60 ≈ 16.67ms。
这 16.67ms 被分成了几块：
- 16ms：留给浏览器绘制 UI 的时间。
- 16ms – 10ms：留给 JavaScript 计算逻辑的时间。
- 16ms – 5ms：留给浏览器合成层（Composite）和绘制的时间。
- 5ms：留给操作系统和其他事件处理的时间。
如果你在 JavaScript 里执行任务的时间超过了 16ms，那么下一帧的绘制就会推迟。当延迟累积起来，用户的画面就会变成 30fps 甚至更低。这种卡顿，人眼是能非常敏锐地捕捉到的。
2. 50ms 法则（感知阈值）
虽然 16ms 是物理极限，但如果你在 17ms、18ms 甚至 20ms 完成计算，用户可能还觉得流畅。但如果你的计算时间超过了 50ms，用户就会感觉到明显的“卡顿”。
为什么是 50ms？
因为人眼对运动的感知有一个特性：如果连续两帧之间的间隔超过了 50ms，大脑就会把这看作是“卡顿”或者“掉帧”。
3. 浏览器的“死刑判决”
除了 React 自己的阈值，浏览器还有一个硬性的物理限制。在 Chrome 等现代浏览器中，如果一个脚本执行时间过长（通常是超过 50ms，具体取决于硬件和负载），浏览器会判定这个脚本是“长任务”，并强制将其挂起，转而去处理高优先级的 UI 渲染。
这就是浏览器为了防止整个页面彻底死机而设下的“物理防火墙”。
第四章：时间分片的核心逻辑——如何切分？
基于上述物理阈值，React 的 Time Slicing（时间分片） 策略就诞生了。
它的核心逻辑非常简单粗暴：把一个大的任务，切分成多个小的任务，每个小任务只执行一点点，然后立刻交出控制权给主线程。
当主线程空闲时，React 再回来继续执行下一个小任务。
代码实战：原生 JS 的时间分片
让我们先不看 React 源码，用原生 JS 写一个最简单的“时间分片”模拟器，以此理解其中的阈值控制。
// 模拟一个耗时任务：生成 10000 个虚拟 DOM 节点
function heavyTask() {
const total = 10000;
for (let i = 0; i < total; i++) {
// 做一些无意义的计算
Math.random() * Math.random();
// 做一些 DOM 操作
const div = document.createElement('div');
div.innerText = `Node ${i}`;
document.body.appendChild(div);
}
}
// 同步执行：直接调用，你会看到浏览器卡死
// heavyTask();
// 异步分片执行
function scheduleHeavyTask() {
const total = 10000;
let i = 0;
function step() {
// 1. 设定阈值：每次循环处理多少个节点？
// 假设我们每次只处理 50 个节点，耗时约 1-2ms
// 这样我们就能在一个渲染帧内完成多次循环
const batchSize = 50;
const start = performance.now();
// 2. 执行一批任务
while (i < total && (performance.now() - start) < 2) { // 限制每次执行不超过 2ms
const div = document.createElement('div');
div.innerText = `Node ${i}`;
document.body.appendChild(div);
i++;
}
// 3. 检查是否完成
if (i < total) {
// 4. 关键点：立即交出主线程控制权
// 使用 requestAnimationFrame 或者 setTimeout(fn, 0)
requestAnimationFrame(step);
} else {
console.log('任务完成！');
}
}
// 开始
requestAnimationFrame(step);
}
// 运行
scheduleHeavyTask();在上面的代码中，batchSize = 50 或者 duration < 2ms，这就是我们的物理阈值。
- 如果阈值设得太小（比如每次只处理 1 个节点），虽然 UI 不会卡顿，但是 CPU 的上下文切换成本会变高，整体执行效率反而下降。
- 如果阈值设得太大（比如每次处理 10000 个节点），主线程就会阻塞，导致页面卡顿。
第五章：React Fiber 的调度器——优先级的艺术
React 的 Fiber 实现比上面的原生 JS 要复杂得多。它不仅仅是为了“不卡顿”，它还引入了优先级的概念。
在 React 18 之前，所有渲染任务都是一样的优先级。但在 React 18 的并发模式下，任务被分为了高优先级（比如用户正在输入、点击按钮）和低优先级（比如后台渲染一个巨大的列表）。
React 18 的 startTransition 机制
这是 React 时间分片最优雅的应用场景。
假设你有一个包含 100,000 条数据的搜索框。当你输入“React”时，你希望立刻看到结果。但是，计算这 100,000 条数据的匹配结果是很慢的。
如果用同步渲染，输入两个字，界面就卡死了。如果用时间分片，React 会把渲染这 100,000 条数据的任务标记为低优先级。
import { startTransition, useState } from 'react';
export default function App() {
const [input, setInput] = useState('');
const [list, setList] = useState([]);
// 普通状态更新，高优先级
const handleChange = (e) => {
setInput(e.target.value);
};
// 长列表更新，低优先级
const handleSearch = (e) => {
// 这里把更新 list 的操作包裹在 startTransition 中
// React 会立即更新 input (高优先级)，让用户感觉不到延迟
// 然后在主线程空闲时，慢慢计算并更新 list (低优先级)
startTransition(() => {
const result = heavySearch(e.target.value);
setList(result);
});
};
return (
<div>
<input value={input} onChange={handleChange} />
<ul>
{list.map(item => <li key={item.id}>{item.name}</li>)}
</ul>
</div>
);
}
// 模拟一个耗时搜索
function heavySearch(query) {
const results = [];
for(let i=0; i<100000; i++) {
if(Math.random() > 0.5) results.push({id: i, name: `${query} - ${i}`});
}
return results;
}在这个例子中，React 的调度器会监控主线程的负载。当你在输入框打字时，handleChange 被立即执行。此时，handleSearch 里的 startTransition 会被放入任务队列的低优先级一侧。
React 不会阻塞当前的输入事件，而是利用时间分片，慢慢去计算数据。如果此时主线程很忙（比如刚打开了一个大图片），React 就会暂停低优先级任务，优先处理输入框的更新。
第六章：深入 requestIdleCallback 与 setTimeout
React 内部是如何利用这些 API 的呢？
requestIdleCallback：懒人的休息时间
requestIdleCallback 是浏览器提供的一个 API，它允许你在主线程空闲的时候执行回调。这听起来很完美，对吧？
但是，requestIdleCallback 有个致命的物理缺陷：它没有时间预算。
它只告诉你“现在没事干”，但不告诉你“你还有多少时间干”。如果你的任务耗时 100ms，虽然你是在空闲时执行的，但这一帧的渲染时间就超了，用户依然会看到卡顿。
所以，React 并没有完全依赖 requestIdleCallback 来做核心渲染，而是结合了 requestAnimationFrame。
requestAnimationFrame：每帧必争
requestAnimationFrame 会在每一帧开始前调用。React 利用这个来检查自己的时间预算。
React 的调度器逻辑大概是这样的（伪代码）：
function workLoop(deadline) {
// 1. 检查是否还有高优先级任务
if (hasHighPriorityWork) {
// 执行高优先级任务
executeWork();
return;
}
// 2. 检查时间预算
// deadline.timeRemaining() 返回当前帧剩余的时间（毫秒）
// 通常在 5ms 到 16ms 之间
while (deadline.timeRemaining() > 0) {
// 3. 执行低优先级任务（时间分片）
if (hasMoreWork) {
executeChunk(); // 每次只跑一小段
} else {
break;
}
}
// 4. 如果还有任务没做完，但时间不够了，就请求下一帧继续
if (hasMoreWork) {
requestIdleCallback(workLoop);
}
}
// 启动调度
requestIdleCallback(workLoop);这里的 deadline.timeRemaining() 就是物理阈值的实时反馈。它告诉 React：“嘿，兄弟，这帧还剩 2ms，赶紧干完这一票赶紧溜，别耽误下一帧的合成。”
第七章：阈值的选择与权衡
在实际开发中，React 团队对阈值的选择是非常精细的。我们作为开发者，也可以从中吸取教训。
1. 执行时间阈值：2ms – 5ms
这是 React 在 Fiber 节点处理上的经验值。如果一次 performUnitOfWork（执行一个 Fiber 节点的工作）耗时超过了 5ms，通常意味着这个组件渲染逻辑写得太烂了（比如在 render 里写了复杂的数学计算、正则匹配、或者大量的 DOM 查询）。
专家建议： 如果你的组件渲染时间经常超过 5ms，说明你的组件太“重”了，需要进行拆分或优化。
2. 帧预算阈值：16ms
这是硬性指标。React 必须保证在 16ms 内完成 JS 计算，把 DOM 留给浏览器去画。
3. 优先级切换阈值
React 在高优先级任务和低优先级任务之间切换时，有一个判断机制。如果你正在处理一个高优先级的点击事件，React 会暂停所有低优先级的渲染任务，直到高优先级任务完成。
这就解释了为什么在 React 18 中，当你正在做一个复杂的动画时，突然点击了一个按钮，那个按钮的反馈是瞬间出现的，而动画可能会被暂停或减速。因为点击事件是最高优先级。
第八章：物理阈值与 React DevTools 的结合
React 官方提供的 Profiler 是一个神器。它能帮你看到你的组件渲染到底花了多少时间。
当你开启 Profiler 并记录操作时，你会发现每个渲染过程都有一个 render 耗时。
- 绿色：耗时很短（< 5ms），完美。
- 黄色：耗时中等（5ms – 15ms），还可以，但要注意。
- 红色：耗时很长（> 16ms），这就是你的“物理阈值”被打破的地方，是导致卡顿的元凶。
通过 Profiler，你可以定位到是哪个组件导致了渲染超时，然后针对性地进行优化。
第九章：总结与反思
说了这么多，React 的时间分片技术本质上是在CPU 时间片和屏幕刷新周期之间玩走钢丝。
它利用了 Fiber 数据结构，将巨大的渲染任务拆解为微小的、可中断的工作单元。它通过 requestAnimationFrame 监控物理帧预算，通过 startTransition 区分任务优先级。
但是，技术只是手段，物理定律不会因为代码写得漂亮就改变。
- 如果你的代码逻辑太重，分片再细也没用，因为总执行时间摆在那里。
- 如果你的阈值设得太低，CPU 的上下文切换开销会抵消掉分片带来的收益。
作为开发者，理解这个“物理阈值”，能让你在写代码时更有敬畏之心。不要在 render 阶段做耗时操作，不要在 useEffect 里搞大数据计算，要善用 useMemo 和 useCallback 来减少不必要的计算。
最后，记住那个 16ms 的数字。它不是代码规范，它是屏幕刷新率的物理回响，是浏览器主线程的怒吼。当你理解了它，你就真正理解了 React 的并发模式，也就理解了现代前端性能优化的核心奥义。
好了，今天的讲座就到这里。希望大家回去后，在写代码时，脑子里都能装着那把“时间切片的手术刀”，把那些卡顿的病灶，切得干干净净。
谢谢大家！