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

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

2024-11-20 12:10

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

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

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

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

不相信的话可以用节点渲染去验证。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

然后react18使用了MessageChannel

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

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

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

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

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

在memorizedState中大概是个这样的关系：

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