要说的是，在这些年的迭代更新中，React框架具有明亮的解决方案设计，纤维对帐（以下称为纤维）具有绝对位置。正如React团队所研究并不断地渗透了两年多的结果，纤维改善了React对复杂页面的响应和性能感知，因此在面对扩展页面场景时，它可以更加顺利地呈现。
在某个时间，调用Render（）方法来创建一个由React元素组成的树。在更新下一个状态或道具时，相同的Render（）方法返回另一棵树。回答需要判断如何如何处理根据这两棵树之间的差异有效地更新UI，以确保当前的UI与最新的树同步。
这是React和解者的设计动机，它也是React团队优化方向的主要主题。浏览器的渲染内容的合理分发以确保页面的及时更新是对帐的职责。
堆栈对帐（以下简称堆栈）为光纤的前身，就像其名称一样，通过堆栈实现任务的调度：将不同的任务（渲染更改）按堆栈中，每次绘制浏览器绘制浏览器时，请绘制浏览器时间，此堆栈中存在的任务将执行。
说到这一点，堆栈的问题显然已经暴露出来。我们知道刷新频率通常为60Hz。如今，支持高刷（120Hz+）的设备也正在增加。页面的每个帧消耗的时间也减少了1S/60↑≈≈16ms↓。浏览器需要执行以下任务
浏览器的1帧
但是用户不关心上述大多数过程，只能及时显示页面。如果我们在渲染时将堆栈的任务太多了，这导致其执行时间超过浏览器的框架，它将使此框架无法及时响应渲染页面，我们经常说我们经常说它掉落了。
堆栈体系结构的特征是将所有任务都按顺序推入堆栈，并且无法确认当前任务在执行时是否会消耗太长脚本。他们所做的事情是无法控制的。
因此，控制了React团队的方向，Fiber对帐者成为了。
实际上，纤维的概念并未由React。纤维的原始含义是纤维，这意味着计算机科学中的纤维。这是一个轻巧的执行线程。
线程，最小的操作系统单元可以执行操作计划。
在这里，不必通过纤维，线，X个程序等的定义混淆。从下图的定义可以看出，相同的线程类型将对不同的调度方具有不同的名称。
结合了定义和上图，我们可以知道纤维的特征：“轻巧且无饰面”
非占领，也称为合作，是一种多校法方法。与Premptive的多任务处理相比，协作多任务处理要求每个运行程序定期放弃自己的权利，知情通知，操作系统允许下一个程序运行。
React团队的目标也与此一致。通过呼叫和排放子任务的管理，确定了当前运行时处理的哪一部分：当需要渲染浏览器时，将线程放出并悬挂当前任务。，将恢复，并通过合理使用资源来实现多任务处理。
为了实现上述目标，React团队根据堆栈堆栈调整了数据结构调整，并分解了需要将其处理为增量执行单元。实现方法是链接列表。
链接列表比堆栈更有效。对于顺序调整，删除等，您只需要更改节点的指针即可。在多个方向链接列表中，您不仅可以根据当前节点找到下一个节点，而且还可以在他当前的节点中找到他，还可以在他的当前节点中找到他。FATHERNODE或兄弟节点。由于更多的指针，列表将占用更多的站立空间。
在React项目的文件中，有一个光纤单元的定义。每个虚拟节点现在由光纤表示。
如前所述，堆栈基于堆栈，每个更新操作将始终占据主线程，直到更新完成为止。这可能导致事件响应延迟，动画卡住了。
在纤维机制中，它采用了“转化为零”的策略。当和解者开始调度时，它会将vdom的庞大任务穿越到几个小任务中。每个任务仅负责一个节点的处理。
处理当前任务时会生成下一个任务。如果此时浏览器需要执行渲染操作，则需要强制执行。如果没有生成下一个任务，则该渲染操作将完成。
至于反应如何进一步实现线程控制，官方文件中的开发团队的设计原理写道：
遵循上述原则，我们可以从上面理解，线程控制与维护框架的渲染密不可分，因此自然可以在实施计划中考虑这种API。
方法插入了一个函数，该函数将在浏览器的自由期间调用。这使开发人员能够在主事件的循环中执行背景和低优先级工作，而不会影响延迟的关键事件。
如果您使用这两个API，此时，光纤任务计划如下图所示
使用RAF任务计划
它看起来很完美，好像是为此诞生的。纤维的早期版本确实使用了这样的解决方案，但这已经过去了。在19年更新中，React团队推翻了先前的设计并将其用于实现线程控制。
MessageChannel允许我们创建一个新的消息频道并通过其两个MessagePort属性发送数据。此功能可在Web Worker中获得。使用方式如下：
React开发成员对此更新表示：对硬件设备的过多依赖无法进一步降低任务计划的频率以获得更大的优化空间。用于任务调度的少量消息事件（5ms）。尽管它将加剧主线程和其他浏览器任务之间的战斗，但值得尝试。
React提交消息
可以在源代码的最新版本中看到，这种“尝试实验”到今天已经使用了。
在这里，我们只看第二种情况。React将使上述集中兼容性处理，并最终获得类似的功能
然后，我们看到如何处理事件
整个过程可以在下图中表示
线程的任务计划的初步模型已可用，然后我们将看到光纤如何控制线程：
当时，我们将让主线程（在中间计算）默认为5ms。如果任务运行超过5ms，则控制权的控制将在执行下一个任务执行之前返回浏览器，以确保在浏览过程中及时渲染。
该任务的恢复将旁边进行，以查看大纲中断的任务是如何恢复的。
代码中定义了任务队列：
通过任务创建
可以看出[4中提到的方法。上述代码中的请求调度]也是开始。实际上，注册实际上返回函数。因此，我们继续看到：
这样，在循环中，通过分配值一次又一次地，光纤始终保留当前任务的执行，以及时中断它，然后使用下一个恢复任务计划。
可以看出，对任务调度过程的总体控制更加可控，并且较少依赖其他因素。尽管开发人员不感知这种变化，但其背后的设计思想值得我们学习。纤维将如何更新下次，我们将拭目以待。
纤维的引入首先结束。希望您今天能获得一些东西。
欢迎将您的建议或问题留在评论区域，欢迎您指出文章中的错误。QIQI表示，将来该框架系列将继续更新。有兴趣的朋友不能忘记跟随我们?