react源码解析——react 任务调度：scheduleWork

React 创建了update，并且将 update 放入 updateQueue 中,接下来就是任务调度的过程。任务调度的起点是 scheduleWork 方法

一般先要进行调度的检查防止出现死循环。这个其实很好理解，就是你在render中进行setstate操作的时候 会有Maximum update depth exceeded报错

接下来是 markUpdateTimeFromFiberToRoot，该函数用于获得 FiberRoot 对象，并且根据计算出的本次更新的 expirationTime，更新 Fiber 上的 expirationTime，由此我们也可以推断出，React 的每次更新其实是从整个 Fiber 树的根节点开始调度的。
在此时他会比较fiber的expirationTime要小于当前的expirationTime，说明它的优先级要比当前的低，此时提高优先级（把当前过期时间变成fiber的过期时间）。向上遍历去更新expirationTime。

此外checkForInterruption如果当前fiber的优先级更高，需要打断当前执行的任务，立即执行该fiber上的update，则更新interruptedBy。enableUserTimingAPI 这个变量在生产环境下的值是false，所以这个函数其实是为开发方便准备的，没有太大意义。。

同步模式 => 是否是初次挂载 => 是 => 直接调用renderRoot渲染更新
同步模式 => 是否是初次挂载 => 否 => 调用scheduleCallbackForRoot进行callback调度
异步模式 => 获取优先级 => 调用scheduleCallbackForRoot进行callback调度

一次更新的产生，并不只影响当前 Fibre 对象，而是会影响到所有上层的 Fiber 节点，修改了当前 Fiber 对象的 expirationTime，修改了 Fiber 父节点 的 childExpirationTime。 2. 首次渲染，React 不会做任何调度，直接 renderRoot，因为首次渲染是没有调度的必要的。

当新的scheduleCallback的优先级更高时，中断当前任务cancelCallback(existingCallbackNode)
如果是同步任务，则在临时队列中进行调度
如果是异步任务，则更新调度队列的状态

中断***
cancelCallback 用于中断当前正在执行的任务。
分片**‘’
同步的更新变成可中断的异步更新

在每处理完成一个 Fiber 节点时，会检查时间片是否到时，如果到了，则会中断此次 “渲染” 。

等到下一次进来的时候，可以直接从 workInProgress 上次中断的 Fiber 节点开始处理即可。
“渲染” 过程被中断的话，还面临着另外一个问题：已经更新过的一部分 Fiber 节点该怎么办？
我们需要将它们回退到本次更新前的状态，才能保证新一次更新是正确的

fiber在渲染中每次都会经历协调Reconciliation与提交Commit两个阶段。

协调阶段：这个阶段做的事情很多，比如fiber的创建diff对比等等都在这个阶段。在对比完成之后即等待下次提交，需要注意的是这个阶段可以被暂停。

提交阶段：将协调阶段计算出来的变更一次性提交，此阶段同步进行且不可中断（优先保证渲染）。

那么接下来我将从源码角度，给大家展示下react是如何创建fiber节点，Reconciliation（diff）是如何对比，以及前文提到的剩余时间是如何运转的。

React 做任务调度的时候，如果任务没有延期，会调用 requestHostCallback(flushWork) 方法来执行任务。

后续还需要补充