React源码中的调度器做了什么？从任务切片理解性能优化核心逻辑

各位前端工程师、架构师以及对高性能UI感兴趣的朋友们，大家好！

今天，我们将深入探讨React源码中一个至关重要的组成部分——调度器（Scheduler）。它不仅仅是React并发模式的基石，更是理解React如何实现卓越性能和流畅用户体验的关键。我们将从宏观的性能挑战出发，逐步剖析调度器的工作原理，特别是其核心的“任务切片”逻辑，并通过代码和详细解释来揭示其奥秘。

一、前端性能的顽疾：主线程阻塞与UI卡顿

在前端领域，性能优化始终是一个永恒的话题。我们追求更快的加载速度、更流畅的动画、更即时的用户反馈。然而，JavaScript的本质特性，即它运行在浏览器的主线程上，给我们带来了固有的挑战。

想象一下，你的浏览器主线程就像一条繁忙的单行道。所有的JavaScript执行、样式计算、布局、绘制以及事件处理都必须在这条路上排队通行。当一个耗时较长的任务，比如一个复杂的数据处理、一个大规模的DOM操作，或者一个React组件树的深度更新，占据了主线程过长时间，这条单行道就会被“堵死”。

其结果是什么？

• UI卡顿（Jank）：用户在滚动页面、点击按钮、输入文本时，界面没有即时响应，出现明显的延迟甚至冻结。
• 交互迟滞：动画不再流畅，从60fps（每秒60帧，每帧约16.6ms）跌落，用户感知到明显的掉帧。
• 糟糕的用户体验：最终导致用户感到沮丧，甚至放弃使用你的应用。

传统的解决方案，例如将耗时操作放到Web Workers中（用于纯计算），或者使用setTimeout(fn, 0)来将任务推迟到下一个事件循环周期，都有其局限性。Web Workers无法直接操作DOM，而setTimeout(0)虽然能避免同步阻塞，但它缺乏优先级管理，且在任务繁重时，仍然可能导致连续的短任务累积，最终形成“微阻塞”。

React，作为一个旨在构建复杂用户界面的库，深知这一痛点。传统的React（16版本之前）在进行组件更新时，其协调（Reconciliation）过程是同步且不可中断的。一旦开始，它会一口气处理完整个组件树的对比和计算，直到生成最终的DOM差异。对于小型应用尚可接受，但对于大型、高交互性的应用，这无疑是性能的巨大瓶颈。

为了突破这一瓶颈，React团队彻底重构了其核心架构，引入了Fiber，并在此基础上构建了调度器（Scheduler）。调度器的核心使命就是将原本同步、不可中断的更新工作，分解成可中断、可切片的任务，并根据优先级进行调度，从而在保证响应性的前提下，最大化吞吐量。

二、从Stack Reconciler到Fiber：可中断的基石

在深入调度器之前，我们必须先理解React渲染机制的演进，特别是从Stack Reconciler到Fiber架构的转变。这是调度器能够发挥作用的先决条件。

2.1 Stack Reconciler：同步与递归的困境

在React 16之前，React的协调算法被称为Stack Reconciler。它的工作方式非常直观，类似于函数调用栈的执行：

1. 当一个组件需要更新时，React会从根组件开始，递归地遍历整个组件树。
2. 对于每个组件，它会调用其render方法，获取新的JSX描述。
3. 然后，它会将新的JSX与上一次的JSX进行比较，找出需要更新的部分。
4. 这个过程是深度优先的，一旦进入一个子树，就会一直处理到叶子节点，然后回溯。

缺点显而易见： 整个协调过程是一个同步、递归的函数调用。这意味着一旦render函数开始执行，它就会一直运行下去，直到整个组件树的所有差异计算完成。在此期间，JavaScript主线程被完全占用，浏览器无法执行任何布局、绘制任务，也无法响应用户输入。这就像一个长时间运行的函数，它霸占了CPU，导致UI完全冻结。

// 伪代码：Stack Reconciler的同步递归性质
function reconcile(oldElement, newElement) {
    // ... 对比逻辑 ...
    if (newElement.type === Component) {
        const instance = new newElement.type(newElement.props);
        const childElement = instance.render();
        // 递归处理子组件
        reconcile(oldElement.children, childElement); 
    } else if (newElement.type === HostComponent) {
        // ... 处理原生DOM元素 ...
        newElement.children.forEach((child, index) => {
            reconcile(oldElement.children[index], child);
        });
    }
    // ... 应用DOM更新 ...
}

// 模拟一次大型更新
function largeUpdate() {
    // 假设这里触发了一个会导致非常深层组件树更新的setState
    // 整个reconcile过程会同步完成，期间UI会卡顿
    root.render(<App largeData={...} />); 
}

// main thread calls largeUpdate()
// UI blocks until largeUpdate finishes

2.2 Fiber Reconciler：任务切片与链表结构

为了解决Stack Reconciler的同步阻塞问题，React 16引入了全新的Fiber架构。Fiber是对协调算法的彻底重写，其核心思想是将一个大的、不可中断的递归工作，拆解成一系列小的、可中断的“工作单元”（work units）。

什么是Fiber？

在React中，一个Fiber就是一个普通的JavaScript对象，它代表了一个组件实例、一个原生DOM元素、一个文本节点等等。它包含了关于这个组件或元素的所有信息：

• 类型（type）：组件类型（函数组件、类组件）或DOM标签（div, span）。
• 属性（props）：组件当前的属性。
• 状态（memoizedState）：组件当前的状态。
• 父节点（return）：指向其父Fiber。
• 子节点（child）：指向其第一个子Fiber。
• 兄弟节点（sibling）：指向其下一个兄弟Fiber。
• 替身（alternate）：指向对应在“上次渲染”中的Fiber。React会维护两棵Fiber树，一棵是当前屏幕上渲染的，另一棵是在后台构建的“工作中的”树。
• 效果标签（flags）：标记这个Fiber需要执行的副作用（如DOM插入、更新、删除等）。

通过这种链表结构（child、sibling、return），Fiber树可以方便地遍历，而且最关键的是，它使得遍历过程可以被中断和恢复。每个Fiber节点都代表了一个可以独立处理的“工作单元”。

Fiber的两阶段工作模式：

Fiber架构将协调过程分成了两个主要阶段：

1. 渲染/协调阶段（Render/Reconciliation Phase）：

   • 这个阶段是可中断的。
   • React会遍历Fiber树，为每个Fiber节点执行“工作单元”——主要是调用组件的render方法、对比新旧Props和State、构建新的子Fiber树等。
   • 这个阶段不会执行任何实际的DOM操作。相反，它会收集所有需要进行的DOM变更（副作用），并将它们标记在Fiber节点的flags属性上。
   • 当时间片用尽，或者有更高优先级的任务到来时，React可以暂停当前的工作，将控制权交还给浏览器。
   • 一旦浏览器空闲，或者更高优先级的任务处理完毕，React可以从上次中断的地方继续工作。

2. 提交阶段（Commit Phase）：

   • 这个阶段是不可中断的，必须同步完成。
   • 一旦渲染阶段完成，所有的“工作单元”都被处理完毕，并且构建了一棵包含了所有变更的Fiber树（被称为“工作中的Fiber树”）。
   • 提交阶段会遍历这棵工作中的Fiber树，根据Fiber节点上的flags，一次性地将所有DOM变更应用到实际的浏览器DOM上。
   • 这个阶段还包括执行生命周期方法（如componentDidMount、componentDidUpdate）和useLayoutEffect等副作用。

为什么Fiber是可中断的基石？

Stack Reconciler是基于调用栈的，一旦函数被调用，就必须等待它返回。而Fiber Reconciler是基于链表遍历的。React可以在处理完一个Fiber节点后，检查当前帧剩余时间是否充足。如果不足，它就可以暂停，记录下当前处理到的Fiber节点，然后将控制权交还给浏览器。等到下一次有机会执行时，它会从上次记录的Fiber节点继续处理，而不是从头开始。

正是这种可中断性，为React调度器提供了操作空间。

三、React调度器：优先级、时间切片与协作式多任务

现在，我们有了Fiber这个能够被中断和恢复的“工作单元”载体，那么谁来决定何时中断、何时恢复、以及优先处理哪个任务呢？这就是React调度器（Scheduler）的职责。

3.1 调度器的核心职责

React调度器是一个独立的包，位于react-scheduler。它的核心职责可以概括为以下几点：

1. 任务管理：接收来自React核心层（如setState、ReactDOM.render）的更新请求，将它们封装成“任务”（Callbacks）。
2. 优先级排序：根据任务的紧急程度赋予不同的优先级，确保高优先级的任务能够尽快执行。
3. 时间切片（Time Slicing）：在执行任务时，周期性地检查当前帧的剩余时间。如果时间不足，则暂停当前任务，将控制权交还给浏览器。
4. 任务恢复：在浏览器空闲时，恢复被暂停的任务，或执行下一个待处理的任务。
5. 跨平台抽象：提供一套与宿主环境（浏览器、Node.js、React Native）无关的调度机制。

3.2 浏览器事件循环与调度器的交互

理解调度器，首先要回顾一下浏览器事件循环（Event Loop）。

浏览器的主线程在大部分时间都是空闲的，等待事件发生。当事件发生时（如用户输入、网络响应、定时器触发），它会将对应的回调函数放入任务队列。事件循环会不断地从任务队列中取出任务并执行。

重要的概念：

• 宏任务（Macrotasks）：setTimeout, setInterval, setImmediate (Node.js), requestAnimationFrame, I/O, UI Rendering。
• 微任务（Microtasks）：Promise.then(), MutationObserver, queueMicrotask。

一个事件循环迭代通常包括：

1. 执行当前宏任务。
2. 执行所有微任务。
3. 执行浏览器渲染（如果需要）。
4. 进入下一个宏任务。

调度器如何利用事件循环？

React调度器最初尝试利用requestIdleCallback。requestIdleCallback允许开发者在浏览器主线程空闲时执行任务。这听起来非常完美：它允许我们执行低优先级的任务，而不会阻塞用户交互。

然而，requestIdleCallback有几个缺点：

• 不确定性：它的触发频率和时机非常不稳定，取决于浏览器何时“空闲”。在繁忙的页面中，可能长时间不触发。
• 帧率低：它可能在帧的末尾才触发，导致无法在下一帧及时执行任务。
• 兼容性问题：并非所有浏览器都支持。

为了获得更精确、更可控的调度能力，React调度器现在主要采用MessageChannel来模拟requestIdleCallback的行为。

MessageChannel的妙用：

MessageChannel允许我们创建一对端口，通过port1.postMessage(data)发送消息，并通过port2.onmessage接收消息。当port1.postMessage被调用时，它会创建一个新的宏任务，并将其推入任务队列。

这意味着什么？

当React调度器需要执行下一个任务时，它会通过MessageChannel发送一条消息。这条消息的回调会在当前任务执行完毕、所有微任务执行完毕、并且浏览器有机会进行渲染之后，作为下一个宏任务被执行。

// 简化版的requestHostCallback实现（类似React Scheduler）
let scheduledHostCallback = null;
let is  MessageLoopRunning = false;
let port1 = null;
let port2 = null;

if (typeof MessageChannel !== 'undefined') {
    const channel = new MessageChannel();
    port1 = channel.port1;
    port2 = channel.port2;
    port2.onmessage = () => {
        if (scheduledHostCallback !== null) {
            const callback = scheduledHostCallback;
            scheduledHostCallback = null;
            isMessageLoopRunning = false;
            callback(); // 执行调度器的主要工作循环
        }
    };
}

function requestHostCallback(callback) {
    scheduledHostCallback = callback;
    if (!isMessageLoopRunning) {
        isMessageLoopRunning = true;
        port1.postMessage(null); // 触发下一个宏任务
    }
}

// 当调度器有任务要处理时，它会调用
// requestHostCallback(flushWork);
// flushWork就是调度器执行任务的主循环

通过MessageChannel，React调度器能够在每个宏任务之间获得一个执行机会，从而实现比setTimeout(0)更可靠、更频繁的“让步”机制。

3.3 任务优先级管理

并非所有的更新都同等重要。用户输入（如文本框输入）需要立即响应，而后台数据加载或非关键的动画更新则可以稍后处理。React调度器定义了一系列的优先级：

优先级名称	数值（越小优先级越高）	描述
ImmediatePriority	1	立即执行，同步阻塞。用于flushSync等需要立即完成的更新。
UserBlockingPriority	2	用户阻塞优先级。用于用户交互事件，如点击、输入。必须在短时间内响应。
NormalPriority	3	普通优先级。大多数setState更新默认采用此优先级。可被中断。
LowPriority	4	低优先级。可以在不阻塞用户体验的情况下执行。
IdlePriority	5	空闲优先级。在浏览器空闲时执行，如预加载、不重要的后台任务。

优先级与过期时间（Expiration Time）：

调度器不仅仅依赖于优先级数值，它还会为每个任务计算一个“过期时间”（expirationTime）。这个过期时间是当前时间加上一个基于优先级的延迟时间。

• 高优先级任务：延迟时间短，过期时间早。
• 低优先级任务：延迟时间长，过期时间晚。

例如：
UserBlockingPriority可能只有几十毫秒的延迟。
NormalPriority可能有几百毫秒的延迟。
LowPriority和IdlePriority可能延迟数秒甚至更久。

调度器会维护一个最小堆（Min-Heap）结构的任务队列，以expirationTime为主要排序依据，priority为次要排序依据。堆顶的任务总是那个最快过期（或优先级最高）的任务。

// 简化后的任务结构
class CallbackNode {
    constructor(callback, priority, startTime, expirationTime, id) {
        this.callback = callback; // 实际要执行的React工作单元
        this.priority = priority;
        this.startTime = startTime; // 任务被调度的时间
        this.expirationTime = expirationTime; // 任务的过期时间
        this.id = id; // 唯一标识符
        this.sortIndex = expirationTime; // 用于堆排序的索引
        // ... 其他内部状态，如是否已取消
    }
}

// 调度任务的简化流程
function scheduleCallback(priority, callback, options) {
    const currentTime = performance.now();
    let timeout;
    switch (priority) {
        case ImmediatePriority: timeout = -1; break; // 立即执行
        case UserBlockingPriority: timeout = 250; break;
        case NormalPriority: timeout = 5000; break;
        case LowPriority: timeout = 10000; break;
        case IdlePriority: timeout = 25000; break;
    }
    const expirationTime = currentTime + timeout;
    const newTask = new CallbackNode(callback, priority, currentTime, expirationTime, nextTaskId++);

    // 将newTask添加到全局的优先级队列（最小堆）中
    // 队列中的任务按expirationTime升序排列
    taskQueue.push(newTask);
    heapify(taskQueue); // 维护堆结构

    // 确保调度器的工作循环被触发
    requestHostCallback(flushWork); 

    return newTask; // 返回任务引用以便后续取消
}

flushWork是调度器的主工作循环，它会不断从任务队列中取出最高优先级的任务并执行。

3.4 任务切片（Time Slicing）的核心逻辑

这是我们今天讲座的重头戏。任务切片是调度器实现“协作式多任务”的关键。它的核心思想是：在执行一个任务时，不一口气执行到底，而是执行一小段时间，然后主动检查是否需要暂停，将控制权交还给浏览器。

这个检查和让步的过程发生在workLoop或flushWork函数中。

1. 帧预算（Frame Budget）：浏览器通常以60fps的速率渲染，这意味着每帧有大约16.6ms的时间。React调度器会预留一部分时间给自身处理更新，通常会设置一个时间片（Time Slice），例如5ms。也就是说，调度器在一个宏任务中，最多连续执行5ms的工作。
2. shouldYield()判断：在执行每个Fiber的工作单元之后，或者在处理一批任务之后，调度器会调用一个shouldYield()函数来判断是否应该暂停。
   shouldYield()的内部逻辑通常是这样的：
   • 检查自当前宏任务开始以来已经过去了多少时间。
   • 如果流逝的时间超过了预设的时间片（比如5ms），那么shouldYield()返回true。
   • 如果有更高优先级的任务正在等待，即使时间片未用尽，也可能返回true，以便优先处理更紧急的任务。
   • 在ImmediatePriority任务中，shouldYield()总是返回false，因为它必须立即完成。

// 简化版的调度器工作循环伪代码
let currentHostTimeoutID = -1;
let currentHostCallbackNode = null;
let isPerformingWork = false;

// 这个函数就是由requestHostCallback触发的
function flushWork() {
    isPerformingWork = true;
    try {
        // 获取当前时间戳，用于计算时间片
        const initialTime = performance.now(); 
        // 假设我们有一个全局的workInProgressRoot，表示当前正在处理的Fiber根节点
        // nextUnitOfWork是下一个要处理的Fiber节点

        // 循环处理任务队列中的任务
        while (currentHostCallbackNode !== null && !shouldYield()) {
            const callback = currentHostCallbackNode.callback;
            currentHostCallbackNode.callback = null; // 清空回调，防止重复执行

            // 执行实际的React工作单元（例如performUnitOfWork），它会返回下一个要处理的Fiber
            const continuationCallback = callback(); 

            if (continuationCallback === null) {
                // 当前任务已完成，从队列中移除并处理下一个
                currentHostCallbackNode = peek(taskQueue); // 获取下一个最高优先级任务
                if (currentHostCallbackNode !== null) {
                    // 如果还有任务，重新调度
                    requestHostCallback(flushWork); 
                }
            } else {
                // 任务未完成（被中断），将剩余部分重新放回队列，并更新回调
                currentHostCallbackNode.callback = continuationCallback;
            }
        }
    } finally {
        isPerformingWork = false;
        // 如果还有未完成的任务，但我们已经yield了，那么需要再次调度
        if (currentHostCallbackNode !== null) {
            requestHostCallback(flushWork);
        }
    }
}

// 调度器内部的shouldYield判断逻辑（简化）
const frameInterval = 5; // 比如5ms的时间片预算
let startTime = -1; // 当前宏任务的开始时间

function schedulePerformWorkUntilDeadline() {
    startTime = performance.now();
    // 触发MessageChannel，让flushWork在下一个宏任务中执行
    requestHostCallback(flushWork); 
}

function shouldYield() {
    const currentTime = performance.now();
    // 检查是否已经超过了当前帧的时间预算
    // 真实的React Scheduler还会检查是否有更紧急的任务在等待
    return currentTime - startTime >= frameInterval; 
}

任务切片的工作流：

1. 开始一个任务：调度器从优先级队列中取出最高优先级的任务（比如一个React更新的根Fiber）。
2. 执行一小段工作：React核心层（Fiber Reconciler）开始处理这个任务，它会遍历Fiber树，处理一个或几个Fiber节点。
3. 检查时间片：在处理完一个Fiber节点后，或者经过一段预设的时间（比如5ms）后，调度器调用shouldYield()。
4. 暂停或继续：
   • 如果shouldYield()返回false（时间片未用尽，且没有更高优先级的任务），则继续处理下一个Fiber节点。
   • 如果shouldYield()返回true（时间片用尽，或者有更高优先级的任务），则暂停当前任务。React会记录下当前处理到的Fiber节点，并将控制权交还给浏览器。
5. 浏览器执行渲染和事件：浏览器获得控制权后，可以响应用户输入、执行动画、进行布局和绘制。
6. 恢复任务：在浏览器空闲时（通过MessageChannel触发的下一个宏任务），调度器再次被激活。它会从上次暂停的地方继续执行被中断的任务。

这个过程不断重复，将一个大型的、可能阻塞UI的更新任务，分解成无数个小的、可管理的“切片”，并巧妙地穿插在浏览器的每一帧中执行。

3.5 并发模式（Concurrent Mode）的实现基石

任务切片和优先级调度是React并发模式（Concurrent Mode）的核心。并发模式允许React同时处理多个更新，即使这些更新是针对同一个组件树的。

例如：

• 用户在搜索框中输入文字（高优先级）。
• 同时，后台正在加载搜索结果并更新列表（普通优先级）。

在非并发模式下，如果搜索结果的更新先触发，它可能会阻塞用户的输入响应。而在并发模式下：

1. 用户输入事件触发一个UserBlockingPriority的更新。
2. 调度器会暂停正在进行的（普通优先级）搜索结果更新。
3. 立即处理用户输入相关的更新，使输入框快速响应。
4. 一旦用户输入处理完毕，调度器会恢复之前被暂停的搜索结果更新，从上次中断的地方继续。

这就是“协作式多任务”的精髓：不同的任务互相协作，通过让步和恢复，共同在主线程上运行，而不是互相阻塞。

四、代码示例：简化调度器机制

为了更好地理解上述概念，我们来构建一个高度简化的调度器模型。请注意，这只是一个教学示例，React的实际调度器代码要复杂得多，涉及更多边缘情况和优化。

// ====================================================================
// 简化版React Scheduler
// 目的：演示优先级队列、时间切片和requestHostCallback的协作
// ====================================================================

// 1. 优先级定义
const ImmediatePriority = 1;
const UserBlockingPriority = 2;
const NormalPriority = 3;
const LowPriority = 4;
const IdlePriority = 5;

// 2. 任务结构
let nextTaskId = 0;
class CallbackNode {
    constructor(callback, priority, startTime, expirationTime, id) {
        this.callback = callback; // 实际要执行的函数
        this.priority = priority;
        this.startTime = startTime;
        this.expirationTime = expirationTime;
        this.id = id;
        this.sortIndex = expirationTime; // 用于堆排序，过期时间越早，优先级越高
        this.is
        _cancelled = false;
    }
}

// 3. 优先级队列 (最小堆实现)
// 简化堆操作，实际React使用更优化的堆实现
const taskQueue = []; // 存储CallbackNode

function push(heap, node) {
    heap.push(node);
    siftUp(heap, node, heap.length - 1);
}

function peek(heap) {
    return heap.length === 0 ? null : heap[0];
}

function pop(heap) {
    if (heap.length === 0) return null;
    const first = heap[0];
    const last = heap.pop();
    if (first !== last) {
        heap[0] = last;
        siftDown(heap, last, 0);
    }
    return first;
}

function siftUp(heap, node, i) {
    let parentIndex;
    while (i > 0 && (parentIndex = (i - 1) >>> 1, node.sortIndex < heap[parentIndex].sortIndex)) {
        heap[i] = heap[parentIndex];
        i = parentIndex;
    }
    heap[i] = node;
}

function siftDown(heap, node, i) {
    let len = heap.length;
    let half = len >>> 1;
    let leftChildIndex;
    while (i < half && (leftChildIndex = (i << 1) + 1, (leftChildIndex + 1 < len && heap[leftChildIndex + 1].sortIndex < heap[leftChildIndex].sortIndex ? leftChildIndex + 1 : leftChildIndex)).sortIndex < node.sortIndex) {
        heap[i] = heap[leftChildIndex];
        i = leftChildIndex;
    }
    heap[i] = node;
}

// 4. requestHostCallback 模拟 (使用MessageChannel)
let scheduledHostCallback = null;
let isMessageLoopRunning = false;
let port1, port2;

if (typeof MessageChannel !== 'undefined') {
    const channel = new MessageChannel();
    port1 = channel.port1;
    port2 = channel.port2;
    port2.onmessage = () => {
        isMessageLoopRunning = false;
        const callback = scheduledHostCallback;
        scheduledHostCallback = null;
        if (callback !== null) {
            callback(); // 执行调度器的主工作循环
        }
    };
}

function requestHostCallback(callback) {
    scheduledHostCallback = callback;
    if (!isMessageLoopRunning) {
        isMessageLoopRunning = true;
        port1.postMessage(null); // 触发下一个宏任务
    }
}

// 5. shouldYield 逻辑 (时间切片核心)
const frameInterval = 5; // 每次执行任务的最大时间，例如5ms
let deadline = 0; // 当前时间片的结束时间

function shouldYieldToHost() {
    const currentTime = performance.now();
    // 如果当前时间超过了deadline，就应该让出控制权
    // 真实的Scheduler还会考虑是否有更高优先级任务等待
    return currentTime >= deadline;
}

// 6. 调度器主工作循环：flushWork
function flushWork() {
    deadline = performance.now() + frameInterval; // 设置当前时间片的结束时间
    let currentTask = peek(taskQueue);

    while (currentTask !== null && !shouldYieldToHost()) {
        if (currentTask.is_cancelled) { // 任务可能在队列中被取消
            pop(taskQueue);
            currentTask = peek(taskQueue);
            continue;
        }

        const callback = currentTask.callback;
        if (typeof callback === 'function') {
            currentTask.callback = null; // 确保只执行一次

            // 执行任务回调，回调可能返回一个新的回调函数（表示任务未完成）
            const didYield = callback(); 

            if (didYield === true) {
                // 任务主动yield，表示未完成，保留在队列中，等待下次继续
                // 注意：这里简化了，真实React会返回剩余工作，这里用true表示需要继续
                console.log(`Task ${currentTask.id} (Prio: ${currentTask.priority}) yielded.`);
                return; // 立即让出，等待requestHostCallback再次触发
            } else {
                // 任务完成，从队列中移除
                console.log(`Task ${currentTask.id} (Prio: ${currentTask.priority}) completed.`);
                pop(taskQueue);
            }
        } else {
            // 任务没有回调函数，直接移除
            pop(taskQueue);
        }
        currentTask = peek(taskQueue);
    }

    if (currentTask !== null) {
        // 还有未完成的任务，但时间片已用尽，需要再次调度
        console.log("Time slice exhausted. Rescheduling remaining work.");
        requestHostCallback(flushWork);
    }
}

// 7. 外部API：scheduleCallback
function scheduleCallback(priority, callback) {
    const currentTime = performance.now();
    let timeout;
    switch (priority) {
        case ImmediatePriority: timeout = -1; break; // 立即执行，无延迟
        case UserBlockingPriority: timeout = 250; break; // 250ms
        case NormalPriority: timeout = 5000; break; // 5s
        case LowPriority: timeout = 10000; break; // 10s
        case IdlePriority: timeout = 25000; break; // 25s
        default: timeout = 5000; break;
    }
    const expirationTime = timeout === -1 ? currentTime : currentTime + timeout;
    const newTask = new CallbackNode(callback, priority, currentTime, expirationTime, nextTaskId++);

    push(taskQueue, newTask);
    console.log(`Scheduled Task ${newTask.id} with Priority ${priority} and Expiration ${expirationTime.toFixed(2)}ms`);

    requestHostCallback(flushWork); // 确保调度器开始运行

    return newTask; // 返回任务引用，可用于取消
}

function cancelCallback(task) {
    task.is_cancelled = true;
    console.log(`Cancelled Task ${task.id}`);
}

// ====================================================================
// 模拟使用场景
// ====================================================================

// 模拟一个耗时任务，可以被中断
function createHeavyTask(taskId, priority, iterations = 10000000) {
    let currentIteration = 0;
    return function heavyWork() {
        const start = performance.now();
        while (currentIteration < iterations && (performance.now() - start < 1)) { // 每次执行1ms左右
            // 模拟一些计算
            for (let i = 0; i < 1000; i++) Math.sqrt(i * Math.random());
            currentIteration++;
        }

        if (currentIteration < iterations) {
            console.log(`Task ${taskId} (Prio: ${priority}) progress: ${((currentIteration / iterations) * 100).toFixed(2)}%`);
            return true; // 表示任务未完成，需要继续
        } else {
            console.log(`Task ${taskId} (Prio: ${priority}) FINISHED.`);
            return false; // 表示任务完成
        }
    };
}

// 场景一：一个高优先级任务打断一个低优先级任务
console.log("n--- Scenario 1: High priority interrupts low priority ---");
const lowPrioTask = scheduleCallback(LowPriority, createHeavyTask('A', LowPriority, 50000000));
// 立即调度一个用户阻塞任务
setTimeout(() => {
    scheduleCallback(UserBlockingPriority, createHeavyTask('B', UserBlockingPriority, 10000000));
}, 100); // 在低优先级任务开始后100ms调度

// 场景二：正常优先级任务和空闲优先级任务交错
console.log("n--- Scenario 2: Normal and Idle priority tasks ---");
scheduleCallback(NormalPriority, createHeavyTask('C', NormalPriority, 20000000));
scheduleCallback(IdlePriority, createHeavyTask('D', IdlePriority, 30000000));
scheduleCallback(NormalPriority, createHeavyTask('E', NormalPriority, 15000000));

// 场景三：取消一个任务
console.log("n--- Scenario 3: Cancelling a task ---");
const cancelableTask = scheduleCallback(LowPriority, createHeavyTask('F', LowPriority, 40000000));
setTimeout(() => {
    cancelCallback(cancelableTask);
    scheduleCallback(UserBlockingPriority, () => {
        console.log("Urgent UI update after cancellation!");
        return false;
    });
}, 500); // 500ms后取消F并调度一个紧急任务

运行上述代码，你会在控制台中观察到以下行为：

1. 优先级排序：taskQueue会根据expirationTime（由优先级决定）进行排序。
2. 时间切片：flushWork在执行每个heavyWork的子任务时，会检查shouldYieldToHost()。如果时间片（5ms）用尽，它会打印“Time slice exhausted. Rescheduling remaining work.”，然后让出控制权。
3. 任务中断与恢复：heavyWork会返回true表示它尚未完成，调度器会将其保留在队列中，在下一个宏任务中继续执行。
4. 高优先级抢占：在场景1中，当Task A（低优先级）正在运行时，Task B（用户阻塞优先级）被调度。由于Task B的expirationTime更早（优先级更高），它会“插队”到Task A之前被执行。Task A会被暂停，直到Task B完成。
5. 取消任务：在场景3中，Task F会在中途被取消，调度器在flushWork中检测到is_cancelled标记后，会直接跳过并移除该任务。

这个简化模型清晰地展示了React调度器如何通过优先级队列、MessageChannel和时间切片机制，实现了对任务的精细控制，从而避免了主线程阻塞。

五、任务切片在行动：性能优化与用户体验

任务切片不仅仅是一个技术细节，它是React并发模式的核心，直接影响着用户对应用的感知性能。

5.1 响应式UI：告别卡顿

最直接的好处就是响应式UI。过去，一个复杂的组件更新可能导致整个页面冻结几百毫秒甚至几秒。现在，通过任务切片，这些长时间的任务被分解成微小的片段，在每一帧的空闲时间中执行。浏览器仍然有足够的时间来处理用户输入和动画，使得UI始终保持响应。

例如： 一个大型表格组件需要重新渲染数千行数据。

• 传统模式：用户点击排序按钮，UI冻结，直到所有数据处理和DOM更新完成。
• 并发模式 + 任务切片：用户点击排序按钮，表格开始更新。在更新过程中，用户仍然可以滚动页面、点击其他按钮，而不会感到卡顿。表格会“渐进式”地更新，或者在后台计算完成后一次性更新。

5.2 平滑的用户体验：无缝过渡

任务切片与优先级调度相结合，使得React能够实现平滑的用户体验。startTransition和useDeferredValue是React提供的两个API，它们直接建立在调度器之上。

• startTransition：将一个更新标记为“过渡”（transition）。过渡更新的优先级会降低，允许更紧急的更新（如用户输入）优先渲染。

  import { startTransition, useState } from 'react';
  
  function SearchInput() {
      const [query, setQuery] = useState('');
      const [searchResults, setSearchResults] = useState([]);
  
      const handleChange = (e) => {
          const newQuery = e.target.value;
          setQuery(newQuery); // 立即更新输入框 (高优先级)
  
          // 将搜索结果的更新标记为过渡，可以被中断
          startTransition(() => {
              fetchSearchResults(newQuery).then(results => {
                  setSearchResults(results); // 更新搜索结果 (低优先级)
              });
          });
      };
  
      return (
          <div>
              <input value={query} onChange={handleChange} />
              <SearchResults data={searchResults} />
          </div>
      );
  }

  在这个例子中，用户输入setQuery(newQuery)是高优先级的，会立即更新输入框。而setSearchResults(results)被包裹在startTransition中，其优先级降低。这意味着如果用户在搜索结果加载完成前继续输入，React会优先处理输入框的更新，保证输入流畅，而搜索结果的渲染则会被中断并稍后恢复。

• useDeferredValue：延迟更新某个值的渲染。它会返回一个“延迟版本”的值，当其他更紧急的更新在进行时，它会保持旧值，直到所有紧急更新完成后，再更新为新值。

  import { useDeferredValue, useState } from 'react';
  
  function SearchList({ query }) {
      const deferredQuery = useDeferredValue(query); // 延迟query的更新
  
      // 这里的ExpensiveList会使用deferredQuery进行渲染
      // 如果query更新很快，deferredQuery会保持旧值，直到UI空闲
      return <ExpensiveList query={deferredQuery} />;
  }
  
  function App() {
      const [searchInput, setSearchInput] = useState('');
      return (
          <div>
              <input value={searchInput} onChange={(e) => setSearchInput(e.target.value)} />
              <SearchList query={searchInput} />
          </div>
      );
  }

  useDeferredValue在内部也是依赖调度器来决定何时更新deferredQuery。它让昂贵的ExpensiveList组件的渲染可以被推迟，优先保证输入框的响应速度。

5.3 优化资源利用：CPU与电池寿命

通过将工作分解成小块并在浏览器空闲时执行，调度器有效地利用了CPU资源，避免了不必要的长时间占用。这不仅提升了性能，对于移动设备而言，也意味着更低的能耗和更长的电池寿命。

5.4 预加载与预渲染：提升用户感知速度

调度器允许React在后台执行低优先级的任务，例如预渲染未来可能访问的组件、预加载数据或执行离屏计算。这些任务可以在不影响当前用户体验的情况下悄悄进行，当用户真正需要它们时，它们已经准备就绪，从而大大提升了用户感知的加载速度。

六、进阶考量与未来展望

React调度器是一个高度优化的复杂系统，其内部实现远比我们今天讨论的简化模型要精妙。

6.1 更精细的调度策略

实际的React调度器会考虑更多因素来决定shouldYield：

• 剩余时间预测：它可能会尝试预测当前帧还剩下多少时间，而不是简单地使用固定时间片。
• 任务饥饿（Starvation）：防止低优先级任务长时间得不到执行。调度器可能会在一定时间后提升低优先级任务的优先级。
• 任务类型：区分不同的任务类型，比如网络请求、计算密集型任务等，并采取不同的调度策略。

6.2 浏览器原生调度API

目前，React调度器使用MessageChannel来模拟requestIdleCallback，因为它提供了更好的控制力。然而，浏览器社区也在积极探索更原生的调度API，例如W3C的scheduler.postTask()提案。如果这些原生API能够提供足够灵活的优先级和可中断性控制，React未来可能会直接利用它们，从而进一步优化调度性能和减少JavaScript运行时开销。

6.3 超越客户端渲染：服务端组件与流式HTML

调度器的思想不仅仅局限于客户端React。在React Server Components和流式HTML（Streaming HTML）等新趋势中，类似的调度和优先级管理思想也被应用，以在服务器端和客户端之间协调工作，实现更快的首屏渲染和渐进式加载。

七、React调度器：现代Web性能的幕后英雄

回顾我们今天的旅程，从前端性能的痛点出发，逐步揭示了React如何通过Fiber架构奠定可中断性的基石，再通过调度器实现精密的任务管理、优先级排序和时间切片。

React调度器是构建高性能、高响应性现代Web应用的关键。它将原本阻塞UI的复杂计算，巧妙地拆解成可协作的微任务，在每一帧的间隙中穿插执行，确保了即使在繁忙的应用中，用户也能享受到流畅、即时的交互体验。理解它的核心机制，不仅能帮助我们更好地使用React，更能启发我们对前端性能优化的深刻思考。