React 时间分片（Time Slicing）：长任务拆分如何通过调度器（Scheduler）避免 UI 阻塞

大家好，欢迎来到今天的讲座。我是你们的老朋友，一个在 React 深渊里摸爬滚打多年的资深工程师。

今天我们要聊的话题，稍微有点“硬核”，但绝对是你理解 React 高性能渲染的敲门砖。这个话题叫——React 时间分片（Time Slicing）。

我知道，听到“时间分片”这四个字，大家脑海里可能已经浮现出一堆枯燥的架构图和架构师们推眼镜的画面。别急，咱们今天不讲那些虚头巴脑的教科书定义，咱们来聊聊“为什么浏览器会卡死”，以及“React 是如何像个老练的间谍一样，在浏览器眼皮子底下偷时间干活的”。

准备好了吗？让我们把浏览器这个“暴躁的老板”先放一边，开始今天的探险。

第一部分：浏览器的心脏——单线程的诅咒

首先，我们要搞清楚一个前提：JavaScript 是单线程的。

这是什么意思？这意味着浏览器里只有一个“大脑”在干活。这个大脑同时只能做一件事。如果它正在做数学题（计算），它就腾不出手来擦桌子（渲染 UI）；如果它正在擦桌子（处理 DOM），它就没法做数学题（计算）。

这听起来很反人类，对吧？毕竟我们现在的电脑都是多核 CPU，为什么 JS 还要这么“抠门”？

因为浏览器需要安全。如果 JS 可以随意更改 DOM，而同时又有其他线程在更改 DOM，那浏览器页面就会乱套，就像一群人同时往一个盒子里扔球，球肯定会炸。

所以，为了安全，浏览器把 JS 放到了主线程上。主线程就像一个只有一张桌子的小面馆。厨师（JS 引擎）只能同时做一道菜。如果客人们点了一桌子菜（复杂的计算任务），厨师就得拼命做。如果这道菜特别难做（长任务），比如需要煮一锅需要 5 秒钟的汤，那在煮汤的这 5 秒钟里，谁点菜？谁上菜？谁结账？服务员（UI 线程）就彻底罢工了。

这时候，用户就会看到什么？页面卡住，滚动条不动，按钮点不下去，甚至有时候连页面都白屏了。这就是所谓的“UI 阻塞”。

第二部分：长任务的“死亡之舞”

为了演示这个现象，我们来看一段代码。假设你在 React 里写了一个按钮，点击之后需要处理 100 万条数据，比如生成一个巨大的数组或者做一个复杂的循环计算。

function handleHeavyClick() {
  console.time('heavy-task');
  // 这是一个典型的长任务
  // 在单线程环境下，这段代码执行期间，UI 是完全冻结的
  for (let i = 0; i < 100000000; i++) {
    // 做一些毫无意义的计算，比如累加
    const dummy = i * i;
    if (dummy > 1000000) break; 
  }
  console.timeEnd('heavy-task');
  alert('计算完成！');
}

当你点击这个按钮，你会看到浏览器在那儿转圈圈（Loading 状态），过了好几秒（取决于你的 CPU 速度），弹窗才出来。在这几秒钟里，用户想取消操作都取消不了，页面就像死了一样。

这就是长任务带来的灾难。在 React 中，这种长任务不仅会阻塞主线程，还会阻塞 React 的渲染循环。React 试图更新 DOM，但主线程忙着算数呢，React 只能干等。

第三部分：时间分片——把大象装进冰箱

那么，怎么解决这个问题呢？我们不能把浏览器变成多线程的（至少目前不行），那我们只能改变“做菜”的方式。

这就引出了时间分片的核心思想：不要一次性把活干完，要把活拆开，中间穿插着做。

想象一下，你要吃一个巨大的汉堡（长任务）。

• 传统方式：你把整个汉堡一口吞下去，噎死你，你也没法呼吸，也没法说话。
• 时间分片方式：你一口咬一口汉堡，吃完一口，喘口气，喝口水，然后再吃一口。

在计算机世界里，这个“一口”通常被定义为 16ms（60fps 的刷新率）或者更短。如果你在 16ms 的时间里能做完一点活，就停下来，把控制权交还给浏览器，让浏览器去渲染 UI、处理用户点击、或者仅仅是让 CPU 休息一下。

React 的时间分片，就是为了让 JavaScript 看起来像是“多线程”的。它通过极其微小的切分，让浏览器觉得主线程一直很忙，但实际上它一直在“偷懒”去处理 UI，然后又回来继续干活。

第四部分：浏览器给的“空闲钩子”——requestIdleCallback

早在 React 官方大规模使用这个技术之前，浏览器其实早就意识到这个问题了。于是，HTML5 提供了一个 API 叫 requestIdleCallback。

它的作用很简单：“当浏览器主线程空闲的时候，回调我一下。”

比如，你可以这样写：

function workLoop(deadline) {
  // 如果还有时间，继续干活
  while (deadline.timeRemaining() > 0) {
    doSomeWork();
  }
  // 如果没时间了，告诉浏览器我下次什么时候再来
  requestIdleCallback(workLoop);
}

requestIdleCallback(workLoop);

deadline.timeRemaining() 这个方法非常关键，它返回的是当前帧剩余的时间（通常是 50ms 左右）。

理论上，这很完美。如果浏览器有空闲时间，我们就处理数据；如果没空闲时间，我们就等待。这就像是一个聪明的管家，在主人看电视的时候，悄悄地帮你把地拖了。

但是！ requestIdleCallback 有一个致命的缺陷，导致它不适合做 React 的核心渲染调度。

1. 优先级问题：requestIdleCallback 是给“空闲任务”用的。比如页面加载完后的数据统计、广告追踪。但是，如果用户正在疯狂点击按钮呢？这时候主线程一点都不空闲，requestIdleCallback 根本不会执行。用户点击了按钮，结果因为我们在等空闲时间，导致按钮响应慢了 500 毫秒。这体验太差了。
2. 浏览器兼容性：虽然现在大部分现代浏览器都支持了，但 IE 和一些老古董浏览器根本不支持。
3. 时序不可控：requestIdleCallback 什么时候回调，浏览器说了算。它可能两秒钟后回调一次，也可能十分钟后回调一次。对于 React 这种需要精确控制渲染节奏的框架来说，这种不确定性是致命的。

第五部分：React 的秘密武器——调度器

所以，React 团队决定不依赖浏览器的这个“懒散”的 API，而是自己造了一个轮子，这就是 React 内部大名鼎鼎的 Scheduler（调度器）。

React 的 Scheduler 比浏览器自带的空闲 API 强在哪里？它更像是一个军事化的调度员。

它有两个核心任务：

1. 高优先级任务（比如用户点击按钮、输入框打字）：不管主线程多忙，必须马上插队执行。
2. 低优先级任务（比如页面初次渲染、数据统计）：如果主线程忙，就让它等一等，等有空了再慢慢做。

Scheduler 的底层逻辑：RAF + Timeout 的混合双打

React 的 Scheduler 是如何实现精确调度的呢？它没有完全依赖 requestIdleCallback，也没有完全依赖 setTimeout。它是一个混合体，利用了两个浏览器的原生 API：

1. requestAnimationFrame (RAF)：

   • 这玩意儿非常有意思。它的触发时间非常精确，通常在屏幕刷新的前一帧开始时触发（约 16ms 一帧）。
   • 如果我们把任务放在 RAF 里，它通常能保证在屏幕刷新前完成。
   • 但是，如果任务很重，RAF 会阻塞下一帧的渲染。所以 Scheduler 会用 RAF 来判断当前帧有没有空余时间。

2. setTimeout (Task)：

   • 这是浏览器用来处理“宏任务”的机制。它的精度最低（通常 4ms 或 10ms），但它有一个优点：它总是会被插入到主线程的任务队列中，优先级高于 requestIdleCallback。

Scheduler 的调度逻辑是这样的（伪代码版）：

function scheduleCallback(priorityLevel, callback) {
  // 1. 如果当前帧还有时间（通过 requestAnimationFrame 获取），或者优先级很高
  //    我们尝试立即执行
  const currentTime = getCurrentTime();
  const expirationTime = currentTime + getExpirationTime(priorityLevel);

  if (shouldYieldToHost() || currentTime >= expirationTime) {
    // 2. 如果时间不够了，或者优先级太高，那就交给 setTimeout
    //    setTimeout 会把任务放入宏任务队列，保证在下一个事件循环执行
    return setTimeoutCallback(callback, expirationTime - currentTime);
  } else {
    // 3. 如果时间充裕，直接注册 RAF，争取在当前帧完成
    return requestAnimationFrameCallback(callback, expirationTime);
  }
}

• 场景 A（高优先级）：用户点击了按钮。React 需要立即更新状态。Scheduler 会发现当前帧没时间了，直接调用 setTimeout，把任务扔进下一个事件循环的队尾。用户立刻就能感觉到响应。
• 场景 B（低优先级）：React 正在渲染一万个组件。Scheduler 发现当前帧还剩 5ms。它不会让 React 做完这 5ms，而是告诉 React：“嘿，兄弟，做完这 5ms 就停手，把控制权还给浏览器。” React 就会停下来，浏览器趁机渲染 UI。等浏览器空闲了，下一帧 RAF 来了，React 再继续做剩下的任务。

这就是时间分片的精髓：主动让步，而不是被动等待。

第六部分：Fiber 架构——时间分片的物理载体

光有 Scheduler 还不够，Scheduler 只是一个大脑，它需要身体来执行。这个身体，就是 Fiber 架构。

在 React 15 之前，React 的渲染是一个巨大的同步函数。就像你把整个文件一次性读进内存，读不完就不停。如果文件有 10GB，你的程序就卡死了。

React 16 引入了 Fiber，它把“渲染树”变成了一棵“链表”。

每个 Fiber 节点，都记录了自己的状态：

• return: 父节点
• child: 第一个子节点
• sibling: 下一个兄弟节点

更重要的是，Fiber 节点在遍历过程中，会记录“工作预算”（Work Budget）。比如，当前帧只有 5ms，那 Scheduler 就会告诉 Fiber：“你只有 5ms 的预算，把这 5ms 用完，然后停下来。”

// Fiber 节点的简化结构
class FiberNode {
  constructor(type) {
    this.type = type; // 组件类型
    this.props = {};  // 属性
    this.stateNode = null; // 对应的 DOM 节点

    // 关键的链表指针
    this.return = null; // 父节点
    this.child = null;  // 第一个子节点
    this.sibling = null; // 下一个兄弟节点

    // 状态
    this.alternate = null; // 旧 Fiber
    this.pendingProps = null;
    this.effectTag = null;
  }
}

当 Scheduler 唤醒 React 进行渲染时，React 会遍历这个链表：

1. 处理当前节点。
2. 检查是否超时（deadline.timeRemaining() < 0）。
3. 如果超时，把当前节点挂起来，把 return 指针交给 Scheduler，保存当前状态。
4. 等下一帧 RAF 再次唤醒时，从上次挂起的地方继续往下遍历。

这就好比你在读一本厚书。以前你是读一页翻一页，读不完就不翻。现在 Fiber 架构让你读一行翻一页，读完一行，看看时间，没时间了就合上书，明天再读。这样你就可以一边读书一边去倒杯水，书也不会丢。

第七部分：实战演练——手写一个时间分片

为了让大家更直观地理解，我们抛开 React，用原生 JS 写一个简单的“时间分片”工具。

假设我们要处理 100 万条数据，直接处理会卡死页面。

// 这是一个非常简化的调度器模拟
let isWorking = false;

function chunkedWork(callback, chunkSize = 1000) {
  if (isWorking) return; // 防止重复调用

  isWorking = true;
  let index = 0;
  const total = 1000000; // 假设有 100 万条数据

  function work() {
    // 1. 计算这一帧还能做多少
    const remaining = chunkSize; 

    // 2. 循环执行任务
    while (index < total && remaining > 0) {
      // 执行你的业务逻辑
      processData(index);
      index++;
      remaining--;
    }

    // 3. 判断是否完成
    if (index < total) {
      // 还没做完，把控制权交还给浏览器
      // 使用 requestAnimationFrame，在下一帧继续
      requestAnimationFrame(work);
    } else {
      // 完成了
      isWorking = false;
      console.log('所有任务完成！');
    }
  }

  // 开始第一帧
  requestAnimationFrame(work);
}

function processData(i) {
  // 模拟耗时操作
  const dummy = Math.sqrt(i) * i; 
}

// 触发
chunkedWork();

在这个例子中：

1. 我们使用了 requestAnimationFrame。因为 RAF 是基于屏幕刷新率的，它保证了我们在屏幕还没刷新之前，尽可能多地把 CPU 占用完，然后停下来让浏览器渲染那一帧的画面。
2. 我们设置了 chunkSize（分片大小）。如果这个值设为 100 万，那页面还是会卡死。如果设为 1000，页面就能保持流畅，因为每做 1000 次计算，我们就让出控制权 16ms。

这就是时间分片在原生 JS 中的实现逻辑。React 内部的 Scheduler 复杂得多，它会根据任务的优先级动态调整这个 chunkSize，但原理是一样的： 微步执行，主动让渡。

第八部分：深入 Scheduler 的优先级队列

光会分片还不够，还得会排队。如果来了一个高优先级的任务（比如用户点击了“提交”），而此时 React 正在慢悠悠地渲染一个低优先级的列表，那怎么办？

这就涉及到了 React 的优先级队列。

在 React 内部，每个任务都有一个优先级数字。数字越大，优先级越高。

1. 调度器维护了一个任务队列。
2. 当一个新的任务进来（比如用户点击），它会被赋予高优先级。
3. Scheduler 会检查当前正在运行的任务。
   • 如果当前任务优先级比新任务低，立即中断当前任务，把控制权交给新任务。
   • 如果当前任务优先级比新任务高，继续执行当前任务。

这就像你在写代码（低优先级），突然老板让你去开会（高优先级）。你会立刻合上电脑，去开会。这就是中断机制。

在 React 18 中，这个机制更加激进，被称为 Concurrent Mode（并发模式）。它允许 React 在渲染的同时响应用户的输入，甚至在渲染过程中取消某些渲染，回退到旧状态。

第九部分：为什么这很重要？

理解时间分片不仅仅是为了炫技，它直接关系到用户体验。

想象一下，你在一个电商 App 上浏览商品列表。列表里有 1000 个商品，每个商品都需要渲染一张图片和一段文字。

• 没有时间分片：页面加载时，你盯着白屏看了 2 秒，心里想“这破网速”，然后页面突然跳出来，图片可能还没加载完，闪烁一下。
• 有时间分片：页面是逐步渲染出来的。你先看到第一个商品，然后第二个，第三个……每当你看到新的内容，你的大脑就会产生“页面正在加载”的反馈。虽然总时间可能也是 2 秒，但你的感知体验完全不同。你不会觉得卡，你会觉得“它在努力工作”。

这就是时间分片带来的 “感知性能” 的提升。

第十部分：代码中的体现

在 React 18 的代码中，你会经常看到 useTransition 这个 Hook。它的底层逻辑就是利用 Scheduler 的优先级机制。

import { startTransition } from 'react';

function App() {
  const [input, setInput] = useState('');
  const [list, setList] = useState([]);

  function handleChange(e) {
    const value = e.target.value;

    // 1. 更新 input 是高优先级任务
    setInput(value);

    // 2. 更新 list 是低优先级任务
    // startTransition 告诉 React："这个计算比较重，你可以慢慢来，别阻塞 input"
    startTransition(() => {
      setList(filterList(value)); // 假设这是一个耗时操作
    });
  }

  return (
    <>
      <input value={input} onChange={handleChange} />
      <ul>
        {list.map(item => <li key={item}>{item}</li>)}
      </ul>
    </>
  );
}

在这个例子中，setInput 是高优先级，setList 是低优先级。Scheduler 会确保 input 的值能立刻更新到屏幕上，让你能输入。而 setList 的计算会分片进行，如果此时你又在输入，React 会暂停 setList，优先处理你的输入。

第十一部分：总结——当调度成为艺术

好了，我们讲了这么多。

React 的时间分片，本质上是一种“分而治之”的策略。它利用 Fiber 架构将庞大的渲染任务拆解成无数个微小的片段，利用 Scheduler 调度器在每一帧的间隙中穿插执行。

它打破了 JS 单线程的枷锁，让“计算”与“渲染”在时间维度上实现了某种程度的并行。它让 React 从一个“同步执行”的框架，进化成了一个“智能调度”的框架。

这不仅仅是技术上的优化，更是一种工程哲学。它告诉我们：不要试图一口吃成个胖子，也不要试图在一秒钟内做完一整年的事。把时间切碎，把节奏放缓，把体验做好。

下次当你看到 React 页面在处理大量数据时依然丝般顺滑，当你点击按钮时没有任何延迟，别忘了那个躲在幕后默默工作的 Scheduler。它就像一个不知疲倦的钟表匠，用时间分片这把精细的刻刀，雕刻出流畅的交互体验。

这就是时间分片，这就是 React 的魔法。

（讲座结束，谢谢大家！）