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