阅读 588

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.expirationTimefiber.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循环体
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
performWorkOnRoot

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

reconcile

renderRoot其实只做两件事:

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

workLoop循环体:

workLoop循环体
workLoop循环体

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

  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结构

如果从目标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_scheduleCallbackunstable_cancelCallbackunstable_shouldYield,三个api能够分别实现将任务加入任务列表,将任务从任务列表中删除,以及判断任务是否应该被打断

背景

主要实现方法是运用requestAnimationFrame + MessageChannel + 双向链表的插入排序,最后暴露出unstable_scheduleCallbackunstable_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表示的是运行到当前帧的帧过期时间,计算方法是当前时间 + activeFrameTimeactiveFrameTime表示的是一帧的时间,默认为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。

首先判断currentDidTimeoutcurrentDidTimeout为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
updateQueue

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

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

假设有一updateQueue为A1 - B2 - C1 - D2;
A1、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. 所有调度任务完成后,firstUpdatelastUpdate指向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

关注下面的标签,发现更多相似文章
评论