参考：https://blog.csdn.net/lwh52000000/article/details/52938010
无论什么时候你在一个组件上调用setState，React就会把它标记为dirty。在循环事件的末尾，React会寻找所有的dirty组件然后重新渲染它们。
batching意味着在一个循环事件中，恰好有一个时间DOM本更新。这是构建一个高性能的app的关键而且很难用JavaScript实现，而在React中这是默认的。
Sub-tree Rendering
当setState在一个组件上被调用是，这个组件会为它的孩子节点重新建议虚拟DOM。如果你在根节点上调用setState那么整个React应用都会被re-render，这样，所有的组件哪怕是那些没有改变的，都会调用它们的render方法。这也许听起来很可怕，没有效率，但是事实上不会，因为我们并没有直接操作真正DOM，render返回的结果只是虚拟节点。
首先，我们讨论的是显示UI接口，因为屏幕尺寸的限制，你通常一次只会显示几百到几千的组件。JavaScript拥有足够快的业务逻辑处理速度来管理整个应用的接口；其次很重要的一点就是你很少会在整个应用的顶点调用setState，一般你会在改变的那个组件或者之上两三层的组件上调用，也就是说改变只会在用户交互的那个部分区域发生。
Selective Sub-tree Rendering
最后，你可以选择更新子树与否。只要你在一个组件里实现下面这个函数：
boolean shouldComponentUpdate(object nextProps,object nextState)
根据传入的下一个props/state和当前的props和state对比，判断是否改变以及是否需要更新。如果实现得好，这个函数可以给你的应用巨大的性能提升。
为了能够使用它，你要能够比较JavaScript对象。这会引发很多的问题比如浅比较还是深比较，如果是深比较的话是使用不可变数据结构还是深复制。
要记住，这个函数会一直被不停地调用，所以，你要保证实现它的话要比默认的render机制花费的时间要少，即便re-render不会发生也成立。
使得React快的方法并不是新发现的。我们很早就知道了DOM操作花费更多，应该批量读写操作，甚至事件委托更快等等。
在实践中，人们仍然在讨论这些，因为把很难它们应用到原始的JavaScript中。真正让React出色的是那些默认的性能机制。使用React，你很难把自己陷入困境，让自己的app变得缓慢。
React的性能花费模型也很容易理解：每次调用setState都会re-render整个子树。如果你想提升性能，尽可能少的调用setStae，使用shouldComponentUpdate来阻止大的子树的更新或者不必要的更新。
