之前画了一张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。

因为尽人皆知的{} !== {}的状况，假如能经由过程简朴推断来决议是不是能够挑选运用本来的对象，那末就能够经由过程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的斲丧比起来哪一个更划算。

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