申明
本文翻译此处，我只是搬运工。翻译不准的地方请参考原文
原文作者：Christopher Chedeau (@vjeux)
正文
React是Facebook创造的构建用户界面的javascript框架。设计始终把性能放在心上。在这篇文章我将介绍diff机制以及React的render流程，这样我们就能自己优化app了
Diff机制
在开始我们的工作之前，我们先看看下面这个例子React是怎样工作的
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>; }
} });
是你描述了你的UI，我们应该知道渲染的结果不是实际的DOM节点。他们只是很小的Javascript对象。我们称之为虚拟DOM。
React像这样找到从先前渲染到下一步渲染的最小步骤。举个例子：如果我们挂载<MyComponent first={true} />变为挂载<MyComponent first={false} />，最后再不挂载它，DOM结构将像这样变化：
第一步
- 创建节点
<div className="first"><span>A Span</span></div>
第一步到第二部
- 把属性
className="first"替换为className="second"- 把节点
<span>A Span</span>替换为<p>A Paragraph</p>
最后
删除节点：<div className="second"><p>A Paragraph</p></div>
一级一级对应
（英文为Level by Level，应该是比较虚拟Dom树的时候是一级一级对应）
找寻两个任意树结构之间最小的变动是个 O(n^3)问题，如你所想这显然不适用，React使用简单强大的启发式算法使其时间复杂度接近 O(n).
React只会尝试一级一级去比价树，这样能显著减少其复杂性而且这不是一个损失，因为在web里极少有组件被移到树中不同的级别去，他们通常在子级中横向移动。
列表
假如我们有一个组件，里面有5个迭代，而我们要在下次在中间插入一个新组件。只有这些信息很难知道两个列表是如何对应的。
默认情况下，React将第一个列表的第一个组件，对应第二个列表的第二个组件，你可以提供key属性去帮助react知道该怎么对应。
组件
一个React app通常由很多组件组成一个大树，主要使用div。diff算法将只会比较有相同类的组件。
例如：如果我们把<Header>替换为<ExampleBlock>,React将会移除header接着创建example block。我们不必浪费我们宝贵的时间比较两个几乎没有相似性的组件。
事件代理
把事件绑到dom节点很慢，消耗内存。而React采用更好的技术称之为“事件代理”。React走的更远，采用W3C兼容的事件系统。这意味着ie8的事件操作bugs已经成为过去。所有的事件在不同浏览器中是一致的。
让我们来讨论它是如何实施的。一个事件监听将会被绑在document的初始节点上。当事件触发时，浏览器会给我们触发事件的DOM节点。为了在DOM结构中传播事件，React并不在虚拟DOM中迭代。
取而代之的是，因为每个React组件都有唯一的id用来编码层次结构。我们可以通过简单的操作获得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);
(个人理解ickBubbleListeners即时事件的hash map，‘a’，‘a.b.c’即是每个组件的id)
浏览器为每个事件和事件监听创建一个事件对象。这样你可以得到事件对象的引用甚至可以改变它。然而这样也意味着大量的内存分配。React在启动时会分配一个对象池，当要创建一个事件对象时，就从那个对象池中重复利用，这样大大减少了垃圾回收操作。
渲染
Batching(没有合适词翻译。。。批量？)
任何时候只要你在一个组件中调用了setState，React将把这个组件标记为dirty（脏），在事件循环结束后，React将找到所有脏的组件并重新渲染它们。
就是说，每一次事件循环Dom都会跟新一下。这个特性是建造高性能app的关键，而且通常用javascript很难实现。在React中，你默认就有了这个特性。
子树渲染
当setState调用时，组件会重新build其子虚拟DOM。如果你在根节点上调用setState,那么整个app都会重新渲染，所有的组件，即使它没有改变也会调用它的render方法。这听起来很低效，但实际中，它工作很好应为我们没有操作实际的DOM。
首先，我们谈论的是显示用户界面。应为屏幕空间是有限的，通常我们只会同时显示几百到上千个elements。Javascript有足够快的业务逻辑管理整个界面。
另一个很重要的是，当你写React代码时，不要一出现变化就在根节点上调用setState方法。你应该在接收变化事件的组件或其上面的组件上调用setState，你应该极少的在上层中调。这意味着变化只会在用户交互的地方。
有选择的子树渲染
最后，你可以通过下面的方法选择阻止子树的渲染：
boolean shouldComponentUpdate(object nextProps, object nextState)
通过判断先前组件和下一个组件的属性/状态，你能够告诉React这个组件是否需要重新渲染。当合适的处理这将会显著提高性能。
为了使用它，你必须能比较对象的差异，这里就牵扯到一些问题，如是否应该深度比较，如果深度比较，我么是否应该固定数据的结构，或是做深度拷贝。
而且你应该记住，这个函数总会被调用，所以你要确保自己写的函数的调用时间要比默认的启发式比较的时间少。
结论
使React快的技术不是新的。我们很早就知道直接操作DOM很费时，你必须将写操作，读操作，和事件代理批量处理，这样更快。。。
人们依旧在谈论它们，因为在实际中实施很困难。是什么是React脱颖而出，就是因为这些优化是默认实施的，这使你不必搬起石头砸自己的脚，不会使app运行的很慢。
React性能成本模型也很好理解：每次setState都会重新渲染子树。如果你想提高性能，就尽量在低层次结构中调用setState或者使用shouldComponentUpdate去阻止渲染很大的子树。
