如果你能干的父母把你生的天生迎合这个世界，就是莫大的幸福了。万一没把你生得适应这个世界，那么要么一直忍气吞声，要么韬光养晦直至适应，没有别的路可走。 ——《我是猫》
1.概述
React通过render方法在内存中产生一个树形virtual dom结构，这个virtual dom结构会被react处理为一个浏览器接受的DOM树。正是virtual dom的引入，使得react更新性能能够得到一个较好的表现。
当完成了装载过程的时候，用户便拥有机会去引发界面的更新了。当用户触发了界面更新的时候，此时react仍然通过render方法去生成一个新的virtual dom，注意是生成了整棵virtual dom树，而不是引起变化的那部分。那么接下来的操作难道是利用整棵virtual dom树转化成DOM树以供浏览器重新渲染吗？在初次挂载过程自然是这样的。但是其它情况下那就不是这样了，毕竟虽然触发了页面的更新过程，但是引起更新的根源有可能就只是页面的一小部分，因此在页面发生更新时直接拿新生成的virtual dom去生成dom树是非常不应该的，至少在性能方面是不能接受的。
那么React在更新过程又是怎么尽力去避免性能问题的呢？答案就是react会提供一个“调和”过程，这个调优过程会对比新的virtual dom树以及旧的virtual dom树，接着找出两者所不同的地方，根据不同的地方来修改现有的DOM。那么这个调优过程判具体又是如何判断两棵virtual dom树是不同的呢？
2.调和过程
当React要比较两棵virtual dom树的时候，是从根节点开始递归往下对比的。在一棵树中，实际上每个节点都在某种意义上是某些节点的根节点。因此，这个对比算法可以从virtual dom树上的任何一个节点开始做比较。对于调和算法来说，首先他从根节点的类型开始作比较。对于这一步，具有两个结果：根节点的类型是相同的；根节点的类型是不同的。不同的结果，对于调和算法关于两个节点是否相同会有不同的看法。
3.如果根节点的类型不同的话
如果根节点的类型不同的话，那么react会认为两个virtual dom树之间的改变实在是太大了，会将所有与这个根节点有关的子节点都认为是不同的，因此这些无辜者都会被抛弃。那么此时将会经历哪些操作呢？答案就是这些旧节点的卸载以及新节点的挂载过程，注意对于此时的这种情况来说，尽管进入的页面的更新过程，但是对于react组件来说却不会进入组件的更新生命周期。
举个例子：
//before
<div>
<appHeader />
<appBody />
<appFooter />
</div>
//after
<section>
<appHeader />
<appBody />
<appFooter />
</section>
对于上面这个例子来说，我们将无实质性作用的包裹元素由div元素改为了section元素，对于这种情况来说，react会把旧的相关子节点(当然也包括根节点自己)给卸载，接着将新的节点给挂载到相应的位置上去。很显然的，这里实质性的内容appHeader等并没有发生变化，但是却还是被强制卸载挂载了一波。
那么如何避免上述这种情况呢？答案是没有，我们能做就只是避免无意义的更改元素的类型。难道不能通过设置shouldComponentUpdate来避免这种情况吗？答案是当然不能，因为这种情况下根本就不会进入组件的更新生命周期啊。
4.如果根节点的类型相同的话
注意，但我们比较根节点的类型的时候是不会比较节点的属性的。如果react认为根节点的类型是相同的话，那么此时调和过程将会认为可以重用某些内容，因此不会像上述情况中所提到的大刀阔斧的经历卸载过程以及装载过程，而是只是对组件进行更新过程。
具体一点描述的话，我们知道对于react来说，元素分为两类：dom元素，组件元素。当根节点是dom元素的时候，并且节点类型相同的话，那么react会比较dom元素上的属性以及content，如果发生变化的话，那么将只会在dom上修改相应的部分，不会多做某些不必要的更改。
如果根节点是组件元素的话，并且节点类型相同的话，那么此时react会比较两个组件元素上props的不同，利用新得到的props去更新原来的组件实例，引发这个组件的更新过程。
更新过程的生命周期函数，我们在前面也提到过，这里在温习一下：
- shouldComponentUpdate
- componentWillReceiveProps
- componentWillUpdate
- render
- componentDidUpdate
在更新过程中，如果我们的shouldComponentUpdate返回false的话，那么下面的生命周期函数就不会得到执行了，这些函数当然包括了那个挺消耗性能的render函数，因此对于shouldComponentUpdate来说，他就是掌握了react组件优化的生杀大权(当然，限于调和过程认为根节点的类型是相同的情况下)。
在这种情况下，react会接着处理当前根节点的子节点，把它们理解为根节点接着进行同样的处理。
5.sibling之间发生变化所引起的调和处理
在下面这种情况下：
//before
<CommentList>
<messageItem text="a" />
<messageItem text="b" />
</CommentList>
//after
<CommentList>
<messageItem text="c" />
<messageItem text="a" />
<messageItem text="b" />
</CommentList>
react处理上面这种情况很出乎意料：他不会认为是新添加了一个text props为“c“的messageItem插入到了第一位，而是认为原有的text props为"a"的messageitem的props被修改为了"c"，并且认为原有的text props为"b"的messageitem的props被修改为了"a"，接着新增了一个text props为"b"的messageitem。
很奇怪吧，而这种做法带来了这种问题：那就是原有的无辜的sibling都会进行更新过程(毕竟props都发生了变化能不更新吗？)，而新增得sibling那就是必备的挂载过程了。问题是这里造成了不必要的性能浪费，毕竟那些其余sibling的内容是没有发生丝毫变化的。
那么问题来了，如何避免这种情况呢？答案就是利用react 提供组件的key属性，这个key属性会被react理解为一个react组件的标志，只要你给上述情况的每一个messageItem元素都给添加了一个独一无二的key属性的话，那么我们给messageItem组件设置的shouldComponentUpdate函数就能够如期而至的起作用了。
6.需要注意的地方
当使用key属性的时候，我们必须给他设置一个独一无二的值；其次把数组的每一项的index设置为key的值也是错误的做法。
