React Fiber（v16)
在现有React中，更新过程是同步的，这可能会导致性能问题。
React决定要加载或者更新组件树时，会做很多事，比如调用各个组件的生命周期函数，计算和比对Virtual DOM，最后更新DOM树，这整个过程是同步进行的。表面上看，这样的设计也是挺合理的，因为更新过程不会有任何I/O操作，但是，当组件树比较庞大的时候，问题就来了。
假如更新一个组件需要1毫秒，如果有200个组件要更新，那就需要200毫秒，在这200毫秒的更新过程中，浏览器那个唯一的主线程都在专心运行更新操作，无暇去做任何其他的事情。想象一下，在这200毫秒内，用户往一个input元素中输入点什么，敲击键盘也不会获得响应，因为渲染输入按键结果也是浏览器主线程的工作，但是浏览器主线程被React占着呢，抽不出空，最后的结果就是用户敲了按键看不到反应，等React更新过程结束之后，咔咔咔那些按键一下子出现在input元素里了。
这就是所谓的界面卡顿，很不好的用户体验。
现有的React版本，当组件树很大的时候就会出现这种问题，因为更新过程是同步地一层组件套一层组件，逐渐深入的过程，在更新完所有组件之前不停止，函数的调用栈就像下图这样，调用得很深，而且很长时间不会返回。
React Fiber的方式：分片，破解JavaScript中同步操作时间过长
把一个耗时长的任务分成很多小片，每一个小片的运行时间很短，虽然总时间依然很长，但是在每个小片执行完之后，都给其他任务一个执行的机会，这样唯一的线程就不会被独占，其他任务依然有运行的机会。
React Fiber把更新过程碎片化，执行过程如下面的图所示，每执行完一段更新过程，就把控制权交还给React负责任务协调的模块，看看有没有其他紧急任务要做，如果没有就继续去更新，如果有紧急任务，那就去做紧急任务。
维护每一个分片的数据结构，就是Fiber。
react与mobx
React 和 MobX 是一对强力组合。React 通过提供机制把应用状态转换为可渲染组件树并对其进行渲染。而MobX提供机制来存储和更新应用状态供 React 使用。
对于应用开发中的常见问题，React 提供了优化UI渲染的机制， 这种机制就是通过使用虚拟DOM来减少昂贵的DOM变化的数量。MobX 提供了优化应用状态与 React 组件同步的机制，这种机制就是使用响应式虚拟依赖状态图表，只有在真正需要的时候才更新并且永远保持是最新的。
React通过diff虚拟DOM树的流程去找哪些组件要重绘，而通过Mobx 可以建立响应式组件，实现精准通知
而在传统 React 应用中，当状态、属性变化后会先调用 shouldComponentUpdate，该方法会深层对比前后状态和属性是否发生改变，再确定是否更新组件。shouldComponentUpdate 是很消耗性能的。Mobx 通过可观察数据，精确地知道组件是否需要更新，减少了调用 shouldComponentUpdate 这一步。这是 Mobx 性能好的原因之一。
响应式组件，即当且仅当组件依赖的可观察数据发生改变时，组件才会自动响应，并重新渲染。
当可观察数据变化时，Mobx 会调用 forceUpdate 直接更新组件。mobx的一个方法reaction，俩参数，一个是数据，一个是响应数据变更，响应数据变更的那个就是React的forceUpdate
vue的响应式原理类似mobx，我就觉得很好奇为什么vue在知道哪个数据更新的情况下不去直接改对应的dom而要重新在组件级别diff一次？
然后我看到一种说法：引入了vd，是因为它要考虑服务端渲染、同构渲染
模板引擎一次性去更新多个dom。但模板引擎依旧没有一种可以追踪状态的机制，当引擎内某个数据发生变化时，要操作dom去重新渲染整个引擎。
而虚拟dom可以很好的跟踪当前dom状态，因为他会根据当前数据生成一个描述当前dom结构的虚拟dom，然后数据发送变化时，又会生成一个新的虚拟dom，而这两个虚拟dom恰恰保存了变化前后的状态。然后通过diff算法，计算出两个前后两个虚拟dom之间的差异，得出一个更新的最优方法（哪些发生改变，就更新哪些）。可以很明显的提升渲染效率以及用户体验
因为虚拟dom是一个普通的javascript对象，故他不单单只能允许在浏览器端，渲染出来的虚拟dom可同时在node环境下或者weex的app环境下允许。有很好的跨端性
Mobx 与 Redux
Mobx 的优势来源于可变数据（Mutable Data）和可观察数据 (Observable Data) 。
Redux 的优势来源于不可变数据（Immutable data）。
不可变数据：只要创建后不修改即可。比如说，Redux 中的 state。每次修改都会重新生成一个 newState ，而不会对原来的值进行改变。所以说 Redux 中的 state 就是不可变数据。
reducer(state, action) => newState.
不可变数据的优势在于，可预测，可回溯。
Mobx 与 Redux 技术选型的本质，是在可变数据与不可变数据之间选择。
当与副作用打交道非常频繁，倾向于 Mobx 。例如 Http 请求的副作用，Dom 操作的副作用等等。使用不可变数据，还必须得使用中间件对副作用封装
而前端的程序以中小型程序为主，纯函数带来的可预测性的收益，远不及其带的代码复杂度（在 Redux 中修改一次状态，需要经过 Action、Dispatch、Reducer 三个步骤）所需要付出的成本。
Mobx知道哪些组件需要被更新，决定哪个组件更新的过程的时间复杂度是O(1)的，而Redux通过脏检查每一个connect的组件去得到哪些组件需要更新，有n个组件connect这个过程的时间复杂度就是O(n)。优化后，Redux的版本可以获得不错的性能。而Redux最完美的优化是为每一个点建立单独的store，这与Mobx精确定位数据依赖的方案在思想上是相同的。
规范
由 providers，consumers，高阶组件，render props 等其他抽象层组成的组件会形成“嵌套地狱”。
