共计 1271 个字符，预计需要花费 4 分钟才能阅读完成。
这里要比照一下 stack 和 fiber 架构的不同以及 react 在 fiber 架构做了那些更改
这里说到了 react16 应用了 fiber, 那咱们看下 16 之前输出 stack 架构的实现的问题，说起 React 算法架构避不开“Reconciliaton”。
Reconciliation
React 官网外围算法名称是 Reconciliation，中文翻译是“协调”！[React diff 算法的实现就与之相干。
略微理解浏览器加载页面原理的前端同学都晓得网页性能问题大都呈现在 DOM 节点频繁操作上；
而 React 通过“虚构 DOM”+ React Diff 算法保障了前端性能
传统 Diff 算法
通过循环递归对节点进行顺次比照，算法复杂度达到 O(n^3)，n 是树的节点数，这个有多可怕呢？——如果要展现 1000 个节点，得执行上亿次比拟。。即使是 CPU 快能执行 30 亿条命令，也 很难在一秒内 计算出差别。
React Diff 算法
将 Virtual DOM 树转换成 actual DOM 树的起码操作的过程 称为 协调（Reconciliaton）。
React Diff 三大策略：
- tree diff
- component diff
- element diff
在 V16 版本之前 协调机制 是 Stack reconciler，V16 版本公布 Fiber 架构后是 Fiber reconciler。
咱们先说 Stack reconciler 存在的问题:
在 setState 后，react 会立刻开始 reconciliation 过程，从父节点（Virtual DOM）开始递归遍历，以找出不同。将所有的 Virtual DOM 遍历实现后，reconciler 能力给出以后须要批改实在 DOM 的信息，并传递给 renderer，进行渲染，而后屏幕上才会显示此次更新内容。
对于特地宏大的 DOM 树来说，reconciliation 过程会很长(x00ms)，在这期间，主线程是被 js 占用的，因而任何交互、布局、渲染都会进行，给用户的感觉就是页面被卡住了。
在这里咱们想解决这个问题的话, 来引入一个概念, 就是工作可中断, 以及工作优先级, 也就是说咱们的 reconciliation 的过程中会生成一些工作和子工作, 用户的操作的工作优先级是要高于 reconciliation 产生的工作的, 也就是说用户操作的工作是能够打断 reconciliation 中产生得工作的, 它会优先执行.
Fiber reconciler
原来的 React 更新工作是采纳递归模式，那么当初如果工作想中断，在递归中是很难解决，所以 React 改成了大循环模式，批改了生命周期也是因为工作可中断。
Fiber reconciler 应用了 scheduling(调度)这一过程，每次只做一个很小的工作，做完后可能“喘口气儿”，回到主线程看下有没有什么更高优先级的工作须要解决，如果有则先解决更高优先级的工作，没有则继续执行(cooperative scheduling 单干式调度)。
所以 Fiber 架构就是用 异步的形式解决旧版本 同步递归导致的性能问题。
本文借鉴于
https://segmentfault.com/a/11…