高德纳: "我们应该忘记忽略很小的性能优化，可以说97%的情况下，过早的优化是万恶之源，而我们应该关心对性能影响最关键的另外3%的代码。"
不要将性能优化的精力浪费在对整体性能提高不大的代码上，而对性能有关键影响的部分，优化并不嫌早。因为，对性能影响最关键的部分，往往涉及解决方案核心，决定整体的架构，将来要改变的时候牵扯更大。
1. 单个React组件的性能优化
React利用Virtual DOM来提升渲染性能，虽然每一次页面更新都是最组件的从新渲染，但是并不是将之前的渲染内容全部抛弃重来，借助Virtual DOM，React能够计算出对DOM树的最少修改，这就是React默认情况下渲染都很迅速的秘诀；
不过，虽然Virtual DOM能够将每次DOM操作量减少到最小，但，计算和比较Virtual DOM依然是一个复杂的过程；
当然，如果能够在开始计算Virtual DOM之前就判断渲染的结果不会有变化，那么就可以不进行Virtual DOM计算和比较，速度就会更快。
2.shouldComponentUpdate的默认实现方式
既然可以对组件在开始计算Virtual DOM之前判断渲染结果不会有变化时，阻止渲染的进行，从而提升性能，那么我们自然想到使用shouldComponentUpdate(nextProp,nextState)
shouldComponentUpdate函数在render函数之前调用，决定“什么时候不需要从新渲染”；
即返回一个布尔值，决定更新是否进行下去，默认返回true，若返回false则中断更新；
shouldComponentUpdate(nextProp,nextState){ return (nextProp.completed !== this.props.completed) || (nextProp.text !== this.props.text) }
其中nextProps为此次更新传入的props，对于这个组件，影响渲染内容的prop只有completed和text，只要确保这两个prop没有变化，shouldComponentUpdate就可以返回false阻止没必要的更新
但是，上述的比较只是‘浅层比较'，如果类型是基本类型，只要值相同，那么“浅层比较”
也会认为二者相同：
那，如果prop的类型是复杂的对象怎么办？
对于复杂对象，‘浅层比较'的方式只看这两个prop是不是同一个对象的引用，如果不是，哪怕对象中的内容完全一样也会认为是不同的两个prop。那么使用“深层比较”：但对对象的结构是无法预知的，如果递归对每个字段都进行“深层比较”，不光会让代码更加复杂，也可能会造成性能问题。
所以，要想判断前后的对象类型的prop是相同的，就必须要保证prop是指向同一个JavaScript对象：
<Foo styleProp = {{color: "red"}}>
要避免使用上面的传入方式，应为每次渲染都会重新创建{color: "red"}对象，引用地址每次都不同，将导致每次的styleProp都不同。
const footStyle = {color: "red"};//确保这个初始化只执行一次，不要放在render函数中 <Foo styleProp = {footStyle}>
使用‘单例模式'确保传入的styleProp指向同一个对象
如果是函数呢？
<Foo onToggle={() => onToggleTodo(item.id)}/>
应该避免使用上面的函数传递模式，因为这里赋值的是一个匿名函数，而且是在赋值的时候产生的，也就是说每次渲染都会产生一个新的函数，这就是问题所在。
如果要传递的prop很多呢？
恩~~用React-Redux的话，有对shouldComponentUpdate的默认实现。
3. 对多个React组件的性能优化
当一个React组件被装载、更新和卸载时，组件的一序列生命周期函数会被调用。不过，这些生命周期函数是针对一个特定的React组件函数，在一个应用中，从上而下有很多React组件组合起来，它们之间的渲染过程要更加复杂。
同样一个组件的渲染过程也要考虑三个过程：装载阶段、更新阶段、卸载阶段
对于装载阶段，组件无论如何都要彻底渲染一次，从这个React组件往下的所有子组件，都要经历一遍React组件的装载生命
周期，所以并没有多少优化的事情可做。
对于卸载阶段，只有一个生命周期函数componentWillUnmount,这个函数只是清理componentDidMount添加的事件处理监听等收尾工作，所以，也没有什么可优化的空间；
4. React更新阶段的调和（Reconciliation）过程
在组件更新过程，会构建更新Virtual DOM，并将其与之前的Virtual DOM进行比较，从而找出不同之处，使用最少的DOM操作进行更新
调和过程：即React更新中对Virtual DOM找不同的过程，通常对比两个N个节点的树形结构的算法，时间复杂度是O(n*3),如果直接
使用默认对比，节点过多的话，需要操作的数量太多，而React不可能采用这种算法；
React实际采用的算法时间复杂度是O(N)(时间复杂度只是对一个算法最好和最差情况下需要的指令操作数量级的估量)
React的Reconciliation算法并不复杂，首先检查两个树形的根节点的类型是否相同，根据相同或者不同有不同的处理方式：
节点类型不同的情况