如何理解 Fiber 架构的迭代动机与设计思想
在 16.x 版本中将其最为核心的 Diff 算法整个重写，使其以'Fiber Reconciler'的全新面貌示人。
那么 Stack Reconciler 到底有着怎样根深蒂固的局限性，使得 React 不得不从架构层面做出改变？而 Fiber 架构又是何方神圣，基于它来实现的调和过程又有什么不同呢？本讲我们就围绕这两个大问题展开讨论。
前置知识：单线程的 JavaScript 与多线程的浏览器
大家在入门前端的时候，想必都听说过这样一个结论：JavaScript 是单线程的，浏览器是多线程的。
对于多线程的浏览器来说，它除了要处理 JavaScript 线程以外，还需要处理包括事件系统、定时器/延时器、网络请求等各种各样的任务线程，这其中，自然也包括负责处理 DOM 的 UI 渲染线程。而 JavaScript 线程是可以操作 DOM 的。
这意味着什么呢？试想如果渲染线程和 JavaScript 线程同时在工作，那么渲染结果必然是难以预测的：比如渲染线程刚绘制好的画面，可能转头就会被一段 JavaScript 给改得面目全非。这就决定了 JavaScript 线程和渲染线程必须是互斥的：这两个线程不能够穿插执行，必须串行。当其中一个线程执行时，另一个线程只能挂起等待。
具有相似特征的还有事件线程，浏览器的 Event-Loop 机制决定了事件任务是由一个异步队列来维持的。当事件被触发时，对应的任务不会立刻被执行，而是由事件线程把它添加到任务队列的末尾，等待 JavaScript 的同步代码执行完毕后，在空闲的时间里执行出队。
在这样的机制下，若 JavaScript 线程长时间地占用了主线程，那么 渲染层面的更新就不得不长时间地等待，界面长时间不更新，带给用户的体验就是所谓的'卡顿'。一般页面卡顿的时候，你会做什么呢？我个人的习惯是更加频繁地在页面上点来点去，期望页面能够给我哪怕一点点的响应。遗憾的是，事件线程也在等待 JavaScript，这就导致你触发的事件也将是难以被响应的。
试想一下界面不更新、交互无反应的这种感觉，是不是非常令人抓狂？这其实正是 Stack Reconciler 后期所面临的困局。
为什么会产生'卡顿'这样的困局
Stack Reconciler 所带来的一个无解的问题，正是 JavaScript 对主线程的超时占用问题。为什么会出现这个问题？Stack Reconciler 是一个同步的递归过程。
同步的递归过程，意味着不撞南墙不回头，意味着一旦更新开始，就像吃了炫迈一样，根本停不下来。这里我用一个案例来帮你复习一下这个过程，请先看下面这张图：
在 React 15 及之前的版本中，虚拟 DOM 树的数据结构载体是计算机科学中的'树'，其 Diff 算法的遍历思路，也是沿袭了传统计算机科学中'对比两棵树'的算法，在此基础上优化得来。因此从本质上来说，栈调和机制下的 Diff 算法，其实是
树的深度优先遍历的过程。而树的深度优先遍历，总是和递归脱不了关系。
拿这棵树来举例，若 A 组件发生了更新，那么栈调和的工作过程是这样的：对比第 1 层的两个 A，确认节点可复用，继续 Diff 其子组件。当 Diff 到 B 的时候，对比前后的两个 B 节点，发现可复用，于是继续 Diff 其子节点 D、E。待 B 树最深层的 Diff 完成、逐层回溯后，再进入 C 节点的 Diff 逻辑......调和器会重复'父组件调用子组件'的过程，直到最深的一层节点更新完毕，才慢慢向上返回。
这个过程的致命性在于它是同步的，不可以被打断。当处理结构相对复杂、体量相对庞大的虚拟 DOM 树时，Stack Reconciler 需要的调和时间会很长，这就意味着JavaScript 线程将长时间地霸占主线程，进而导致我们上文中所描述的渲染卡顿/卡死、交互长时间无响应等问题
设计思想：Fiber 是如何解决问题的
什么是 Fiber？从字面上来理解，Fiber 这个单词翻译过来是'丝、纤维'的意思，是比线还要细的东西。在计算机科学里，我们有进程、线程之分，而 Fiber 就是比线程还要纤细的一个过程，也就是所谓的'纤程'。纤程的出现，意在对渲染过程实现更加精细的控制。
Fiber 是一个多义词。从架构角度来看，Fiber 是对 React 核心算法（即调和过程）的重写；从编码角度来看，Fiber 是 React 内部所定义的一种数据结构，它是 Fiber 树结构的节点单位，也就是 React 16 新架构下的'虚拟 DOM'；从工作流的角度来看，Fiber 节点保存了组件需要更新的状态和副作用，一个 Fiber 同时也对应着一个工作单元。
