12｜Fiber 架构的迭代动机与设计思想

为什么会产生“卡顿”这样的困局？

JavaScript 线程和渲染线程必须是互斥的：这两个线程不能够穿插执行，必须串行。当其中一个线程执行时，另一个线程只能挂起等待。在这样的机制下，当处理结构相对复杂、体量相对庞大的虚拟 DOM 树时，Stack Reconciler 需要的调和时间会很长，这就意味着 JavaScript 线程将长时间地霸占主线程，进而导致我们上文中所描述的渲染卡顿/卡死、交互长时间无响应等问题。

Fiber 是如何解决问题的

Fiber（丝、纤维），就是比线程还要纤细的一个过程，也就是所谓的“纤程”。纤程的出现，意在对渲染过程实现更加精细的控制。

Fiber 架构的应用目的，按照 React 官方的说法，是实现“增量渲染”，就是把一个渲染任务分解为多个渲染任务，而后将其分散到多个帧里面，实现增量渲染的目的，是为了实现任务的可中断、可恢复，并给不同的任务赋予不同的优先级，最终达成更加顺滑的用户体验。

React 16 之前，React 的渲染和更新阶段依赖的是如下图所示的两层架构	React 16为了实现“可中断”和“优先级”，两层架构变成了如下图所示的三层架构
Reconciler 这一层负责对比出新老虚拟 DOM 之间的变化，Renderer 这一层负责将变化的部分应用到视图上，从 Reconciler 到 Renderer 这个过程是严格同步的。	首先，每个更新任务都会被赋予一个优先级。当更新任务抵达调度器时，高优先级的更新任务（记为 A）会更快地被调度进 Reconciler 层；此时若有新的更新任务（记为 B）抵达调度器，调度器会检查它的优先级，若发现 B 的优先级高于当前任务 A，那么当前处于 Reconciler 层的 A 任务就会被中断，调度器会将 B 任务推入 Reconciler 层。当 B 任务完成渲染后，新一轮的调度开始，之前被中断的 A 任务将会被重新推入 Reconciler 层，继续它的渲染之旅，这便是所谓“可恢复”。

Fiber 架构对生命周期的影响

1. render 阶段：纯净且没有副作用，可能会被 React 暂停、终止或重新启动。

2. pre-commit 阶段：可以读取 DOM。

3. commit 阶段：可以使用 DOM，运行副作用，安排更新

其中 pre-commit 和 commit 从大阶段上来看都属于 commit 阶段。在 render 阶段，React 主要是在内存中做计算，明确 DOM 树的更新点；而 commit 阶段，则负责把 render 阶段生成的更新真正地执行掉。这两个阶段做的事情，和上文讲到的 React 架构分层结合起来更好理解。

React 15 中从 render 到 commit 的过程	React 16 中，render 到 commit 的过程

新老两种架构对 React 生命周期的影响主要在 render 这个阶段，这个影响是通过增加 Scheduler 层和改写 Reconciler 层来实现的。在 render 阶段，一个庞大的更新任务被分解为了一个个的工作单元，这些工作单元有着不同的优先级，React 可以根据优先级的高低去实现工作单元的打断和恢复。由于 render 阶段的操作对用户来说其实是“不可见”的，所以就算打断再重启，对用户来说也是 0 感知。但是，工作单元（也就是任务）的重启将会伴随着对部分生命周期的重复执行，这些生命周期是：

• componentWillMount

• componentWillUpdate

• shouldComponentUpdate

• componentWillReceiveProps

其中 shouldComponentUpdate 的作用是通过返回 true 或者 false，来帮助我们判断更新的必要性，一般在这个函数中不会进行副作用操作，因此风险不大。