React 性能优化技巧总结(7)

而对于传递箭头函数的场景，我们可以代以只唯一声明过一次的函数，从而总可以拿到相同的引用，如下所示：

class App extends React.Component{  
  constructor(props) {  
    this.doSomethingMethod = this.doSomethingMethod.bind(this);      
  }  
  doSomethingMethod () { // do something}  
    
  render() {  
    return <Bar onSomething={this.doSomethingMethod} />  
  }  
}  

Tip #5：控制更新

还是那句话，任何方法总有其适用范围。

第三条建议虽然处理了不必要的更新问题，但我们也不总能使用它。

而第四条，在某些情况下我们并不能拆分对象，如果我们传递了某种嵌套确实复杂的数据结构，那我们也很难将其拆分开来。

不仅如此，我们也不总能传递只声明了一次的函数。比如在我们的例子中，如果 App 是个函数式组件，恐怕就不能做到这一点了（在 class 组件中，我们可以用 bind 或者类内箭头函数来保证 this 的指向及唯一声明，而在函数式组件中则可能会有些问题）。

幸运的是， 无论是 class 组件还是函数式组件，我们都有办法控制浅比较的逻辑 。

在 class 组件中，我们可以使用生命周期钩子 shouldComponentUpdate(prevProps, prevState)来返回一个布尔值，当返回值为 true 时才会触发 render。

而如果我们使用 React.memo，我们可以传递一个比较函数作为第二个参数。

注意！ React.memo 的第二参数（比较函数）和 shouldComponentUpdate 的逻辑是相反的，只有当返回值为 false 的时候才会触发 render。 参考文档 。

const Bar = React.memo(  
  function Bar({ name: { first, last } }) {  
    console.log("update");  
    return (  
      <h1>  
        {first} {last}  
      </h1>  
    );  
  },  
  (prevProps, newProps) =>  
    prevProps.name.first === newProps.name.first &&  
    prevProps.name.last === newProps.name.last  
);  

尽管这条建议是可行的，但我们仍要注意 比较函数的性能开销 。如果 props 对象过深，反而会消耗不少的性能。

上述场景仍不够全面，但多少能带来一些启发性思考。当然在性能方面，我们还有许多其他的问题需要考虑，但遵守上述的准则仍能带来相当不错的性能提升。

【编辑推荐】

1. AWS 开源 SageMaker，帮助开发人员优化机器学习模型
2. 你与数据科学家只差这 26 条 Python 技巧
3. 在未来和AI争夺工作的16个实用技巧
4. 互联网公司口中的架构优化、战略调整？其实是裁员不同姿势
5. GitHub 蝉联趋势榜数日 5k+ star 的 Nginx 性能优化整理

（编辑：ASP站长网）