React 的桶算法详解

桶算法（Bucket Algorithm）是React调度系统的核心秘密武器！它通过巧妙的时间分组，实现了批量更新和优先级管理。让我深入解释这个精妙的设计。

内容结合了deepseek产出，旨在碎片化理解一些react 的概念，以便后续整体的原理理解

一、什么是桶算法？

基本概念

想象你有一堆需要处理的信件，不是每封一收到就立刻处理，而是按时间分桶：

9:00-9:05收到的信 → 9:05桶
9:05-9:10收到的信 → 9:10桶

以此类推...

桶算法的核心思想：把相近时间的更新分配到同一个过期时间桶里。

代码实现

js 复制代码

// ReactFiberExpirationTime.js
function computeExpirationBucket(
  currentTime: ExpirationTime,
  bucketSizeMs: number,  // 桶的大小（毫秒）
  offset: number         // 偏移量
): ExpirationTime {
  // 关键公式：
  return (
    ((currentTime - offset + bucketSizeMs) / bucketSizeMs | 0) * bucketSizeMs + offset
  );
}

二、桶算法的数学原理

公式拆解：

复制代码

result = floor((currentTime - offset + bucketSize) / bucketSize) * bucketSize + offset

例子：理解计算过程

假设：

currentTime = 1234ms
bucketSizeMs = 100ms
offset = 10ms

计算步骤：

js 复制代码

1. currentTime - offset = 1234 - 10 = 1224
2. 加 bucketSizeMs: 1224 + 100 = 1324
3. 除以 bucketSizeMs: 1324 / 100 = 13.24
4. 向下取整: floor(13.24) = 13
5. 乘以 bucketSizeMs: 13 × 100 = 1300
6. 加 offset: 1300 + 10 = 1310

最终 expirationTime = 1310

可视化：时间线分桶

text 复制代码

时间轴：   0    100   200   300   400   500   600
桶边界：  |-----|-----|-----|-----|-----|-----|
offset=10:  10   110   210   310   410   510   610

更新时间点：
95ms  → 桶：110  (因为 (95-10+100)/100=1.85→floor=1→1×100+10=110)
105ms → 桶：110  (同一桶！)
115ms → 桶：210
195ms → 桶：210

三、React中的具体桶配置

1. 不同优先级的桶大小

js 复制代码

// 同步更新：没有桶，立即执行
const Sync = 1;

// 交互式更新（用户输入）：小桶，快速响应
function computeInteractiveExpiration(currentTime: ExpirationTime) {
  return computeExpirationBucket(
    currentTime,
    150,   // 桶大小：150ms 👈 小桶，快速过期
    10     // 偏移：10ms
  );
}

// 异步更新（数据获取）：大桶，可以等
function computeAsyncExpiration(currentTime: ExpirationTime) {
  return computeExpirationBucket(
    currentTime,
    5000,  // 桶大小：5000ms 👈 大桶，慢慢来
    250    // 偏移：250ms
  );
}

2. 为什么要有偏移量（offset）？

js 复制代码

// 没有offset的问题：
桶边界：0, 100, 200, 300...

// 更新在边界时间发生：
99ms → 桶：100
100ms → 桶：200 ❌ 差1ms却分到不同桶！

// 有offset（10）：
桶边界：10, 110, 210, 310...

99ms → 桶：110
100ms → 桶：110 ✅ 都在同一个桶！

目的：避免在桶边界附近的时间点被错误地分到不同桶。

四、桶算法的实际效果

场景：用户快速输入

js 复制代码

// 用户在输入框快速打字
onChange事件时间线：
时间(ms): 101, 105, 108, 112, 115, 120, 125...

// 使用桶算法（桶大小150ms，offset=10）：
101ms → (101-10+150)/150=1.606→1→1×150+10=160
105ms → (105-10+150)/150=1.633→1→160 ✅ 同一桶
108ms → (108-10+150)/150=1.653→1→160 ✅ 同一桶
112ms → (112-10+150)/150=1.68→1→160 ✅ 同一桶
115ms → (115-10+150)/150=1.7→1→160 ✅ 同一桶
120ms → (120-10+150)/150=1.733→1→160 ✅ 同一桶
125ms → (125-10+150)/150=1.766→1→160 ✅ 同一桶

// 这些更新都有相同的 expirationTime = 160
// React会把它们批量处理！

场景：混合优先级更新

js 复制代码

// 同时有用户输入和数据加载
时间线：
0ms: 用户开始输入
50ms: 数据加载完成
150ms: 用户继续输入

// 计算expirationTime：
// 用户输入（交互式，桶大小150ms）：
0ms → (0-10+150)/150=0.933→0→0×150+10=10
150ms → (150-10+150)/150=1.933→1→1×150+10=160

// 数据加载（异步，桶大小5000ms）：
50ms → (50-250+5000)/5000=0.96→0→0×5000+250=250

// 结果：
用户输入0ms: expirationTime = 10
数据加载50ms: expirationTime = 250
用户输入150ms: expirationTime = 160

// 执行顺序：10 → 160 → 250
// 用户输入优先！

五、桶算法的精妙之处

1. 自动批量处理

js 复制代码

// 没有桶算法：
更新A: 时间100 → expirationTime=100
更新B: 时间101 → expirationTime=101
更新C: 时间102 → expirationTime=102
// 三个不同的expirationTime，可能触发三次渲染

// 有桶算法（桶大小150）：
更新A: 时间100 → expirationTime=160
更新B: 时间101 → expirationTime=160
更新C: 时间102 → expirationTime=160
// 相同的expirationTime，一次渲染处理所有！

2. 优先级保持

js 复制代码

// 即使时间接近，不同优先级还是不同桶
const 当前时间 = 100;

// 交互式更新（高优先级）：
computeInteractiveExpiration(100) 
= computeExpirationBucket(100, 150, 10)
= 160

// 异步更新（低优先级）：
computeAsyncExpiration(100)
= computeExpirationBucket(100, 5000, 250)
= 5250

// 160 < 5250，所以交互式更新先执行！

3. 防止"优先级反转"

js 复制代码

// 场景：低优先级更新先调度，高优先级后到
// 时间线：
0ms: 数据更新开始（低优先级，expirationTime=5250）
10ms: 用户点击（高优先级，expirationTime=160）

// 没有桶算法可能：
数据更新: expirationTime=10
用户点击: expirationTime=11
// 错误！数据更新先执行（虽然它优先级低）

// 有桶算法：
数据更新: expirationTime=5250
用户点击: expirationTime=160
// 正确！用户点击先执行（160 < 5250）

六、桶大小选择的考量

React的选择：

js 复制代码

// 为什么是150ms和5000ms？
150ms ≈ 人类感知的"瞬时"阈值
- 小于150ms的延迟，用户感觉是"立即响应"
- 大于150ms，用户可能感觉"有点慢"

5000ms = 5秒，合理的网络请求超时时间
- 数据加载可以等5秒
- 超过5秒应该显示loading或错误

心理学依据：

js 复制代码

┌─────────────────────────────────────────────┐
│ 用户感知延迟                                 │
├─────────────────────────────────────────────┤
│ 0-100ms:    瞬时（感觉不到延迟）             │
│ 100-300ms:  轻微可感知                       │
│ 300-1000ms: 明显但可接受                     │
│ 1000ms+:    等待感明显                       │
└─────────────────────────────────────────────┘

七、桶算法的实际源码分析

源码位置：ReactFiberExpirationTime.js

js 复制代码

// 常量定义
export const NoWork = 0;
export const Sync = 1;
export const Never = 2147483647; // 最大的31位有符号整数

// 单位转换
export const msToExpirationTime = (ms: number): ExpirationTime => {
  // 总是添加一个偏移量，这样我们就不会与NoWork冲突。
  return ((ms / UNIT_SIZE) | 0) + MAGIC_NUMBER_OFFSET;
};

export const expirationTimeToMs = (expirationTime: ExpirationTime): number => {
  return (expirationTime - MAGIC_NUMBER_OFFSET) * UNIT_SIZE;
};

// 桶算法实现
export const ceiling = (
  num: number,
  precision: number,
): ExpirationTime => {
  // 这就是桶算法的核心！
  return (((num / precision) | 0) + 1) * precision;
};

export const computeExpirationBucket = (
  currentTime: ExpirationTime,
  bucketSizeMs: number,
  offset: number,
): ExpirationTime => {
  // 转换为毫秒
  const currentTimeMs = expirationTimeToMs(currentTime);
  
  // 应用桶算法
  const bucketTimeMs = ceiling(
    currentTimeMs - offset + bucketSizeMs,
    bucketSizeMs,
  );
  
  // 转换回ExpirationTime单位
  return msToExpirationTime(bucketTimeMs - bucketSizeMs + offset);
};

关键优化：位运算 | 0

js 复制代码

// (num / precision) | 0 相当于 Math.floor(num / precision)
// 但位运算比Math.floor快得多！

// 例子：
(13.24 / 100) | 0 = 0.1324 | 0 = 0
(132.4 / 100) | 0 = 1.324 | 0 = 1
// | 0 会丢弃小数部分，实现快速向下取整

八、桶算法的局限性

1. "桶边界"问题

js 复制代码

// 极端情况：更新恰好在桶边界两侧
const 桶大小 = 150;
const offset = 10;

// 更新A: 时间159ms
// 计算: (159-10+150)/150=1.993→1→160

// 更新B: 时间160ms  
// 计算: (160-10+150)/150=2.0→2→310 ❌

// 差1ms，但分到不同桶！
// 这就是为什么需要offset来缓冲

2. 长任务可能阻塞

js 复制代码

// 如果桶内有一个很长的任务
更新1-10: 都在160桶
更新1执行了200ms（超过桶大小）
更新2-10可能被延迟

// React的解决方案：时间切片
// 长任务会被中断，让其他更新有机会执行

九、现代React的演进

React 18的更新：更细粒度的优先级

js 复制代码

// React 17及之前：主要靠expirationTime
// React 18：引入了Lane（车道）模型

// Lane vs ExpirationTime：
// ExpirationTime: 基于时间，连续值
// Lane: 基于位掩码，离散优先级

// 例子：Lane优先级
export const SyncLane: Lane = 0b0000000000000000000000000000001;
export const InputContinuousLane: Lane = 0b0000000000000000000000000000100;
export const DefaultLane: Lane = 0b0000000000000000000000000010000;
export const TransitionLane: Lane = 0b0000000000000000000100000000000;

// 优势：
// 1. 更精确的优先级控制
// 2. 可以同时处理多个同优先级更新
// 3. 更好的并发支持

但桶算法思想仍在！

即使有了Lane模型，桶算法的核心思想------把相近的更新分组处理------仍然被保留：

js 复制代码

// React 18中，类似的思想：
function requestUpdateLane(fiber: Fiber): Lane {
  // 根据模式和场景返回不同的lane
  if (fiber.mode & ConcurrentMode) {
    if (currentEventPriority !== NoLane) {
      return currentEventPriority;
    }
    if (isTransitionPending()) {
      return TransitionLane;
    }
    // 类似桶算法的分组思想
    return getCurrentPriorityLevel() === ImmediatePriority
      ? SyncLane
      : DefaultLane;
  }
  return SyncLane;
}

十、桶算法总结

核心价值：

批量优化：相近时间的更新一起处理，减少渲染次数
优先级保持：不同优先级的更新有不同桶大小
响应性保证：用户交互用小桶，快速响应
效率提升：位运算等优化，性能极高

设计哲学：

js 复制代码

"不是每个更新都立即处理，而是聪明地分组处理"
"用户交互要快，数据加载可以等"
"用简单的数学实现复杂的行为"

现实比喻：

就像快递公司的集散中心：

9:00-9:15的快递 → 9:15班车
9:15-9:30的快递 → 9:30班车
紧急快递用小班车（15分钟一班）
普通快递用大班车（2小时一班）
这样既高效又保证紧急件优先

桶算法是React高性能的关键之一，它用简单的数学公式解决了复杂的调度问题，体现了React团队的精湛工程能力！

至此，结束。