前言
浏览器中的渲染引擎是单线程的，几乎所有的操作都在这个单线程中执行——解析渲染DOM Tree和CSS Tree，解析执行JavaScript——除了网络操作。这个线程就是浏览器的主线程。单线程意味着，一段时间只做一件事，所以浏览器在同一时间内，其主线程只能关注于一个任务。
在Web开发中，很多人觉得，不就是写HTML和CSS将数据显示出来么，So Easy!抱着这样想法开发出来的网站，如果比较简单的话，还不能看出差别，但是一旦页面复杂，用户交互变多，弊端就会爆发：卡顿，没反应，容易崩溃……
稍有经验的前端工程师会知道，页面的DOM改变，就会导致页面重新计算DOM，进行重绘或者重排，DOM结构复杂或者频繁操作DOM通常是产生性能瓶颈的原因。而网站从最开始比较简单，开始变的越来越复杂，用户交互也会越来越多，怎么去减轻DOM操作带来的性能损耗就变得重要起来。
（图片来自：http://t.cn/R0wwkPo）
React来了
React是近几年非常火的一个前端框架，它第一次提出了Virtual DOM的概念。
Virtual DOM是一个JavaScript对象。每次，我们只需要告诉React下一个状态是什么，React就会自己构建一个新的Virtual DOM，然后根据新旧Virtual DOM快速计算其差异，找出需要重绘或重排的元素，告诉浏览器。浏览器根据相关的更新，重新计算DOM Tree，重绘页面。
我们下面看一个例子：
这个例子会在页面中创建一个输入框、一个按钮、一个BlockList组件。BlockList组件会根据NUMBER_OF_BLOCK的数值渲染出对应数量的数字显示框，数字显示框显示点击按钮的次数。我们最开始设置据NUMBER_OF_BLOCK为2 ，只渲染2个数字显示框。
首次渲染出页面之后，我们点击按钮，页面中的数字显示框的值由0变为1。如下图所示：
当点击按钮的时候，按钮点击次数从0变为1，我们需要告诉React下面要显示1了，于是，通过setState操作，我们告诉React: 下一个你需要显示的数据是1。然后，React 开始更新组件。对应的Virtual DOM Tree变化如下图所示。黄色表示状态被更新。
我们点击按钮，触发setState之后，React就会创建一个新的Virtual DOM，然后将新旧Virtual DOM进行diff操作，判断哪些元素需要更新，将需要更新的元素放到更新列表中，最后遍历更新列表更新所有的元素，这所有的过程都是React帮我们完成的。
对浏览器而言，这个过程仅仅是编译执行了一段JavaScript代码而已，我们把从setState开始，到页面渲染结束的浏览器主线程工作流程画出来，如下图所示。蓝色粗线表示浏览器主线程。
所以从拿到最新的数据，到将数据在页面中渲染出来，可以分为两个阶段。
- 调度阶段。这个阶段React用新数据生成新的Virtual DOM，遍历Virtual DOM，然后通过Diff算法，快速找出需要更新的元素，放到更新队列中去。
- 渲染阶段。这个阶段React根据所在的渲染环境，遍历更新队列，将对应元素更新。在浏览器中，就是跟新对应的DOM元素。除浏览器外，渲染环境还可以是Native，硬件，VR等。
想知道怎么React 怎么进行Diff的，可以看这里。
新问题
之前，React在官网中写道：
We built React to solve one problem: building large applications with data that changes over time.
现在更新为：
React is a declarative, efficient, and flexible JavaScript library for building user interfaces.
所以我们看出，React新的定位在于灵活高效的数据。但是在实际的使用中，尤其是遇到页面结构复杂、数据更新频繁的应用时，React的表现不尽如人意。
在上一个例子中，我们可以设置NUMBER_OF_BLOCK的值为100000（实际情况下，可能没有那么多），将其变为一个“复杂”的网页。
点击按钮，触发setState，页面开始更新。
点击输入框，输入一些字符串，比如“hireact”。我们可以看到，页面此时没有任何的响应。
等待7s，输入框中突然出现了之前输入的“hireact”，同时，BlockList组件也更新了。
在这等待的7s中，页面不会给我任何的响应，我会以为网站崩溃了，或者电脑死机了。如果没有让我等待几秒，只是等待了0.5秒，多等待几个0.5秒之后我会在心里默想：这是什么破网站！
显而易见，这样的用户体验并不好。
浏览器主线程在这7s的performance如下图所示：
黄色部分是JavaScript执行时间，也是React占用主线程时间，紫色部分是浏览器重新计算DOM Tree的时间，绿色部分是浏览器绘制页面的时间。
三种任务，占用浏览器主线程7s，此时间内浏览器无法与用户交互。但是DOM改变之后，浏览器重新计算DOM Tree，重绘页面是一个必不可少的阶段（紫色绿色阶段），浏览器一直都是这样执行的。主要是黄色部分执行时间较长,占用了6s，即React较长时间占用主线程，导致主线程无法响应用户输入。
新技能Get
可以确定的是复杂度为常数的diff算法还是很优秀的，主要问题出现在，React的调度策略--Stack reconcile。这个策略像函数调用栈一样，会深度优先遍历所有的Virtual DOM节点，进行Diff。它一定要等整棵Virtual DOM计算完成之后，才将任务出栈释放主线程。所以，在浏览器主线程被React更新状态任务占据的时候，用户与浏览器进行任何的交互都不能得到反馈，只有等到任务结束，才能突然得到浏览器的响应。
React这样的调度策略对动画的支持也不好。如果React更新一次状态，占用浏览器主线程的时间超过16.6ms[1]，就会被人眼发现前后两帧不连续，给用户呈现出动画卡顿的效果。
React核心团队很早之前就预知这样的风险的存在，并且持续探索可解决的方式。基于浏览器对 requestIdleCallback和requestAnimationFrame这两个API的支持，以及其他团队对这两个API的实现，如React Native团队。React团队实现新的调度策略--Fiber reconcile。
Fiber是一种轻量的执行线程，同线程一样共享定址空间，线程靠系统调度，并且是抢占式多任务处理，Fiber 则是自调用，协作式多任务处理。
Fiber Reconcile与 Stack Reconcile主要有两方面的不同：
首先，使用协作式多任务处理任务。将原来的整个Virtual DOM的更新任务拆分成一个个小的任务。每次做完一个小任务之后，放弃一下自己的执行将主线程空闲出来，看看有没有其他的任务。如果有的话，就暂停本次任务，执行其他的任务，如果没有的话，就继续下一个任务。
整个页面更新并重渲染过程分为两个阶段。
Reconcile阶段。此阶段中，依序遍历组件，通过diff 算法，判断组件是否需要更新，给需要更新的组件加上tag。遍历完之后，将所有带有tag的组件加到一个数组中。这个阶段的任务可以被打断。
Commit阶段。根据在Reconcile阶段生成的数组，遍历更新DOM，这个阶段需要一次性执行完。如果是在其他的渲染环境--Native，硬件，就会更新对应的元素。
所以之前浏览器主线程执行更新任务的执行流程就变成了这样。
其次，对任务进行优先级划分。不是每来一个新任务，就要放弃现执行的任务，转而执行新任务。与我们做事情一样，将任务划分优先级，只有当比现任务优先级高的任务来了，才需要放弃现任务的执行。比如说，屏幕外元素的渲染和更新任务的优先级应该小于响应用户输入任务。若现在进行屏幕外组件状态更新，用户又在输入，浏览器就应该先执行响应用户输入任务。浏览器主线程任务执行流程如下图所示。
我们重写一个组件，跟之前的一样。一个输入框，一个按钮，一个BlockList组件。BlockList组件会根据NUMBER_OF_BLOCK的数值渲染出对应数量的数字显示框，数字显示框显示点击按钮的次数。将NUMBER_OF_BLOCK设置为100000，模拟一个复杂的页面。不同的是，使用Fiber reconcile调度策略，设置任务优先级，让浏览器先响应用户输入再执行组件更新。
在对比代码差异之前，我们先执行同样的操作，对比一下浏览器的行为。
点击button，触发setState，页面开始更新。
点击输入框，输入一些字符串，比如“hireact”。我们可以看到，页面能够响应我们的输入了。
浏览器主线程的performance如下图所示：
可以看到，在黄色JavaScript执行过程中，也就是React占用浏览器主线程期间，浏览器在也在重新计算DOM Tree，并且进行重绘，截图显示，浏览器渲染的就是用户新输入的内容。简单说，在React占用浏览器主线程期间，浏览器也在与用户交互。这个才是我们在网站上面期望获得的体验，浏览器总是对我的输入有反馈。
那我们的代码改变了哪些呢？从下往上看：
首先，从reactDOM.render()变成了ReactDOMFiber.render()。我们使用了ReactFiber去渲染整个页面，ReactFiber会将整个更新任务分成若干个小的更新任务，然后设置一些任务默认的优先级。每执行完一个小任务之后，会释放主线程。
其次，render方法中返回的不再是一个被div元素包一层的组件列表，而是直接返回一个组件列表，这是React在新版中提供的新的写法。除此之外，可以直接返回字符串和数字。像下面：
再次，我们传给setState的不是最新状态，而是一个callback，这个callback返回最新状态。同上，这个也是React新版中提供的新的写法，同时也是推荐的写法。
最后，我们没有直接调用setState，而是将其作为callback传给了unstable_deferredUpdates这个API。从名字就可以看出，deferredUpdates是将更新推迟，unstable表明现在还不稳定，在开发阶段。从源代码上看，unstable_deferredUpdates做了一件事情，就是将传给它的更新任务的优先级设置为lowpriority。所以我们将seState 作为callback传给了unstable_deferredUpdates，就是告诉React，这个setState任务，是一个lowpriority的任务。（需要注意的是，并不确定React团队是否将unstable_deferredUpdates或者deferredUpdates作为一个开放的接口，现在这个版本[2]可以通过这个API去设置优先级。同时，从源代码可以看到，React团队想要实现“给任务设置优先级”的功能，目前只看到一个performWithPriority的接口，也还没有实现。）
我们点击按钮之后，unstable_deferredUpdates将这个更新任务设置为low priority。此时是没有其他任务存在的，React就开始进行状态更新了。更新任务进入了Reconcile阶段，我们点击输入框，此时，用户交互任务来了，此任务优先级高于更新任务，所以浏览器主线程将焦点放在了输入框……。之后更新任务进入了Commit阶段，不能将浏览器主线程放弃，到了最后浏览器渲染完成之后，将用户在更新任务Commit阶段的输入以及最新的状态显示出来。
对比Stack Reconcile和Fiber Reconfile的实现，我们可以看到React新的调度策略让开发者对React应用有了更细节的控制。开发者，可以通过优先级，控制不同类型任务的优先级，提高用户体验，以及整个应用程序的灵活性。
采用新的调度算法之后，会将动画的渲染任务优先级提高，对动画的支持会比较友好，具体例子可以看Lin Clark在React Conf 2017的演讲。
后记
看起来React Fiber很厉害的样子，如果要用的话，还是有一些问题是需要考虑的。
比如说，task按照优先级之后，可能低优先级的任务永远不会执行，称之为starvation；
比如说，task有可能被打断，需要重新执行，那么某些依赖生命周期实现的业务逻辑可能会受到影响。
……
React Fiber也是带来了很多的好处的。
比如说，增强了某些领域的支持，如动画、布局和手势；
比如说，在复杂页面，对用户的反馈会更及时，应用的用户体验会变好，简单页面看不到明显的差异；
比如说，api基本上没有变化，对现有项目很友好。
……
现在，react-fiber已经通过了所有的测试，在网站上面Is Fiber Ready Yet?http://isfiberreadyyet.com/，已经通过了所有的测试，还有4个warning需要fix。它会随着React 16发布，到底效果怎么样，只有用过才知道了。
