这两天其实是有一些想看看react的，总觉得同部门的人用react写代码，而我还在用着上一代的backbone，对react还不算熟（之前用过个把月，参加了一个项目的初期研发）。今天准备阅读一篇之前熟悉react的时候看到的文章。
React的差异算法 React’s diff algorithm by Christopher Chedeau（Facebook Software Engineer ）
在学习react的时候，你必须明白，这不是真的dom node，而是虚拟dom节点。
当使用react来从上一个节点渲染下一个节点的时候，使用了代理 representation 来找到需要的最小步数。
文章举了这么一个例子：
var MyComponent = React.createClass({
render: function () {
if (this.props.first) {
return <div className="first"><span>A Span</span></div>;
} else {
return <div className="second"><p>A Paragraph</p></div>;
}
}
});
这时将<MyComponent first={true} /> 改成 <MyComponent first={false} />，最后再移除会发生什么。
发生的步骤分为三步
None to first
Create node: <div className="first"><span>A Span</span></div>
First to second
Replace attribute: className="first" by className="second"
Replace node: <span>A Span</span> by <p>A Paragraph</p>
Second to none
Remove node: <div className="second"><p>A Paragraph</p></div>
在任意两个树中找到修改的最小改变是一个O(n^3)时间复杂度的算法。这肯定不适用于生产环境。React使用了简单但是非常强大的搜索算法，能够在接近O(n)的时间复杂度内找到差异。
React使用的方法是一层一层的访问树结构。这大大的降低了复杂度，并且不会有大的损失。原因是在web应用中，几乎没有将一个组件移动到树中不同的层级上的情况，通常组件都是在children之间移动。
举个例子，如果有一个组件，在一次遍历中渲染了五个组件，并且在下一次渲染时在其中插入了一个新组件。只通过这些信息来判断并知道这两个列表之间的映射关系是非常困难的。
在React的默认情况下，会将前一个列表的第一个组件和下一个列表的第一个组件进行关联，以此类推。你可以提供一个key属性来帮助React发现映射。然后就可以很容易的在children中发现那个唯一的key.
通常情况下，一个React应用是由许多自定义的组件组成的，最终组合成一个由div组成的树。React会考虑这种额外的信息，并且只匹配有相同的class的组件。
例如，如果一个<Header>被一个<ExampleBock>替换了，React会移除<Header>，并且创建一个新的<ExampleBock>。我们不会花费时间来试图寻找这两个组件不相同的部分。
也就是说，如果两个自定义的组件class不同，就直接移除旧的并创建新的组件。如果class相同，才会去判断与之前的两个组件有什么不同。（按理来说，如果组件就不相同，应该也是不会去判断的，会直接移除旧的、创建新的）
使用原生的js在DOM节点中添加事件监控是非常慢的，而且还非常耗费内存。然而，在React中实现了一种名为“事件委派 event delegation”的流行的技术。React甚至走的更远，重新实现了一下W3C的事件系统。这意味着IE8的事件处理的（event-handling）bug（这里虽然写的是bug，但是我觉得原作者可能是想表达对原生js的事件的不满）已经是过去式了，并且所有的事件名称在不同的浏览器中是一致的。
让我来解释一下这是如何实现的。一个单事件监听被添加在document的根部。当一个事件被触发时，浏览器会直接给出目标DOM节点。这种方法能够成功主要是因为每个React组件有一个用来编码层级结构的唯一id。React使用一组的字符串来得到所有父节点的id。而且发现将所有的事件监听存储在hash map中，比将事件监听添加在虚拟DOM上的性能要好很多。
下面这个例子展示了当一个事件通过虚拟DOM传播时发生了什么：
// dispatchEvent('click', 'a.b.c', event)
clickCaptureListeners['a'](event);
clickCaptureListeners['a.b'](event);
clickCaptureListeners['a.b.c'](event);
clickBubbleListeners['a.b.c'](event);
clickBubbleListeners['a.b'](event);
clickBubbleListeners['a'](event);
浏览器为每个活动事件 event 和事件监听 listener 创建了一个新的对象。这些对象有很好的属性，可以保存它的引用，甚至可以去修改它。但是，这意味着这样会带来很高的内存花费。React启动时为这些对象分配了一个内存池。当需要一个事件对象时，可以在内存池中取到这个对象。这显著的减少了垃圾回收机制garbage collection所需要的内存 。（相关的垃圾回收机制可以参考这篇Memory Management
）
当你调用了一个组件上的setState时，React会将其标记为脏的 dirty。当事件循环结束时，React查询所有脏 dirty 的组件，并且重新渲染他们。
该合并意味着在事件循环中，只有一个确切的DOM被更新的时间点。这是构建一个高性能的应用的关键，并且在其他JavaScript代码中很难实现。在React应用中，你自然而然的使用它。
当setState被调用，组件会为其孩子重新构建虚拟DOM。如果你在根元素上调用setState，整个React应用会被重新渲染。所有的组件，甚至你从来没改变的组件，都会调用其render方法。这听起来很恐怖、效率很低，但是实际中，还是很可行的，因为这操作没有触摸实际的DOM。
这么做的原因有两点：
1、从展示用户界面的角度来说。因为屏幕的空间是有限的，很多情况下你需要一次展示成百上千个元素。JavaScript对于整个业务逻辑的接口管理来说已经足够的快了。
2、正常来说，每次事情发生变化时，通常不会在根节点上调用setState。你在接收到事件变化的节点或者上面一些节点上调用它。很少情况下你会到达根节点。这意味着更新只在用户交互的局部发生。
3、如果你使用了组件中的shouldComponentUpdate方法，这可以阻止一些子树 sub-tree 的重新渲染。
boolean shouldComponentUpdate(object nextProps, object nextState)
基于组件的前一个和下一个props/state，你可以告诉React这个组件没有改变并且不需要重新渲染。当正确实现时，会给你的应用带来巨大的性能的提升。
为了能够使用它，你不得不比较JavaScript对象。有许多问题会浮现出来，例如应该是浅比较还是深比较；如果是深比较，我们应该使用不可改变的数据结构还是使用深度拷贝。
并且你需要记住，即使重新渲染不是必须的，但是这个shouldComponentUpdate函数每次都会render的时候被调用，所以应该确保它花费的计算时间比React的搜索和重新渲染该组件的时间少，不然这个方法就毫无意义。
总结
让React实现更快的方法不是使用新的技术。很长时间以来我们已经知道了触摸DOM的花费是昂贵的，你应该打包你的读写操作，让事件委派的操作可以更快…
人们仍然在议论这些问题，因为在实际中，使用原声js代码很难将这些问题简单化。而React能够脱颖而出是因为，这些所有的优化已经被写在了框架里面。
React性能消耗的模型理解起来很简单：每次setState都会重新渲染整个子树。
如果你想要提升你的React应用的性能，你可以降低调用setState的频率，并且合理使用shouldComponentUpdate来阻止一些大子树的重新渲染。
