react fiber 主流程及功能模块梳理

因为有裁人消息流出+被打C的双重冲击，只好尽可能在被裁以前恶补一波本身的未知领域，随时作好准备

本文是本身在阅读完react fiber的主流程及部分功能模块的一篇我的总结，有些措辞、理解上不免有误，若各位读到这篇文章，请不要吝啬你的评论，请提出任何质疑、批评，能够逐行提出任何问题

阅读以前须要了解react和fiber的基本知识，如fiber的链表结构，fiber的遍历，react的基本用法，react渲染两个阶段（reconcile和commit），fiber的反作用（effectTag）

我的推荐的fiber阅读方法：

• facebook/react
• 初级入门最佳文章：司徒正美：React Fiber架构
  正美大哥的其它fiber文章，须要边看源码边看文章，只看文章会十分费解，不是他讲的很差，而是react细节太多又重要，讲太细更加云里雾里
• 排除ref、context等细节，排除suspense、error boundary等模块，reconcile+commit在react中我认为是比较简单的，最好本身看看源码，不懂再参考：onefinis：React Fiber 源码理解
• reconcile+commit嫌源码太长太杂，直接参考：Luminqi/learn-react，带讲解，且代码中影响主流程的源码已经被删光，须要注意其代码设定是expirationTime越小优先级越高，与最新版本的react相反

react调度器任务流程归纳

react为实现并发模式（异步渲染）设计了一个带优先级的任务系统，若是咱们不知道这个任务系统的运做方式，永远也不会真正了解react，接下来的讲解默认开启react并发模式

首先并发模式的功能：

1. 时间分片（time slice），保证动画流畅，保证交互响应，提高用户体验
2. 任务的优先级渲染

先从2提及，由于咱们要对react有一个全局的理解

首先，要知道调度算法包含一切，每个调度任务，都须要完成reconcile和commit的流程，所以ReactFiberScheduler.js即为react最核心的模块，完成任务调度全靠他；任务调度须要有一个调度器，细节请移步下文中的Scheduler.js；这个调度器按优先级顺序保存着多个任务，firstCallbackNode为当前任务，从最高优先级任务开始，如图所示：

调度器，双向循环链表结构，这些任务存在于macrotask

你们想象一下，调度器要实现任务的优先级调度，当高优先级任务来临时，当前运行的任务（firstCallbackNode）须要打断，让位给高优先级任务，这个过程必须在macrotask中完成，为何？首先requestIdleCallback为macrotask，并且这样的打断才是咱们须要的，由于若是在主线程来调度，用户的交互会被js运行卡住，你想打断都打断不了

咱们通常会在哪调用setState？

1. componentWillMount中调用setState；该生命周期的执行会运行在reconcile阶段，不加入任务调度器
2. componentDidMount中调用setState；该生命周期的执行会运行在commit阶段，react中有一个isRendering标志，true表示reconcile+commit正在进行，任务加入调度器须要isRendering为false，不加入任务调度器
3. onClick、onChange事件的事件回调函数中调用setState；react将这些事件触发的更新视为批量更新，调度任务不会加入调度器，而是收集全部的setState，再批量同步更新

又因为初始化渲染不开启并发模式，所以调度器中只会有三种来源的任务：

1. 在非主线程（setTimeout、promise等）中使用setState而建立的调度任务
2. 手动使用unstable_scheduleCallback以调用setState而建立的任务
3. 在2中，调度器开始执行setState任务，发起的调度任务

   

   3000、4000表明优先级；来源3的任务来自来源2

在1和3中，setState就真的成了异步更新了；对于1和3，react也会作一个合并的处理，将全部setState合并，如：

setTimeout(() => {
  this.setState({
    nums: this.state.nums + 1
  })
  this.setState({
    nums: this.state.nums + 1
  })
}, 0)
复制代码

若state.nums初始值为0，在非并发模式下，最终会更新到2，由于setState是同步的；而在并发模式下，nums最终仍然为1，由于第二个setState任务没法加入调度器；来源1和来源3都是调度任务，在react调度器中，调度任务不能同时出现两个或以上；为何有这个规则，咱们下文再谈。源码以下：

function scheduleCallbackWithExpirationTime(
  root: FiberRoot,
  expirationTime: ExpirationTime,
) {
  if (callbackExpirationTime !== NoWork) {
    // A callback is already scheduled. Check its expiration time (timeout).
    // 低级别的任务直接 return
    if (expirationTime < callbackExpirationTime) {
      // Existing callback has sufficient timeout. Exit.
      return;
    } else {
      if (callbackID !== null) {
        // Existing callback has insufficient timeout. Cancel and schedule a
        // new one.
        // 不然会取消当前，再用新的替代
        cancelDeferredCallback(callbackID);
      }
    }
    // The request callback timer is already running. Don't start a new one. } else { startRequestCallbackTimer(); } ... callbackID = scheduleDeferredCallback(performAsyncWork, {timeout}); } 复制代码

调度器已经简单介绍完毕，实现细节请移步下文的Scheduler.js；咱们能够把调度器想象成一个黑盒，当咱们每调用一次并发模式的setState时，就向调度器加入一个任务，它会自动帮咱们按优先级运行

每个并发模式调用的setState都会产生一个调度任务，而每个调度任务都会完成一次渲染过程，所以我预测在并发模式正式推出后，会有大量文章针对并发模式下的setState的优化文章，至少咱们如今能够知道并发模式下的setState可不能滥用；搞清楚了调度器和任务框架咱们再来深刻一下调度器中的每一个任务

调度任务细节

有了上文的总体框架，我以为这个时候你们能够本身去看看源码了，我只要告诉你performAsyncWork表明向调度器加入一个异步调度任务，而performSyncWork表明了主线程开始运行一个同步任务，源码阅读就不困难了

任务大流程

先简单思考一下，一个调度任务须要完成什么工做：

1. 首先，必须完成reconcile+commit的基本功能，也就是完成一次完整的渲染
2. 须要实现时间分片功能，这个固然不是简单地交给requestIdleCallback就好了，它只能帮咱们尽可能分配好时间来运行JS，详见下文；若是你的callback运行时间太长，它是没办法的，由于只要JS运行就会卡交互
3. 为了实现时间分片，须要实现打断功能，commit阶段要执行太多反作用，所以咱们最好在reconcile中实现打断
4. 为了避免卡交互，reconcile运行最好不要超过一帧的时间，须要帧内打断，此判断来自Scheduler.js
5. 任务运行的好好的，忽然来了个高优先级的大哥，那很差意思，你须要打断，等大哥运行完，你要从新开始运行，这个功能一样交给Scheduler.js，在当前任务内，咱们只要让reconcile打断就行

先验知识：

1. 调度任务从根节点（root）开始，按照深度优先遍历执行，根节点能够理解为ReactDOM.render(<App/>, document.getElementById('root'))所建立，正常来讲一个项目应该只有一个
2. 一个调度任务可能会包含多个root，执行完高优先级root，才能执行下一个root，高优先级root也是能够插队的
3. fiber.expirationTime属性表明该fiber的优先级，数值越大，优先级越高，经过当前时间减超时时间得到，同步任务优先级默认为最高
4. react当前时间是倒着走的，当前时间初始为一个极大值，随着时间流逝，当前时间愈来愈小；任务（fiber）的优先级是根据当前时间减超时时间计算，如当前时间10000，任务超时时间500，当前任务优先级算法10000-500=9500；新任务来临，时间流逝，当前时间变为9500，超时时间不变，新任务优先级算法9500-500=9000；新任务优先级低于原任务；
   注意：当时间来到9500时，老任务超时，自动得到最高优先级，由于全部新任务除同步任务外优先级永远不会超过老任务，react以这套时间规则来防止低优先级任务一直被插队
5. fiber.childExpirationTime属性表明该fiber的子节点优先级，该属性能够用来判断fiber的子节点还有没有任务或比较优先级，更新时若没有任务（fiber.childExpirationTime===0）或者本次渲染的优先级大于子节点优先级，那么没必要再往下遍历 当某组件（fiber）触发了任务时，会往上遍历，将fiber.return.expirationTime和fiber.return.childExpirationTime所有更新为该组件的expirationTime，一直到root，能够理解为在root上收集更新
6. fiber有个alternate属性，其实是fiber的复制体，同时也指向本体，用于react error boundary踩错误，随时回滚，执行完毕且无误后本体与复制体同步；在初始化时，react并不建立alternate，而在更新时建立

先看看调度任务的总流程：

调度任务大流程

从setState开始，区分同步或异步，同步则直接运行performWork，异步则将performWork加入到macrotask运行（调度器）；再根据isYieldy（是否能打断，同步则不能打断，为false） 来调用不一样的performRoot循环体；图中绿线表明异步任务，红框表示该过程可被打断；任务未执行完毕的话（被打断），这里会重复向调度器加入任务

注意：这里的打断表明macrotask中该任务已运行完毕，会把js运行交还给主线程，也是用户交互能获得喘息的惟一机会

再看看performRoot循环体：

performRoot循环体

循环判断是否还有任务以及!(didYield && currentRendererTime > nextFlushedExpirationTime)，didYield表示是否已经被调度器叫停；currentRendererTime能够理解为任务运行的当前时间，经过recomputeCurrentRendererTime()获得，上文说过，随着时间流逝，该值愈来愈小；nextFlushedExpirationTime表示将要渲染的任务的时间（root.expirationTime）；当两个表达式都为true时，循环才退出，didYield为true说明任务被调度器叫停，须要被打断，currentRendererTime > nextFlushedExpirationTime为true代表任务未超时

这里我认为判断有些重复，由于调度器已经为咱们判断了是否超时，超时则不会打断，我认为react在这里是一个双保险机制，具体缘由未知

进入循环，执行performWorkOnRoot() ，这个稍后再讲；接下来是findHighestPriorityRoot()，其实就是找最高优先级的root，并获得root的expirationTime，root的expirationTime即为将要执行的任务的时间即这里的nextFlushedExpirationTime；最后是算当前时间

再看看performWorkOnRoot()：

performWorkOnRoot

我已合并同步异步的状况，绿线表示异步多出来的部分；代码很简单，就是判断finishedWork是否为空，为空则renderRoot()，不为空则completeRoot() ，这里renderRoot即为reconcile过程，completeRoot即为commit过程，接下来看reconcile过程

reconcile

renderRoot其实只作两件事：

1. 执行一个workLoop循环体
2. 判断nextUnitOfWork是否为空，若不为空则任务未完成，下次再继续，为空则代表reconcile完成，赋值root.finishedWork，这时候才能commit

workLoop循环体：

workLoop循环体

看的出来workLoop即为循环求nextUnitOfWork的过程，直到nextUnitOfWork为空或者被打断；nextUnitOfWork是一个全局变量，就是遍历所在的fiber，那么workLoop就是不断地遍历，求出下一个fiber；先执行beginWork，beginWork作了什么？

1. 若是是初次渲染，须要把fiber的儿子们求出来
2. 若是是更新，须要将新的儿子们与原来的儿子们作对比（diff 算法）
3. 若是遍历到的是ClassComponent类型（组件）fiber，则要初始化组件，求出它的实例以及调用processUpdateQueue（参考后文）获得state，调用render渲染函数以获得JSX表示的虚拟节点，标记componentDidMount等反作用
4. 若是遍历到的是HostComponent类型（div等）fiber，标记Placement反作用

若是beginWork的结果为空，说明这个节点已经没有儿子了，接下来就该轮到completeUnitOfWork出场了，completeUnitOfWork须要作到：

1. 既然向下遍历已经到头了，须要向右遍历，向右遍历到头了，须要向上回朔
2. 将有effectTag标记的fiber给链接起来，加速commit过程
3. 作好appendChild工做
4. 如有事件，须要绑定事件系统，参考后文

commit

reconcile完成之后，接下来再回到performWorkOnRoot中的commitRoot，主要工做以下：

1. 按照reconcile链接的effect顺序来遍历fiber
2. 处理被标记的fiber的effectTag，如：Placement、Deletion、Snapshot等

react调度任务细节总结完毕，我并无说太多reconcile和commit的细节，由于我认为这部分写多了就不叫总结了，远不如本身读来的清楚

一个不错的比喻

将整个react项目比做一个大型矿场，用户是老板，调度器是包工头，调度任务是矿工，不一样的矿场表明着不一样的root；一个项目只能有一个矿坑（nextUnitOfWork），虚线底部表明矿已挖完，reconcile结束

• 老板发出让矿工挖矿的指令，由包工头来调度矿工，包工头会按矿工的优先级顺序来挖矿，最高级的矿工先挖矿，若来了更高级的矿工，当前矿工中止工做，让位给他
• 矿工开始挖矿时，会选择优先级高的矿场来挖矿，正如调度任务从高优先级的root开始调度
• 矿工须要定时休息（任务超过1帧时间），休息好了会接着原来的矿坑来挖矿
• 全部矿场只会有一个矿坑，若是中途替换了不一样矿工挖矿，矿工会新开一个矿坑来挖矿

疑问

• 为何调度器内只能有一个调度任务？

由于一个矿坑只产出一种矿，不一样矿工来挖同一个矿坑，有的矿工挖的是金矿，有的矿工挖的是煤矿，不容许；这里可能也有react15中setState合并的考虑

• 为何commit阶段不能打断？

commit阶段要执行componentDidMount这种react彻底失控的反作用，以及其它生命周期，固然不能打断，否则打断再运行，岂不是会重复调用屡次？ 在reconcile阶段，react一样避免调用任何失控的代码，如componentWillReceiveProps，componentWillReceiveProps，用户在这些生命周期里面调用setState，reconcile被打断后从新开始岂不是要调用屡次setState？

• 为何调度任务要从root开始调度？

  

  fiber结构

若是从目标fiber开始更新，如这里的fiber2，那么咱们的矿坑就能够从fiber2开始挖，节省了时间；可是你没有想过，root的优先级是会更新的，若是这时候fiber3拥有了更高优先级，那么会从fiber3开始遍历，因为遍历只能向下或向右，咱们会忽视fiber2的更新；因此不如把全部更新提到root，这样惟一的坏处就是被打断以后要从root开始遍历，可是至少不会漏掉更新

思考

1. react有个致命缺点，到了react16依然没有改进，那就是若是咱们有1万个节点，只变更其中的一个，那么react会在reconcile过程遍历1万次以上，即便最后commit只作一次，以及dom变动只作一次，可是reconcile的开销太不必了，vue在这点上完爆了react
2. 浏览器的改进会致使现有的react fiber架构崩溃，只须要作一个改进：JS执行不阻塞用户交互，动画，重排与重绘
3. react是否能使用web worker来改进调度器，调度器始终是个单线程任务执行器，若是咱们用web worker来调度任务更能使浏览器的性能发挥到极致，固然第一个前提就是咱们的矿坑（nextUnitOfWork）不能是个全局变量
4. react并发模式有一个说不上是bug，可是对于用户体验来讲是bug的问题
   xilixjd/xjd-react-study 这个页面，当用户在输入框中输入123时，输入框最终显示结果为3，或13，缘由是reconcile + commit过程太慢，用户在输入1时，页面上输入框的1都没刷出来，用户又输了2，刚刷出1时，用户又输入了3，因此setState接收到的多是单独的1，单独的2，单独的3或13
5. 再有，手动调用unstable_scheduleCallback时的timeout值很是有讲究，当用户以滚键盘的极快速度输入1-9时，timeout值设得太低，中间不少数字将不会被渲染！ 举例来讲，当输入1时，以unstable_scheduleCallback来调用setState，调度器中存在的任务是setState任务，而后setState任务又建立了一个调度任务，这个调度任务不断地打断重连，咱们的交互获得喘息，输入了2，3，4...调度器中又放入了多个setState任务，由于按得太快，这些任务在调度器中被链接到了一块儿；在第一个任务打断重连完毕后，接下来的几个setState任务所有执行并转成了调度任务，因为这几个调度任务expirationTime相等，执行的倒是不一样的setState任务，所以调度任务被合并，只会剩下最后一个执行的调度任务； 不过，当timeout值设置得够大时，问题将获得解决，由于这时候加入调度器的setState任务的expirationTime会很是大，它们的执行会很是靠后，在它们建立的每个调度任务执行完以后，所以输入框的数字将渲染得很完整，不过依然没法摆脱4的问题

TODO

1. react hooks
2. react suspense，error boundary
3. context，ref

react事件系统

react在这部分的内容不少很杂，可是我认为对主流程而言不必讲的太细，何况我也没看太仔细，这里更多细节只须要参考这篇文章React事件系统和源码浅析 - 掘金

简单来讲，react实现了一套事件系统；在更新props阶段，就为全部拥有事件回调的fiber绑定好事件（react事件系统），事件绑定在document上；触发事件时，进入事件系统，事件系统建立一个SyntheticEvent用来代替原生的e对象；接着，以冒泡/捕获的顺序收集全部fiber和其中的事件回调；再按冒泡/捕获顺序触发绑定在fiber上的回调函数

这里须要注意几点：

1. 在为document绑定事件的时候，有的事件会绑定几个附加的事件，如：当为input绑定change事件时，会将focus事件一同绑定，用意未知
2. 强交互事件（click，change）触发的是同步work，同步work会阻塞线程，也就是说同步work运行完才能开始新交互，可是这段在源码interactiveUpdates()里的判断让人费解，找不到其场景

if (
    !isBatchingUpdates &&
    !isRendering &&
    lowestPriorityPendingInteractiveExpirationTime !== NoWork
  ) {
    // Synchronously flush pending interactive updates.
    performWork(lowestPriorityPendingInteractiveExpirationTime, false);
    lowestPriorityPendingInteractiveExpirationTime = NoWork;
  }
复制代码

Scheduler.js —— 实现了requestIdleCallback的polyfill + 优先级任务的功能

关键词：requestAnimationFrame、frameDeadline、activeFrameTime、timeout、unstable_scheduleCallback、unstable_cancelCallback、unstable_shouldYield

简介

核心模块。react fiber的任务调度全靠它，我认为搞懂这个模块才能搞懂react schedule的过程，unstable_scheduleCallback、unstable_cancelCallback、unstable_shouldYield，三个api可以分别实现将任务加入任务列表，将任务从任务列表中删除，以及判断任务是否应该被打断

背景

主要实现方法是运用requestAnimationFrame + MessageChannel + 双向链表的插入排序，最后暴露出unstable_scheduleCallback和unstable_shouldYield两个api。

对第一位的理解须要看一下这篇文章，简单来讲是屏幕显示是显示器在不断地刷新图像，如60Hz的屏幕，每16ms刷新一次，而1帧表明的是一个静止的画面，若一个dom元素从左到右移动，而咱们须要这个dom每一帧向右移动1px，60Hz的屏幕，咱们须要在16ms之内，完成向右移动的js运行和dom绘制，这样在第二帧（17ms时）开始的时候，dom已经右移了1px，而且被屏幕给刷了出来，咱们的眼睛才会感受到动画的连续性，也就是常说的不掉帧。requestAnimationFrame则给了咱们十分精确且可靠的服务。

requestAnimationFrame如何模拟requestIdleCallback？

requestIdleCallback的功能是在每一帧的空闲时间（完成dom绘制、动画等以后）来运行js，若这一帧的空闲时间不足，则分配到下一帧执行，再不足，分配到下下帧完成，直到超过规定的timeout时间，则直接运行js。requestAnimationFrame能尽可能保证回调函数在一帧内运行一次且dom绘制一次，这样也保证了动画等效果的流畅度，然而却没有超时运行机制，react polyfill的主要是超时功能。

requestAnimationFrame一般的用法：

function callback(currentTime) {
  // 动画操做
  ...
  window.requestAnimationFrame(callback)
}
window.requestAnimationFrame(callback)
复制代码

其表明的是每一帧都尽可能运行一次callback，并完成动画绘制，若运行不完，也没办法，就掉帧。

Scheduler.js使用animationTick做为requestAnimationFrame的callback，用以计算frameDeadline和调用传入的回调函数，在react中即为调度函数；frameDeadline表示的是运行到当前帧的帧过时时间，计算方法是当前时间 + activeFrameTime，activeFrameTime表示的是一帧的时间，默认为33ms，可是会根据设备动态调整，好比在刷新频率更高的设备上，连续运行两帧的当前时间比运行到该帧的过时时间frameDeadline都小，说明咱们一帧中的js任务耗时也小，一帧时间充足且requestAnimationFrame调用比预设的33ms频繁，那么activeFrameTime会下降以达到最佳性能

有了frameDeadline与用户自定义的过时时间timeoutTime，那么咱们很容易获得polyfill requestIdleCallback的原理：用户定义的callback在这一帧有空就去运行，超过帧过时时间frameDeadline就到下一帧去运行，你能够超过帧过时时间，可是你不能超过用户定义的timeoutTime，一旦超过，我啥也无论，直接运行callback。

如何实现优先级任务？

Scheduler.js将每一次unstable_scheduleCallback的调用根据用户定义的timeout来为任务分配优先级，timeout越小，优先级越高。具体实现为：用双向链表结构来表示任务列表，且按优先级从高到低的顺序进行排列，当某个任务插入时，从头结点开始循环遍历，若遇到某个任务结点node的expirationTime > 插入任务的expirationTime，说明插入任务比node优先级高，则退出循环，并在node前插入，expirationTime = 当前时间 + timeout；这样就实现了按优先级排序的任务插入功能，animationTick会循环调用这些任务链表。

重难点

function unstable_shouldYield() {
  return (
    !currentDidTimeout &&
    ((firstCallbackNode !== null &&
      firstCallbackNode.expirationTime < currentExpirationTime) ||
      shouldYieldToHost())
  );
}
shouldYieldToHost = function() {
  return frameDeadline <= getCurrentTime();
};
复制代码

unstable_shouldYield被用来判断在任务列表中是否有更高级的任务，在react中用来判断是否能打断当前任务，是schedule中的一个核心api。

首先判断currentDidTimeout，currentDidTimeout为false说明任务没有过时，你们要知道过时任务拥有最高优先级，那么即便有更高级的任务依然没法打断，直接return false； 再判断firstCallbackNode.expirationTime < currentExpirationTime，这里其实是照顾一种特殊的状况，那就是一个最高优先级的任务插入以后，低优先级的任务还在运行中，这种状况是仍然须要打断的；这里firstCallbackNode实际上是那个插入的高优先级任务，而currentExpirationTime实际上是上一个任务的expirationTime，只是还没结算

最后是一个shouldYieldToHost()，很简单，就是看任务在帧内是否过时，注意到这边任务帧内过时的话是return true，表明直接就能被打断；

ReactUpdateQueue.js —— 用来更新state的模块

关键词：enqueueUpdate、processUpdateQueue

react15中，全部经交互事件触发的setState更新都会被收集到dirtyComponents，收集好了再批量更新；react16因为加入了优先级策略，在调度时连setState操做都被赋予不一样的优先级，在同一组件针对带优先级的调度任务及setState操做，是该模块的核心功能

首先贴两个数据结构（已删去部分不关注的属性）：

export type Update<State> = {
  expirationTime: ExpirationTime,
  payload: any,
  callback: (() => mixed) | null,
  next: Update<State> | null,
  nextEffect: Update<State> | null,
};

export type UpdateQueue<State> = {
  baseState: State,
  // 头节点
  firstUpdate: Update<State> | null,
  // 尾节点
  lastUpdate: Update<State> | null,
  // callback 处理
  firstEffect: Update<State> | null,
  lastEffect: Update<State> | null,
};
复制代码

fiber上有个updateQueue属性，就是来自上述数据结构。每次调用setState的时候，会新建一个updateQueue，queue中存储了baseState，用于记录state，该属性服务于优先级调度，后面会说；另外记录头节点、尾节点及用于callback的effect头尾指针；还有以链表形式链接的update，如图所示：

updateQueue

每当调用一次setState，会调用enqueueUpdate，就会在链表以后插入一个update，这个插入是无序的，然而不一样的update是带优先级的，用一个属性expirationTime来表示，payload即为调用setState的第一个参数。

当调度任务依次执行时，会调用processUpdateQueue计算最终的state，咱们不要忘了调度任务是带有优先级的任务，执行的时候有前后顺序，对应的是processUpdateQueue的前后执行顺序；而update也是优先级任务的一部分，当咱们按链表顺序从头至尾执行时，须要优先执行高优先级的update，跳太低优先级的update；react的注释为咱们阐明了这一过程：

假设有一updateQueue为A1 - B2 - C1 - D2；
A一、B2等表明一个update，其中字母表明state，数字大小表明优先级，1为高优先级；
调度任务按高低优先级依次执行，第一次调度是高优先级任务，从头结点firstUpdate开始处理，processUpdateQueue会跳太低优先级的update；
则执行的update为A1 - C1，本次调度获得的最终state为AC，baseState为A，queue的firstUpdate指针指向B2，以供下次调度使用；
第二次调度是低优先级任务，此时firstUpdate指向B2，则从B2开始，执行的update为 B2 - C1 - D2，最终state将与baseState：A合并，获得ABCD

以上即为processUpdateQueue的处理过程，咱们须要注意几点：

1. processUpdateQueue从头结点firstUpdate开始遍历update，并对state进行合并 对于低优先级的update，遍历时会跳过
2. 当遇到有被跳过的update时，baseState会定格在被跳过的update以前的resultState
3. baseState主要做用在于记录好被跳过的update以前的state，以便在下一次更加低优先级的调度任务时合并state
4. 全部调度任务完成后，firstUpdate和lastUpdate指向null，updateQueue完成使命

再看一个例子：

A1-B1-C2-D3-E2-F1 第一次调度：baseState：AB，resultState：ABF，firstUpdate：C2 第二次调度：baseState：ABC，resultState：ABCEF，firstUpdate：D3 第三次调度：baseState：ABC，resultState：ABCDEF，firstUpdate：null