之前画了一张redux的流程图，可以看看右下角的部分，可以看出来怎么进行优化。

在reducer里面，尽量减少数据的变动

不要做多余、无意义的事

也就是能不改变就不改变。比如不要做下面这种无谓的事情：

function reducer(state,action){
  // ....一大堆逻辑代码
  return {
   ...state
  }
}

这个代码虽然在selector中，也可以通过areStatePropsEqual来判断计算后的state是否发生了改变。

但是如果直接return state;就可以直接被areStatesEqual拦截，避免多余的计算和对比。

要做多余的检查

同样，state内部数据，如果数据相同，尽量使用原数据。只针对复杂数据类型(Object,Array)。
比如：

function reducer(state,action) {
  let mayNotChange = state.mayNotChange; // mayNotChange为Array或Object
  let newState = {...mayNotChange};
  // ...一大堆逻辑
  return {
    ...state,mayNotChange: changed ? newState : mayNotChange // 没有发生改变的话，就用原来的对象
  }
}

很多时候，一般习惯于通过计算，然后直接把生成的newState赋值给mayNotChange。

由于众所周知的{} !== {}的情况，如果能通过@H_404_40@简单判断来决定是否可以选择使用原来的对象，那么就可以通过areStatePropsEqual来进行判断，同样可以避免不必要的计算，更可以避免不必要的渲染。

注: 所说的选择使用原来的对象，是确定数据没有发生改变的时候，使用原对象。并不是说当发生改变的时候，也在原来的对象上面修改最好。在不考虑自定义areStatesEqual和areStatePropsEqual的情况下，如果只在原对象上面进行修改，可能会造成对比的时候，前后两种结果相同，可能造成无法重新渲染的情况

优化equal的四个方法

在connect的option中，有四个对比的方法

1. areStatesEqual(默认为===)，用来判断redux store返回的state是否和之前的相同

2. areOwnPropsEqual(默认为shallowEqual)，用来判断父组件传入的props是否和之前的相同

3. areStatePropsEqual(默认为shallowEqual)，用来判断mapStateToProps的结果是否和之前的相同

4. areMergedPropsEqual(默认为shallowEqual)，用来判断最后merge合并的最终结果是否和之前的相同

可以通过自己的需求对着四个方法进行优化。

比如一个redux的state是这个样子：

state = {
    pageA: {...},pageB: {...},number: 2
  }

而在pageA里面只需要pageA和number，那么就可以通过areStatesEqual来进行对比:

function areStatesEqual(prev,current){
  return prev.number === current.number && isEqual(prev.pageA,current.pageA);
}

或者针对复杂结构数据的情况，进行特殊处理，比如深度对比

function areStatePropsEqual(prev,current){
  return deepEqual(prev,current);
}

这些优化都可以减少不必要的计算和重渲染。

shouldComponentUpdate

多余提一句，在使用shouldComponentUpdate的时候，要谨慎使用。这个方法就是利用shouldComponentUpdate的消耗来换取render的消耗。

当某些小的、调用的次数少的component，就没有必要添加shouldComponentUpdate检查。

当组件够大，够复杂，可以考虑使用这个方法来减少re-render的消耗。当然，还是需要考虑用这个方法的消耗和diff&render的消耗比起来哪个更划算。

先想到这么多，等想到了其他的再添加上来。