React-性能优化(一)

刺骨的言语ヽ痛彻心扉 2022-11-15 14:15 284阅读 0赞

### 文章目录 ###

*  一、使用React.Memo来缓存组件
 *  二、使用useMemo缓存大量的计算
 *  三、避免使用内联对象
 *  四、避免使用匿名函数
 *  五、延迟加载不是立即需要的组件
 *  六、调整CSS而不是强制组件加载和卸载
 *  七、使用React.Fragment避免添加额外的DOM
 *  八、基于 shouldComponentUpdate 优化
 *  九、基于 PureComponent + immutable.js 优化

> React 好像就意味着组件化、高性能，我们永远只需要关心数据整体，两次数据之间的 UI 如何变化，则完全交给 Virtual Dom 的 Diff 算法去做。以至于我们很随意的去操纵数据，基本优化 shouldComponentUpdate 也懒得去写，毕竟不写也能正确渲染。但随着应用体积越来越大，会发现页面好像有点变慢了，特别是组件嵌套比较多，数据结构比较复杂的情况下，随便改变一个表单项，或者对列表做一个筛选都要耗时 100ms 以上，这个时候我们就需要优化了！

# 一、使用React.Memo来缓存组件 #

提升应用程序性能的一种方法是实现memoization。Memoization是一种优化技术，主要通过存储昂贵的函数调用的结果，并在再次发生相同的输入时返回缓存的结果，以此来加速程序。父组件的每次状态更新，都会导致子组件重新渲染，即使传入子组件的状态没有变化，为了减少重复渲染，我们可以使用React.memo来缓存组件，这样只有当传入组件的状态值发生变化时才会重新渲染。如果传入相同的值，则返回缓存的组件。示例如下：

export default React.memo((props) => {
      return (
        <div>{props.value}</div>  
      )
    });

import React from "react";
    
    function Child({seconds}){
        console.log('I am rendering');
        return (
            <div>I am update every {seconds} seconds</div>
        )
    };
    
    function areEqual(prevProps, nextProps) {
        if(prevProps.seconds===nextProps.seconds){
            return true
        }else {
            return false
        }
    
    }
    export default React.memo(Child,areEqual)

# 二、使用useMemo缓存大量的计算 #

有时渲染是不可避免的，但如果您的组件是一个功能组件，重新渲染会导致每次都调用大型计算函数，这是非常消耗性能的，我们可以使用新的useMemo钩子来“记忆”这个计算函数的计算结果。这样只有传入的参数发生变化后，该计算函数才会重新调用计算新的结果。通过这种方式，您可以使用从先前渲染计算的结果来挽救昂贵的计算耗时。总体目标是减少JavaScript在呈现组件期间必须执行的工作量，以便主线程被阻塞的时间更短。

// 避免这样做
    function Component(props) {
      const someProp = heavyCalculation(props.item);
      return <AnotherComponent someProp={someProp} /> 
    }
      
    // 只有 `props.item` 改变时someProp的值才会被重新计算
    function Component(props) {
      const someProp = useMemo(() => heavyCalculation(props.item), [props.item]);
      return <AnotherComponent someProp={someProp} /> 
    }

# 三、避免使用内联对象 #

使用内联对象时，react会在每次渲染时重新创建对此对象的引用，这会导致接收此对象的组件将其视为不同的对象。

该组件对于prop的浅层比较始终返回false,导致组件一直重新渲染。

// Don't do this!
    function Component(props) {
      const aProp = { someProp: 'someValue' }
      return <AnotherComponent style={
       { margin: 0 }} aProp={aProp} />  
    }
    
    // Do this instead :)
    const styles = { margin: 0 };
    function Component(props) {
      const aProp = { someProp: 'someValue' }
      return <AnotherComponent style={styles} {...aProp} />  
    }

# 四、避免使用匿名函数 #

匿名函数在每次渲染上都有不同的引用。这类似于上面描述的内联对象。

// 避免这样做
    function Component(props) {
      return <AnotherComponent onChange={() => props.callback(props.id)} />  
    }

// 优化方法
    class Component extends React.Component {
      handleChange = () => {
       this.props.callback(this.props.id) 
      }
      render() {
        return <AnotherComponent onChange={this.handleChange} />
      }
    }

# 五、延迟加载不是立即需要的组件 #

// 延迟加载不是立即需要的组件
    const MUITooltip = React.lazy(() => import('@material-ui/core/Tooltip'));
    function Tooltip({ children, title }) {
      return (
        <React.Suspense fallback={children}>
          <MUITooltip title={title}>
            {children}
          </MUITooltip>
        </React.Suspense>
      );
    }
    
    function Component(props) {
      return (
        <Tooltip title={props.title}>
          <AnotherComponent />
        </Tooltip>
      )
    }

# 六、调整CSS而不是强制组件加载和卸载 #

渲染成本很高，尤其是在需要更改DOM时。每当你有某种手风琴或标签功能，例如想要一次只能看到一个项目时，你可能想要卸载不可见的组件，并在它变得可见时将其重新加载。如果加载/卸载的组件“很重”，则此操作可能非常消耗性能并可能导致延迟。在这些情况下，最好通过CSS隐藏它，同时将内容保存到DOM。

将不透明度调整为0对浏览器的成本消耗几乎为0（因为它不会导致重排）`opacity：0`，并且应尽可能优先于更该visibility 和 display。有时在保持组件加载的同时通过CSS隐藏可能是有益的，而不是通过卸载来隐藏。对于具有显著的加载/卸载时序的重型组件而言，这是有效的性能优化手段。

# 七、使用React.Fragment避免添加额外的DOM #

function Component() {
            return (
                <div>
                    <h1>Hello world!</h1>
                    <h1>Hello there!</h1>
                    <h1>Hello there again!</h1>
                </div>
            )
    }

改为

function Component() {
            return (
                <React.Fragment>
                    <h1>Hello world!</h1>
                    <h1>Hello there!</h1>
                    <h1>Hello there again!</h1>
                </React.Fragment>
            )
    }

# 八、基于 shouldComponentUpdate 优化 #

render 方法由于伴随着对虚拟 DOM 的构建和对比，这其中的过程非常耗时，而在 React 中，很多时候会不经意的调用 ‘re-render’，为了避免不必要的 render 带来的性能消耗，因此出现了 shuouldComponentUpdate 这个生命周期。

shouldComponentUpdate 是 React 更新阶段的一个生命周期，React 组件会根据 shouldComponentUpdate 这个生命周期的返回值，来决定是否执行该方法之后的生命周期，进而决定是否对组件进行 ‘re-render’（重渲染）

shouldComponentUpdate(nextProps, nextState) {
        // 判断 text 属性在父组件更新前后有没有发生变化，若没有发生变化，则返回 false
        if(nextProps.textB === this.props.textB) {
          return false
        }
        // 只有在 text 属性值确实发生变化时，才允许更新进行下去
        return true
      }

# 九、基于 PureComponent + immutable.js 优化 #

pureComponent 是在 shouldComponentUpdate 衍生出来的玩法。它的功能也是避免 re-render。

PureComponent 与 Component 的区别点，就在于它内置了对 shouldComponentUpdate 的实现：PureComponent 将会在 shouldComponentUpdate 中对组件更新前后的 props 和 state 进行浅比较，并根据浅比较的结果，决定是否需要继续更新流程。

**浅比较**将针对值类型数据对比其值是否相等，而针对数组、对象等引用类型的数据则对比其引用是否相等。

import React from "react";
    export default class ChildB extends React.PureComponent {
      render() {
        console.log("ChildB 的render方法执行了");
        return (
          <div className="childB">
            子组件B的内容：
            {this.props.text}
          </div>
        );
      }
    }

基于**浅比较**的判断逻辑就会带来这样两个风险：

*  若数据内容没变，但是引用变了，那么浅比较仍然会认为“数据发生了变化”，进而触发一次不必要的更新，导致过度渲染；
 *  若数据内容变了，但是引用没变，那么浅比较则会认为“数据没有发生变化”，进而阻断一次更新，导致不渲染。

参考  
[https://juejin.cn/post/6844903924302888973][https_juejin.cn_post_6844903924302888973]  
[https://blog.csdn.net/weixin\_46107920/article/details/112008226][https_blog.csdn.net_weixin_46107920_article_details_112008226]

[本文链接https://blog.csdn.net/qq\_39903567/article/details/115383336][https_blog.csdn.net_qq_39903567_article_details_115383336]

[https_juejin.cn_post_6844903924302888973]: https://juejin.cn/post/6844903924302888973
[https_blog.csdn.net_weixin_46107920_article_details_112008226]: https://blog.csdn.net/weixin_46107920/article/details/112008226
[https_blog.csdn.net_qq_39903567_article_details_115383336]: https://blog.csdn.net/qq_39903567/article/details/115383336