共计 3541 个字符，预计需要花费 9 分钟才能阅读完成。
react 源码解析 16.concurrent 模式
视频解说（高效学习）：进入学习
往期文章：
1. 开篇介绍和面试题
2.react 的设计理念
3.react 源码架构
4. 源码目录构造和调试
5.jsx& 外围 api
6.legacy 和 concurrent 模式入口函数
7.Fiber 架构
8.render 阶段
9.diff 算法
10.commit 阶段
11. 生命周期
12. 状态更新流程
13.hooks 源码
14. 手写 hooks
15.scheduler&Lane
16.concurrent 模式
17.context
18 事件零碎
19. 手写迷你版 react
20. 总结 & 第一章的面试题解答
21.demo
concurrent mode
react17 反对 concurrent mode，这种模式的基本目标是为了让利用放弃 cpu 和 io 的疾速响应，它是一组新性能，包含 Fiber、Scheduler、Lane，能够依据用户硬件性能和网络情况调整利用的响应速度，外围就是为了实现异步可中断的更新。concurrent mode 也是将来 react 次要迭代的方向。
- cup：让耗时的 reconcile 的过程能让出 js 的执行权给更高优先级的工作，例如用户的输出，
- io：依附 Suspense
Fiber
Fiber 咱们之前介绍过，这里咱们来看下在 concurrent mode 下 Fiber 的意义，react15 之前的 reconcile 是同步执行的，当组件数量很多，reconcile 时的计算量很大时，就会呈现页面的卡顿，为了解决这个问题就须要一套异步可中断的更新来让耗时的计算让出 js 的执行权给高优先级的工作，在浏览器有闲暇的时候再执行这些计算。所以咱们须要一种数据结构来形容实在 dom 和更新的信息，在适当的时候能够在内存中中断 reconcile 的过程，这种数据结构就是 Fiber。
Scheduler
Scheduler 独立于 react 自身，相当于一个独自的 package，Scheduler 的意义在于，当 cup 的计算量很大时，咱们依据设施的 fps 算出一帧的工夫，在这个工夫内执行 cup 的操作，当工作执行的工夫快超过一帧的工夫时，会暂停工作的执行，让浏览器有工夫进行重排和重绘。在适当的时候持续工作。
在 js 中咱们晓得 generator 也能够暂停和持续工作，然而咱们还须要用优先级来排列工作，这个是 generator 无奈实现的。在 Scheduler 中应用 MessageChannel 实现了工夫切片，而后用小顶堆排列工作优先级的高下，达到了异步可中断的更新。
Scheduler 能够用过期工夫来代表优先级的高下。
优先级越高，过期工夫越短，离以后工夫越近，也就是说过一会就要执行它了。
优先级越低，过期工夫越长，离以后工夫越长，也就是过很久了能力轮到它执行。
lane
Lane 用二进制位示意工作的优先级，不便优先级的计算，不同优先级占用不同地位的‘赛道’，而且存在批的概念，优先级越低，‘赛道’越多。高优先级打断低优先级，新建的工作须要赋予什么优先级等问题都是 Lane 所要解决的问题。
batchedUpdates
简略来说，在一个上下文中同时触发屡次更新，这些更新会合并成一次更新，例如
onClick() {this.setState({ count: this.state.count + 1});
this.setState({count: this.state.count + 1});
} 在之前的 react 版本中如果脱离以后的上下文就不会被合并，例如把屡次更新放在 setTimeout 中，起因是处于同一个 context 的屡次 setState 的 executionContext 都会蕴含 BatchedContext，蕴含 BatchedContext 的 setState 会合并，当 executionContext 等于 NoContext，就会同步执行 SyncCallbackQueue 中的工作，所以 setTimeout 中的屡次 setState 不会合并，而且会同步执行。
onClick() {setTimeout(() => {this.setState({ count: this.state.count + 1});
this.setState({count: this.state.count + 1});
});
}export function batchedUpdates<A, R>(fn: A => R, a: A): R {
const prevExecutionContext = executionContext;
executionContext |= BatchedContext;
try {return fn(a);
} finally {
executionContext = prevExecutionContext;
if (executionContext === NoContext) {resetRenderTimer();
//executionContext 为 NoContext 就同步执行 SyncCallbackQueue 中的工作
flushSyncCallbackQueue();}
}
} 在 Concurrent mode 下，下面的例子也会合并为一次更新，根本原因在如下一段简化的源码，如果屡次 setState，会比拟这几次 setState 回调的优先级，如果优先级统一，则先 return 掉，不会进行前面的 render 阶段
function ensureRootIsScheduled(root: FiberRoot, currentTime: number) {
const existingCallbackNode = root.callbackNode;// 之前曾经调用过的 setState 的回调
//...
if (existingCallbackNode !== null) {
const existingCallbackPriority = root.callbackPriority;
// 新的 setState 的回调和之前 setState 的回调优先级相等 则进入 batchedUpdate 的逻辑
if (existingCallbackPriority === newCallbackPriority) {return;}
cancelCallback(existingCallbackNode);
}
// 调度 render 阶段的终点
newCallbackNode = scheduleCallback(
schedulerPriorityLevel,
performConcurrentWorkOnRoot.bind(null, root),
);
//...
} 那为什么在 Concurrent mode 下，在 setTimeout 回调屡次 setState 优先级统一呢，因为在获取 Lane 的函数 requestUpdateLane，只有第一次 setState 满足 currentEventWipLanes === NoLanes，所以他们的 currentEventWipLanes 参数雷同，而在 findUpdateLane 中 schedulerLanePriority 参数也雷同（调度的优先级雷同），所以返回的 lane 雷同。
export function requestUpdateLane(fiber: Fiber): Lane {
//...
if (currentEventWipLanes === NoLanes) {// 第一次 setState 满足 currentEventWipLanes === NoLanes
currentEventWipLanes = workInProgressRootIncludedLanes;
}
//...
// 在 setTimeout 中 schedulerLanePriority, currentEventWipLanes 都雷同，所以返回的 lane 也雷同
lane = findUpdateLane(schedulerLanePriority, currentEventWipLanes);
//...
return lane;
}Suspense
Suspense 能够在申请数据的时候显示 pending 状态，申请胜利后展现数据，起因是因为 Suspense 中组件的优先级很低，而离屏的 fallback 组件优先级高，当 Suspense 中组件 resolve 之后就会从新调度一次 render 阶段，此过程产生在 updateSuspenseComponent 函数中，具体能够看调试 suspense 的视频
总结
Fiber 为 concurrent 架构提供了数据层面的反对。
Scheduler 为 concurrent 实现工夫片调度提供了保障。
Lane 模型为 concurrent 提供了更新的策略
下层实现了 batchedUpdates 和 Suspense
