fiber 架构的本质

直白的描述，啥是 fiber

唔，大家好久不贱……最近在研究 fiber，然后终于研究的差不多啦，就发篇文章

在文章开始之前，需要了解两个前置知识：

1. 链表

什么是链表，和传统的树有啥不同 其实最大的不同在于，就是链表上的没一个节点，都能知道自己的父节点，兄弟节点，子节点，这点在传统的树的递归中是没办法知道的

1. requestIdeCallback

这个 API 也是关键，简单说就是它接收的回调，会在每一帧的空闲时间执行

通俗讲，就是假如这里的一帧是十秒钟（假如），执行一个回调需要一秒钟，那么还剩九秒钟，再执行一次，直到执行十次，空闲时间塞满了

也就是说，这个 while 循环，是空闲时间的不断递减

以上，fiber 的执行过程就很明了了，这就是 fiber 的最关键

流程

不上代码，直白的描述整个流程

我们的 react 都是从 render 函数开始的，传统的 diff patch 的方法，会 render 的时候进行首次递归，这个过程会进行 diff 和 path，然后第二次之后的递归，是递归父组件，进行局部的 diff patch

fiber 不是这样

fiber 首次 render 的时候，就会调用一次 requestIdeCallback，之前说了，这个 api 会进行循环

这个循环，它负责变更 current fiber（当前的 fiber 节点） 前面提到，链表天生可以拿到 节点本身，还能拿到父节点，兄弟节点，子节点

而 fiber 节点，其实就是比 vnode 多了这些，

所以这个循环，变更 fiber 很简单，就是不断地将当前的 fiber ，变成 fiber.child，当没有 child 了，就向上找 slibing，兄弟再找不到了，就找父亲，全找完，完工

也就是说，这里有个全局的 current fiber 不断的变更

它会找孩子找兄弟找父亲，直到找完

与此同时，会进行组件更新，也就是原始 vnode 的更新，主要是更新 state，props，render() 出新的 vnode

其实到这里，fiber 就结束了

本质上就是不断地变更当前的 fiber ，顺便变更 state 和 props

还有一步就是 commit，相当于以前的 patch 操作

我们已经得知，current fiber 会被不断地更替，携带的 props 和 state 也会被不断更替，那很简单，commit 的参数就可以是 current fiber，进行 dom 操作

以上，是 fiber 的整个流程，其实比递归更加容易理解，整个设计也更加精彩，不能理解主要是因为文章太鸡肋，加上 react 的实现真的很难读懂

总结

fiber 架构的本质：

• 循环条件：利用 requestIdeCallback 空闲时间递减
• 遍历过程：利用链表，找孩子找兄弟找父亲