做了一次React Fiber架构的分享📎Fiber架构分享.pptx,这是文字版的。
一、.为什么会出现 Fiber 架构
React 15 至 React 16 发生的一个主要的变化是,从原先的 Stack Reconciler 转为了 Fiber Reconciler。那为什么React 团队要进行这样的更改呢?先让我们看一下 Stack Reconciler 所存在的问题。
在Stack Reconciler 中,进行渲染时,父组件调用子组件,我们可以类比为函数递归。当组件进行 diff 后,会以递归的方式去深度优先的遍历整个组件树,从而达到将整个组件树全部计算和渲染的目的:
image.png但这样做就会有一个问题,我们都知道浏览器给予用户一个不卡顿的体验,一般需要保证1秒60祯的刷新频率,换算下来,就是浏览器的每一帧生成的时间应该是在 16ms 左右。而大部分垃圾时间(janky),我们都可以归类于:同步任务所占用的CPU时间(主要是 JS 运算)+ 原始DOM更新。而Fiber的出现,主要所要解决的就是同步任务所占用的 CPU 时间(JS运算等等),其解决的方式是,将一个大块的同步任务(也就是我们上面所说的递归的去diff和计算虚拟DOM树),拆分成一个个小的同步任务,然后在每一个时间切片之间,去判断是否存在一些优先级更高的的事情,如果存在就优先去处理优先级高的任务,从而保证一次渲染计算不会占用太长的CPU运算的时间,让后续的 layout 和 paint 的时间是足够的:
image.png二、Fiber 架构的具体实现
对于Fiber架构的整体构成,我个人理解,主要可以分为以下两个部分:
- Fiber调度算法
- Fiber节点
其中Fiber调度算法,主要是用于任务优先级的确认(即高优先级的任务先指向,低优先级的任务的恢复亦或者直接放弃) 。而Fiber节点,则是一种数据结构,我们可以理解为一个对象,它是有虚拟DOM生成,用于存储一个渲染单位的一些基本信息,是Fiber实现的基石,其主要属性如下:
function FiberNode(
tag: WorkTag,
pendingProps: mixed,
key: null | string,
mode: TypeOfMode,
) {
// 静态数据结构属性
this.tag = tag;
this.key = key;
this.elementType = null;
this.type = null;
this.stateNode = null;
this.ref = null;
// 位置属性
this.return = null;
this.child = null;
this.sibling = null;
// 状态属性
this.pendingProps = pendingProps;
this.memoizedProps = null;
this.updateQueue = null;
this.memoizedState = null;
this.dependencies = null;
this.mode = mode;
// 记录 Effect 的属性
this.effectTag = NoEffect;
this.nextEffect = null;
this.firstEffect = null;
this.lastEffect = null;
// 调度优化优先级
this.lanes = NoLanes;
this.childLanes = NoLanes;
// 用于实现双缓存的属性
this.alternate = null;
}
React Fiber下的组件创建与更新,其本质上就是去构建一个由多个Fiber 节点相连组成的 Fiber 节点树的过程。而创建和更新 Fiber 节点树,React又将其分为了两个阶段去完成:
- Render 阶段(或者叫做:Reconciler 阶段)
- Commit阶段
2.1、Render阶段
React在Render阶段,主要做的一个事情是生成一个用于更新的 Fiber节点树,而在这个过程中,React不会做任何有副作用的事情,只会对副作用去做一个收集,等到Commit阶段再去做。这主要是由于我们上面所说的,React 的更新不再是一次性完成的了,而是可能会进行多次反复横跳,也就是说在Render阶段做的事情,可能会由于优先级的问题被执行多次。而具有副作用的一些操作,通常不是幂等的,如果被执行多次,可能会产生开发者预料不到的问题。而Commit阶段,则不会执行多次,因此React会将副作用操作进行收集,统一到Commit去完成,具体实现步骤可以看如下的思维导图:
image具体总结就是在Render阶段会做两个事情:
- 进行BeginWork,如果有Current Fiber Tree,则会依据Current Tree进行DIFF,生成 WorkInProgress 树,如果没有,则直接进行深度优先遍历去生成 WorkInProgress
- 进行Complete Work,对副作用进行收集,组成Effect List
2.2、Commit阶段
在得到最后所需要渲染的 WorkInProgress 树后,React会进入Commit阶段,在这个阶段React主要会做以下一些事情:
- 执行Render之后的生命周期函数
- 执行副作用操作
而它内部将Commit也分成了三个不同的阶段:
- before mutation阶段(执行DOM操作前)
- mutation阶段(执行DOM操作)
- layout阶段(执行DOM操作后)
主要做的事情如下思维导图:
image(这里有一个小的Tip需要注意,Hook中的 useEffect 是在Commit阶段之后执行的,也就是说,实际上它调用的时机会比所有的生命周期函数都要晚)
三、Fiber的局限性
首先就是Fiber的实现过于复杂,导致代码量以及源码的复杂度都直线上升,一方面增加了React的包的大小(相较于Vue),另一方面是让React源码的复杂度提升,更具有黑盒效益了。
另一方是,React Fiber所带来的收益往往没有我们想的那么大。具体的一些论述,可以去看尤大在Github上的一个回答,很精彩:
image.png
参考资料:
网友评论