大家好，欢迎来到今天的“前端性能急救室”。
我知道，你们很多人在写代码的时候，都有过这种“至暗时刻”：你点击了一个按钮，界面上的 Loading 圈转得比你的耐心还要慢，鼠标指针在屏幕上卡住不动，仿佛被一只无形的大手按在了暂停键上。你看着那个圈，心里想：“这浏览器是不是死机了？还是我的电脑要爆炸了？”
其实，并没有。这只是你的 React 组件在试图在 16 毫秒内渲染完整个世界，结果把自己累趴下了。
今天我们不聊 CSS 的 flex: 1 怎么写，也不聊 TypeScript 的类型定义怎么绕，我们要聊聊 React 里那个传说中的“时间分片”魔法，以及那个神秘的、像圣杯一样的5毫秒阈值。为什么是 5ms？它是不是对所有人都适用？如果你的电脑是一台老爷机，这个阈值会不会让你在屏幕前枯坐整整一整天？
别急，今天这堂课，我们就来扒开 React 的内裤，看看时间分片到底是怎么在硬件的夹缝中求生存的。
第一部分：16ms 的诅咒与 5ms 的救赎
首先，我们要明白一个残酷的物理定律：屏幕是有刷新率的。
大多数显示器，无论是 60Hz 还是 144Hz，它们的刷新周期都是固定的。60Hz 的屏幕，每秒刷新 60 次，这意味着每一帧的“保质期”只有 1/60 秒，也就是大约 16.6 毫秒。
如果你在浏览器的主线程上做了一件事耗时超过了 16ms，屏幕上就会出现掉帧。如果是 33ms，掉一半帧；如果是 100ms，那就是你在看幻灯片。
React 16 之前的版本是同步渲染的。这意味着什么？意味着如果父组件渲染耗时 100ms，子组件渲染耗时 100ms，父组件渲染完后，子组件渲染，这 200ms 的时间里，用户连点击个关闭按钮的反馈都收不到。用户会以为你把他的电脑给黑了。
为了解决这个问题，React 引入了“时间分片”。
它的核心思想非常简单粗暴：别一次干完，把活儿切碎了干。
想象一下，你是个切洋葱的厨师。如果你试图在一秒钟内把 100 斤洋葱切完，你肯定会切到手，而且洋葱会到处飞。但如果你把洋葱切成薄片，每切完一片就停一下，呼吸一下，洋葱就不会飞，你也不会切到手。
React 就是这样做的。它把一个巨大的渲染任务，拆分成一个个小任务，每个任务只执行一小会儿，比如 5毫秒。
为什么是 5ms？
- 16ms 是一帧的时间。
- 5ms 是 16ms 的 1/3。
- 剩下的 11ms 去哪了？这部分是给浏览器留的“缓冲区”。它要处理合成、处理输入事件、处理垃圾回收（GC）、甚至还要处理你那个还在加载的图片。
所以，5ms 是一个“安全区”。在这个区域内，React 既能完成工作，又能保证浏览器主线程有喘息的机会，让 UI 保持流畅。
第二部分：代码里的“刀工”
光说不练假把式。让我们看看 React 内部是怎么实现这个 5ms 阈值的。
React 团队其实写了一个独立的包，叫 scheduler。这个包的代码写得非常精妙，简直就是瑞士军刀。它不依赖浏览器，而是自己实现了一套调度算法。
我们先不直接用 React 的并发模式，我们自己用原生 JS 模拟一下这个 5ms 的魔法。
// 模拟一个繁重的计算任务
function heavyComputation() {
let sum = 0;
for (let i = 0; i < 10000000; i++) {
sum += i;
}
return sum;
}
// 这是一个典型的 React 时间分片实现
function renderInChunks(task, chunkTime = 5) {
const startTime = performance.now();
while (true) {
// 计算剩余时间
const remainingTime = chunkTime - (performance.now() - startTime);
// 如果时间不够了，或者任务做完了，就停下来
if (remainingTime <= 0 || task.done) {
task.done = true;
break;
}
// 执行一部分任务
task.step();
// 如果任务做完了，直接返回
if (task.done) {
return;
}
}
}
// 定义任务对象
const myTask = {
done: false,
step() {
// 这里只做一点点工作，比如渲染 100 个节点
for (let i = 0; i < 100; i++) {
// 模拟 DOM 操作
document.body.insertAdjacentHTML('beforeend', `<div>Node ${i}</div>`);
}
}
};
// 开始调度
renderInChunks(myTask, 5);
上面的代码很简单，对吧？这就是 React 的精髓。它通过 performance.now() 精确计算时间，一旦发现时间到了 5ms，它就立刻把控制权交还给浏览器，让浏览器去处理用户的点击事件。
如果用户在这个间隙点击了按钮，React 就会把这个点击事件标记为“高优先级”，立刻中断当前正在进行的渲染任务，去处理点击事件。这就是“响应性”。
但是，这里有个巨大的坑：这只是逻辑上的切分，视觉上呢？
第三部分：硬件性能的“鄙视链”
现在我们到了最关键的部分：5ms 这个阈值，对不同硬件来说，真的公平吗？
这就像是用一把手术刀切豆腐，刀很快；但如果这把刀是在 2010 年的奔腾处理器上用，那切豆腐可能比切木头还慢。
1. 高性能设备（MacBook Pro M3, RTX 4090）
对于这些设备，5ms 简直是浪费生命。你的 CPU 主频可能高达 3-4GHz，每秒钟能执行几百亿次指令。5ms 内，你的 CPU 能跑完好几轮任务。
在这种情况下，5ms 的阈值显得过于保守。你可能会想：“既然我有 100ms 的预算，为什么非要等 5ms 才能切下一刀？”
这就像你在高速公路上开车，限速 120，但你在 100km/h 的时候就被强制踩刹车等红灯一样难受。
- 问题： 在高性能设备上，5ms 的阈值会导致“过度调度”。CPU 会在任务之间频繁切换上下文，这种开销反而可能降低性能。
- 体验： 虽然不会卡顿，但你会感觉不到那种“丝般顺滑”的极致感，因为 React 一直在忙着“偷懒”，而不是拼命干活。
2. 低端设备（老旧笔记本, Android 低端机）
对于这些设备，5ms 是救命稻草，但也可能是催命符。
如果你的 CPU 只有 1GHz，内存只有 4GB，那么 5ms 内可能连一个简单的 DOM 更新都处理不完，更别提那些复杂的计算了。
- 问题： 如果任务太重，5ms 根本不够用。React 会发现每次切片后，剩余时间又变回了 5ms，然后继续切下一刀。这就形成了一个死循环，CPU 一直在 5ms 的边缘徘徊，无法完成任何实质性工作。
- 体验： 界面会卡顿，因为 React 一直在抢着干活，导致浏览器主线程始终处于高负载状态，用户依然感觉不到流畅。
3. 中端设备（大多数现代笔记本）
这是 5ms 阈值最适用的场景。这里的 CPU 性能适中，内存带宽也能跟上。
5ms 既能保证浏览器有足够的时间去合成帧，又能让 React 有足够的时间去完成大部分渲染工作。这是一个动态平衡点。
第四部分：实战演练——编写一个“智能”的调度器
既然 5ms 不是万能的，那我们能不能写一个“自适应”的调度器？根据当前硬件的性能，动态调整切片时长？
我们可以通过 navigator.hardwareConcurrency（CPU 核心数）和 performance.memory（内存使用情况）来获取一些硬件信息。
class SmartScheduler {
constructor() {
// 根据核心数估算性能
this.cores = navigator.hardwareConcurrency || 4;
// 假设每个核心每秒能处理 1000 万次简单运算（这是一个经验值）
this.opsPerCorePerSecond = 10000000;
// 默认阈值 5ms
this.defaultThreshold = 5;
}
// 动态计算阈值
calculateThreshold() {
// 如果是高端设备（比如 16 核心或更多），我们适当放宽阈值
if (this.cores >= 16) {
return 10;
}
// 如果是低端设备（比如 2 核心或更少），我们缩小阈值
if (this.cores <= 2) {
return 2;
}
// 中间情况，保持默认 5ms
return this.defaultThreshold;
}
// 执行任务
runTask(task) {
const threshold = this.calculateThreshold();
const startTime = performance.now();
const loop = () => {
const remainingTime = threshold - (performance.now() - startTime);
if (remainingTime <= 0) {
// 时间到了，暂停
requestIdleCallback(loop);
return;
}
// 执行任务
task.step();
if (task.done) {
return;
}
// 如果还有时间，继续跑，不用请求下一帧
// 这就是为什么是“智能”的，不浪费每一微秒
loop();
};
// 开始调度
requestIdleCallback(loop);
}
}
// 使用示例
const smartTask = {
done: false,
step() {
// 模拟繁重操作
console.log("Working...");
}
};
const scheduler = new SmartScheduler();
scheduler.runTask(smartTask);上面的代码展示了如何根据 CPU 核心数动态调整阈值。但这还不够，我们还需要考虑内存。
如果内存压力很大（比如 performance.memory.usedJSHeapSize 很高），我们也应该降低阈值，因为垃圾回收（GC）会随时打断我们的工作。
第五部分：5ms 阈值的“假象”
最后，我要给大家泼一盆冷水。
时间分片并不意味着你的界面一定会变得超级流畅。
为什么？
因为“流畅”是物理现象，是由显卡和显示器决定的。
假设你的显示器是 60Hz 的，你每秒只能刷新 60 次。如果你在 5ms 内完成了渲染，但你还有 11ms 的空闲时间，这 11ms 会被浪费掉。屏幕画面还是那一帧，直到下一帧的到来。
如果你的任务耗时 50ms，无论你怎么切分（5ms 一刀），用户看到的依然是 50ms 的卡顿。时间分片只是让这 50ms 的卡顿变得稍微不那么“僵硬”，让你能在中间响应一些点击，但它无法改变 50ms 这个物理事实。
这就像你跑马拉松，虽然你学会了“时间分片”（跑一会走一会），但如果你身体机能不行，跑 50 米就喘，那你也跑不完 42 公里。
所以，5ms 的阈值只是 React 的“战术动作”，真正的“战略胜利”还需要你做好以下几件事：
- 虚拟化列表： 不要渲染 10,000 个 DOM 节点。只渲染屏幕上能看到的几个。这是减少渲染压力的根本。
- 代码分割： 不要把所有的 React 组件都打包成一个巨大的 JS 文件。按需加载，让浏览器在空闲的时候去下载代码，而不是在渲染的时候去下载。
- 避免在渲染中做数学题： 在
render函数里做JSON.parse(JSON.stringify(data))或者复杂的斐波那契计算，是在自杀。
第六部分：未来的展望
随着硬件的发展，5ms 这个阈值可能会变得越来越不适用。
现在的手机屏幕已经是 120Hz 甚至 144Hz 了。这意味着每一帧的时间缩短到了 8.3ms。如果你还用 5ms 的阈值，你的浏览器主线程会有 3ms 的空闲。这对于现代硬件来说，简直是暴殄天物。
未来，React 可能会引入“基于帧率”的调度。如果你的屏幕是 144Hz，React 会自动把切片时间调整为 3ms；如果你的屏幕是 60Hz，它就保持 5ms。
此外，Web Workers 的普及也会改变游戏规则。我们可以把繁重的计算放在 Web Worker 里，主线程只负责渲染。那时候，时间分片可能就不再那么重要了，因为计算已经不在主线程上了。
结语
好了，今天的讲座就到这里。
我们聊了 React 的时间分片，聊了那个神奇的 5ms 阈值，也聊了不同硬件下的适应性。记住，技术没有银弹，5ms 是 React 团队基于当时的主流硬件和浏览器环境做出的最佳妥协。作为开发者，我们的任务就是理解这些妥协，然后利用它们，为用户提供最好的体验。
下次当你看到界面卡顿的时候，别急着骂浏览器，先看看是不是你的任务太重了，是不是该用虚拟化了，或者是不是该给 React 的调度器加点“智能”了。
代码要写得优雅，电脑要跑得飞快。这是我们的底线，也是我们的信仰。
谢谢大家，下课！