瞧一瞧React Fiber

啥是React Fiber？

React Fiber，简单来讲就是一个从React v16开始引入的新协调引擎，用来实现Virtual DOM的增量渲染。

说人话：就是一种能让React视图更新过程变得更加流畅顺滑的处理手法。

咱们都知道：进程大，线程小。而Fiber（纤维）是一种比线程还要细粒度的处理机制。从这个单词也能够猜想：React Fiber会很“细”。到底怎么个细法，咱们接着往下看。

为何会有React Fiber？

以前说了，React Fiber是为了让React的视图更新过程变得更加流畅顺滑。怎么，以前React的视图更新不流畅，不顺滑了？

还真是的，在React v16以前，React的视图更新确实存在很大的性能问题，其中首当其冲的，就是它的同步更新机制。

在React决定要加载或更新一颗组件树以前，会大体作出以下一系列动做：调用各组件的生命周期函数 --> 计算和对比Virtual DOM --> 更新真实的DOM树。这个过程是同步的，也就是说，一旦这个过程开始，它就会一气呵成跑完，一直到真实DOM树更新完毕。

然而，当组件树比较庞大时，这种机制的问题就来了：一颗拥有300个组件的组件树须要所有更新，假设一个组件更新只需耗时1ms，整棵树更新一次就须要耗时300ms。在这300ms期间，浏览器的主线程一直在“专心致志”地忙着更新这颗组件树（这时函数的调用栈会很是长），对于页面上的任何操做都是“漠不关心”的。在这期间，假如用户在一个输入框敲了几个字，页面上也不会有任何反应，由于渲染按键输入结果也须要主线程来作，然而此时主线程正忙着更新组件树呢。等到300ms结束了，浏览器主线程有空了，才把刚刚敲的那几个字渲染到input输入框内。

太卡了，真的。

因为JavaScript的单线程工做特色，业内一直有个这样的原则：**任何动做都不要长时间霸占主线程，若是迟迟不归还主线程，那么在这期间程序就无法对其余输入做出响应。用户输入了却没有响应，或者说响应来的很慢，也就是咱们经常说的“卡顿”。显然，React的同步更新机制在组件树庞大时就违反了这一原则，犯了大忌。

这就是React Fiber出现的缘由：为了解决旧版React视图更新的性能瓶颈。

React Fiber到底怎么工做的？

首先，React Fiber并无解决更新庞大组件树耗时长的问题，实际上总的耗时仍是同样的长。可是它解决了一个被广大开发者口诛笔伐的恶行：长时间霸占主线程不放。

而它解决的方法就是：分片。

它的工做原理是这样的：把耗时长的更新任务拆解成一个个小的任务分片，每执行完一个小的任务分片，都归还一次主线程，看看有没有什么其余紧急任务要作。若是在归还主线程时恰巧发现有紧急任务，那么会立刻停掉当前更新任务，转而让主线程去作紧急任务，等主线程作完紧急任务，再从新作更新任务。（注意⚠️：是从新！不是从上次被打断的点继续）；若是没有紧急任务，才敢惟惟诺诺地继续作接下来的任务分片。

简单来讲，就是降了视图更新的优先级，把更新过程碎片化。

如今咱们捋一捋，React Fiber会这样处理一个更新过程：

1. 将一个更新过程分为Reconciliation阶段和Commit阶段；
2. 对于Reconciliation阶段进行分片处理，这个阶段能够被更紧急的任务打断，分片任务作到一半可能要重来；
3. 对于Commit阶段，直接一气呵成把DOM更新完，不能被打断。

React Fiber对咱们平常开发有什么影响？

React Fiber在Reconciliation阶段可能会调用如下生命周期函数（这也意味着在这个阶段的生命周期函数在一次加载和更新过程当中可能会被屡次调用）：

• componentWillMount
• componentWillUpdate
• componentWillReceiveProps
• shouldComponentUpdate

若是你恰巧没有上react hooks的车，而是使用传统的类组件进行开发，那么切记，不要在以上几个生命周期函数中作只须要作一次的操做（好比：页面初始化时发起一个ajax请求获取数据）。

若是你日常使用react hooks进行开发，那没事了，就当看了个热闹。