【react框架】别把Fiber整得那么难理解，来参考下我是咋理解的，用大白话解释

前言

看b站的视频和网上一些博客，在讲fiber的时候，动不动就上源码解释，各种高大上的概念词汇，对于第一次接触fiber想了解它的人来说极其的不友好。

所以我就在网上看了各种文章和视频，结合自己的理解，梳理了一下，写下这一篇用大白话解释fiber的文章，希望能帮助到新人。

文中还有很多不严谨的地方，但这都是为了好理解，我认为学习一个东西，要先理解大概，再去补充细节。

---

Fiber出现背景：响应式更新特性带来的问题

用过react的小伙伴们应该知道，当我们修改了一个组件的某个节点数据时，组件会重新去更新每一个节点，包括所有子组件，也就是大家常说的，自顶向下重新渲染组件。

不相信的话可以用节点渲染{Math.random()}去验证。

在每次的重新渲染过程中，都会重新生成一颗新的虚拟DOM树。

在react15中，设计的是stack架构。在做diff的时候，采用的是深度递归的方式去遍历的虚拟DOM树，而且这种递归是不能中途打断的，必须一次性遍历完。

如果这颗虚拟树很复杂（例如嵌套了很多复杂的子组件），主线程在做diff时，就会长期霸占时长，留给重排重绘合成的时间就无法保证1s内执行60次，也就是页面无法保证60Hz的刷新率，看起来就会卡了

这里不理解的话可以看【计算机原理交集】一起探讨和梳理下，浏览器怎么解析HTML文件的。

16版本为了解决这个痛点才推出了fiber，准确的来说叫做FIber架构。

---

Fiber带来的好处：拆分任务、按需执行

简单来讲，用上了fiber架构后能够把diff的任务切割成非常小的小任务。每次要做这些小任务的时候，看每16.66ms的主线程是否有空闲时期，有的话就塞入执行。

并且他还有个能力，打个不严谨的比方啊，例如某次的diff任务需要被分割成100份小任务，他不是一下子全部分割完，而是一边分割一边塞入每16.66ms的主线程空闲时期中执行。

---

Fiber简单原理描述

fiber的本质其实是一个js对象，是虚拟DOM节点对象到视图中间过程的一个包装对象。

diff算法中遍历虚拟树的时候，用的是深度优先。在react15的时候，遍历必须一次性全部完成，也就是遍历任务只有一次。

那么我们可以把每个虚拟DOM的节点改造一下，记录节点对象上都有父级、子级、兄弟节点的指向。

相当于就是把树结构改造添加上了链表的特性

这样有什么好处，当遍历任务中断的时候，我们可以记录遍历到的节点位置，下次继续遍历的时候，通过记录的位置找到遍历任务暂停的节点，通过指向关系继续遍历。

ok，那我们是不是可以通过这个思路去做细颗粒的任务切分了呢？

我们把每一个虚拟DOM节点添加上真实DOM属性，添加上各种关系指向的过程，就是一个简单的小任务，也叫单元任务。我称为fiber化。

例如一个DOM树有100个节点，那么他就可以被切分成100个单元任务，要fiber化100次。

这个过程就可以这样描述了：

当主线程空闲时，就遍历虚拟树fiber化每个节点，此时假如fiber化了20个，也就是完成了20个单元任务。这时主线程被其他任务占用了，记录遍历到的节点位置。接着主线程又空闲了，继续从第20个节点开始遍历，直到回到root节点后发现的子节点都fiber化过了，任务全部结束。

---

Fiber对象长啥样

我从网上嫖来一段给大家看看，其实只需要知道有指向，有类型就ok了：

type Fiber = {
  // 用于标记fiber的WorkTag类型，主要表示当前fiber代表的组件类型如FunctionComponent、ClassComponent等
  tag: WorkTag,
  // ReactElement里面的key
  key: null | string,
  // ReactElement.type，调用`createElement`的第一个参数
  elementType: any,
  // The resolved function/class/ associated with this fiber.
  // 表示当前代表的节点类型
  type: any,
  // 表示当前FiberNode对应的element组件实例
  stateNode: any,

  // 指向他在Fiber节点树中的`parent`，用来在处理完这个节点之后向上返回
  return: Fiber | null,
  // 指向自己的第一个子节点
  child: Fiber | null,
  // 指向自己的兄弟结构，兄弟节点的return指向同一个父节点
  sibling: Fiber | null,
  index: number,

  ref: null | (((handle: mixed) => void) & { _stringRef: ?string }) | RefObject,

  // 当前处理过程中的组件props对象
  pendingProps: any,
  // 上一次渲染完成之后的props
  memorizedProps: any,

  // 该Fiber对应的组件产生的Update会存放在这个队列里面
  updateQueue: UpdateQueue<any> | null,

  // 上一次渲染的时候的state
  memorizedState: any,

  // 一个列表，存放这个Fiber依赖的context
  firstContextDependency: ContextDependency<mixed> | null,

  mode: TypeOfMode,

  // Effect
  // 用来记录Side Effect
  effectTag: SideEffectTag,

  // 单链表用来快速查找下一个side effect
  nextEffect: Fiber | null,

  // 子树中第一个side effect
  firstEffect: Fiber | null,
  // 子树中最后一个side effect
  lastEffect: Fiber | null,

  // 代表任务在未来的哪个时间点应该被完成，之后版本改名为 lanes
  expirationTime: ExpirationTime,

  // 快速确定子树中是否有不在等待的变化
  childExpirationTime: ExpirationTime,

  // fiber的版本池，即记录fiber更新过程，便于恢复
  alternate: Fiber | null,
}

---

用什么关键api去实现的原理

其实严谨来说是问Scheduler的实现原理，因为任务切分与派发都是他去做的。它也被称为调度器

我听网上说是之前用的伪requestIdleCallback，去做的实现。因为requestIdleCallback的兼容性很差，例如safari直接就不支持了。

然后react18使用了MessageChannel

想详细了解的，具体可以参考React Scheduler 为什么使用 MessageChannel 实现

---

Fiber与Vue的响应式更新区别

用过Vue的都知道，Vue的响应式更新是精确更新，例如某个组件的节点发生改动，那就只更新这个节点就好了。利用的就是Proxy代理（Vue2是defineProperty），但每个响应式变量都需要代理，每个组件都搜集了很多依赖，所以在性能上也不是十全十美的。

我看网上还说，从响应式范围来看，React可以看做是应用级的响应式，Vue可以看做是组件级的响应式。

只能说这两者各有各的好吧。

---

hooks的链表结构

我们可以在fiber对象上找到一个这样的属性memorizedState，这个属性记录了组件内部hooks的调用顺序，例如：

const [ str, setStr ] = useState('a')
useEffect(() => {
  	//
    return () => {
        //
    }
})
useLayoutEffect(() => {
    //
    return () => {
        //
    }
})

在memorizedState中大概是个这样的关系：useState--->useEffect--->useLayoutEffect

那么正因为要记录这个hooks的链表关系，所以hook只能用在最高层的作用域上。 （举个例子，假如有个条件语句里也有hook，那它插入链表中哪个位置呢？所以不可能让这种情况发生）

如果有精力可以去看看这篇文章更加的深入的了解react中hooks链表：梳理useEffect和useLayoutEffect的原理与区别

我暂时还没搞的很清楚，等我以后有空了再来捋一遍