从 setState 聊到 React 性能优化

痛定思痛。 2023-01-16 04:52 182阅读 0赞

##  ##

作者：风不识途

https://segmentfault.com/a/1190000039776687

## setState的同步和异步    ##

### 1.为什么使用setState ###

*  开发中我们并**不能直接通过修改** `state` 的值来**让界面发生更新**：
 *   *  因为我们修改了 `state` 之后, 希望 `React` 根据最新的 `Stete` 来重新渲染界面, 但是这种方式的修改 `React` 并不知道数据发生了变化
     *  `React` 并没有实现类似于 `Vue2` 中的 `Object.defineProperty` 或者 `Vue3` 中的`Proxy`的方式来监听数据的变化
     *  我们必须通过 `setState` 来告知 `React` 数据已经发生了变化
 *  疑惑: 在组件中并没有实现 `steState` 方法, 为什么可以调用呢?
 *   *  原因很简单: `setState`方法是从 `Component` 中**继承过来的**

![d16498332be98c4f67a1c8598254094c.png][]

### 2.setState异步更新 ###

**setState是异步更新的** ![2ec549b7a940a65e5459eddc7a12d943.png][]

*  为什么`setState`设计为异步呢?
 *   *  `setState` 设计为异步其实之前在 `GitHub` 上也有很多的讨论
     *  React核心成员（Redux的作者）Dan Abramov也有对应的回复, 有兴趣的可以看一下
 *  简单的总结: `setState`设计为异步, 可以**显著的提高性能**
 *   *  如果每次调用 `setState` 都进行一次更新, 那么意味着 `render` 函数会被频繁的调用界面重新渲染, 这样的效率是很低的
     *  **最好的方法是获取到多个更新, 之后进行批量更新**
 *  如果同步更新了 `state`, 但还没有执行 `render` 函数, 那么`state`和`props`不能保持同步
 *   *  `state`和`props`不能保持一致性, 会在开发中产生很多的问题

### 3.如何获取异步的结果 ###

*  如何获取 `setState` 异步更新`state`后的值?
 *  方式一: `setState`的回调
 *   *  `setState`接收两个参数: 第二个参数是回调函数(`callback`), 这个回调函数会在`state`**更新后执行**

![5a21ac855806d0e53e10d9d280ec5a1e.png][]

*  方式二: `componentDidUpdate`生命周期函数

![d8226709d4e695216fd10ccd6538f0e1.png][]

### 3.setState一定是异步的吗? ###

>  *  其实可以分成两种情况
>  *  在组件生命周期或React合成事件中, `setState`是异步的
>  *  在`setTimeou`或原生DOM事件中, `setState`是同步的

*  验证一: 在`setTimeout`中的更新 —> 同步更新

![38e16441d78d8a37896fcd78d57b28e6.png][]

*  验证二: 在原生`DOM`事件 —> 同步更新

![aeb3088da8da164bb2cb7f27322eee31.png][]

### 4.源码分析 ###

![5e9db563b974dc0745ccf4928cf45af8.png][]

## setState的合并 ##

### 1.数据的合并 ###

*  通过`setState`去修改`message`，是**不会对其他** `state` 中的数据产生影响的
 *   *  源码中其实是有对 **原对象** 和 **新对象** 进行合并的

![753844952a97de0149aea0ce2db9179c.png][]

### 2.多个state的合并 ###

*  当我们的**多次调用**了 `setState`, **只会生效最后一次**`state`

![6b6c2f127d31f5ea43fe1377f55ce3ef.png][]

*  `setState`合并时进行累加: **给setState传递函数**, 使用前一次`state`中的值

![7242bd0e747bdc19797cd8dc040f2b05.png][]

## React 更新机制 ##

### 1.React 更新机制 ###

*  我们在前面已经学习`React`的渲染流程：

![949fec06294d3df5c5ec63a53c09f2ee.png][]

*  那么 React 的更新流程呢?

![327e81fe31842a671ad98eadc259a6f6.png][]

*  React基本流程

### 2.React 更新流程 ###

*  `React`在 `props` 或 `state` 发生改变时，会调用 `React` 的 `render` 方法，会创建一颗不同的树
 *  `React`需要基于这两颗不同的树之间的差别来判断如何有效的更新`UI`：
 *  如果一棵树参考另外一棵树进行完全比较更新, 那么即使是最先进的算法, 该算法的复杂程度为 O(n 3 ^3 3)，其中 n 是树中元素的数量
 *   *  如果在 `React` 中使用了该算法, 那么展示 `1000` 个元素所需要执行的计算量将在`十亿`的量级范围
 *  这个开销太过昂贵了, React的更新性能会变得非常低效
 *  于是，`React`**对这个算法进行了优化**，将其优化成了`O(n)`，如何优化的呢？
 *   *  **同层节点之间相互比较**，**不会跨节点比较**
     *  **不同类型的节点，产生不同的树结构**
     *  **开发中，可以通过key来指定哪些节点在不同的渲染下保持稳定**

![0196c32bbe181a5b23d9292c8738d723.png][]

#### 情况一: 对比不同类型的元素 ####

*  当**节点为不同的元素**，**React会拆卸原有的树**，**并且建立起新的树**：
 *   *  当一个元素从 `<a>` 变成 `<img>`，从 `<Article>` 变成 `<Comment>`，或从 `<button>` 变成 `<div>` **都会触发一个完整的重建流程**
     *  当卸载一棵树时，对应的`DOM`节点也会被销毁，组件实例将执行 `componentWillUnmount()` 方法
     *  当建立一棵新的树时，对应的 `DOM` 节点会被创建以及插入到 `DOM` 中，组件实例将执行 `componentWillMount()` 方法，紧接着 `componentDidMount()` 方法
 *  比如下面的代码更改：
 *   *  **React 会销毁 Counter 组件并且重新装载一个新的组件，而不会对Counter进行复用**

![931b70081c436157eac76c2409fb0ec0.png][]

#### 情况二: 对比同一类型的元素 ####

*  **当比对两个相同类型的 React 元素时，React 会保留 DOM 节点**，**仅对比更新有改变的属性**
 *  比如下面的代码更改：
 *   *  通过比对这两个元素，`React`知道只需要修改 `DOM` 元素上的 `className` 属性

![3c2613156b3fa42de797e8ca814d3c59.png][]

*  比如下面的代码更改：
 *   *  当更新 `style` 属性时，`React` 仅更新有所改变的属性。
     *  通过比对这两个元素，`React` 知道只需要修改 `DOM` 元素上的 `color` 样式，无需修改 `fontWeight`

![efb08a8f67252493b8adc9404ef080ad.png][]

*  如果是同类型的组件元素：
 *   *  组件会保持不变，`React`会更新该组件的`props`，并且调用`componentWillReceiveProps()` 和 `componentWillUpdate()` 方法
     *  下一步，调用 `render()` 方法，`diff` 算法将在之前的结果以及新的结果中进行递归

#### 情况三: 对子节点进行递归 ####

*  在默认条件下，当递归 `DOM` 节点的子元素时，`React` 会同时遍历两个子元素的列表；当产生差异时，生成一个 `mutation`
 *   *  我们来看一下在最后插入一条数据的情况：????
        
        ![3c77bd3b43eeef60cb8c983849ba2acd.png][]
     *  **前面两个比较是完全相同的，所以不会产生mutation**
     *  **最后一个比较，产生一个mutation，将其插入到新的DOM树中即可**
 *  但是如果我们是在前面插入一条数据：
    
    ![df348b037462abb59ef2531606c847bf.png][]
 *   *  **React会对每一个子元素产生一个mutation，而不是保持 `<li>星际穿越</li>` 和 `<li>盗梦空间</li>`的不变**
     *  **这种低效的比较方式会带来一定的性能问题**

## React 性能优化 ##

### 1.key的优化 ###

*  我们在前面遍历列表时，总是会提示一个警告，让我们加入一个`key`属性：

![d0a4fcbf48eafad28e47a93effb53fc4.png][]

*  方式一：在最后位置插入数据
 *   *  这种情况，有无`key`意义并不大
 *  方式二：在前面插入数据
 *   *  这种做法，在没有 `key` 的情况下，所有的`<li>`都需要进行修改
 *  在下面案例: 当子元素 (这里的`li`元素) 拥有 `key` 时
 *   *  `React` 使用 `key` **来匹配原有树上的子元素以及最新树上的子元素**：
     *  下面这种场景下, key为 111 和 222 的元素**仅仅进行位移**，不**需要进行任何的修改**
     *  将`key`为 `333` 的元素插入到最前面的位置即可

> `key`的注意事项：
> 
>  *  `key`应该是唯一的
>  *  `key`不要使用随机数（随机数在下一次render时，会重新生成一个数字）
>  *  使用`index`作为`key`，对性能是没有优化的

### 2.render函数被调用 ###

*  我们使用之前的一个嵌套案例：
 *   *  在App中，我们增加了一个计数器的代码
 *  当点击 `+1` 时，会重新调用 `App` 的 `render` 函数
 *   *  **而当 App 的 render函数被调用时，所有的子组件的 render 函数都会被重新调用**

![6ae434a8115f31917138766b1eb4cd36.png][]

*  **那么，我们可以思考一下，在以后的开发中，我们只要是修改 了App中的数据，所有的子组件都需要重新`render`，进行 `diff` 算法，性能必然是很低的：**
 *   *  事实上，很多的组件没有必须要重新`render`
     *  **它们调用 render 应该有一个前提**，就是**依赖的数据**(state、 props) **发生改变时**，**再调用自己的`render`方法**
 *  如何来控制 `render` 方法是否被调用呢？
 *   *  通过`shouldComponentUpdate`方法即可

### 3.shouldComponentUpdate ###

> `React`给我们提供了一个生命周期方法 `shouldComponentUpdate`（很多时候，我们简称为`SCU`），这个方法接受参数，并且需要有返回值；主要作用是：\*\*控制当前类组件对象是否调用`render`\*\*方法

*  该方法有两个参数:
 *  参数一: `nextProps`修改之后, 最新的 `porps`属性
 *  参数二: `nextState` 修改之后, 最新的 `state` 属性
 *  该方法**返回值**是一个 booolan 类型
 *  返回值为`true`, 那么就需要调用 `render` 方法
 *  返回值为`false`, 那么不需要调用 `render` 方法
 *  比如我们在App中增加一个`message`属性:
 *  `JSX`中并**没有依赖**这个`message`, 那么**它的改变不应该引起重新渲染**
 *  但是通过`setState`修改 `state` 中的值, 所以最后 `render` 方法还是被重新调用了

// 决定当前类组件对象是否调用render方法
    // 参数一: 最新的props
    // 参数二: 最新的state
    shouldComponentUpdate(nextProps, nextState) {
      // 默认是: return true
      // 不需要在页面上渲染则不调用render函数
      return false
    }

### 4.PureComponent ###

*  如果所有的类, 我们都需要手动来实现 `shouldComponentUpdate`, 那么会给我们开发者增加非常多的工作量
 *   *  我们设想一下在`shouldComponentUpdate`中的**各种判断目的是什么**?
     *  `props` 或者 `state` 中数据是否发生了改变, 来决定`shouldComponentUpdate`返回 `true` 或 `false`
 *  事实上 `React` 已经考虑到了这一点, 所以 `React` 已经默认帮我们实现好了, 如何实现呢？
 *   *  将 class 继承自 PureComponent
     *  内部会进行**浅层对比**最新的 `state` 和 `porps` , 如果组件内没有依赖 `porps`或`state` 将不会调用`render`
     *  解决的问题: 比如某些子组件没有依赖父组件的`state`或`props`, 但却调用了`render`函数

![8f1ed599cade0f18a11796992a6fe134.png][] ![399b78e0c5d5b74b8c68c290b344e6fc.png][]

### 5.shallowEqual方法 ###

> 这个方法中，调用 `!shallowEqual(oldProps, newProps) || !shallowEqual(oldState, newState)`，这个 `shallowEqual` 就是进行**浅层比较：**
> 
> ![f4c3b1c9acb35588d79f2f6b81dd4750.png][]

### 6.高阶组件memo ###

*  **函数式组件如何解决**`render`: 在没有依赖 `state` 或 `props` 但却重新渲染 `render` 问题
 *   *  我们需要使用一个高阶组件`memo`：
     *  我们将之前的Header、Banner、ProductList都通过 memo 函数进行一层包裹
     *  Footer没有使用 memo 函数进行包裹；
     *  最终的效果是，当`counter`发生改变时，Header、Banner、ProductList的函数不会重新执行，而 Footer 的函数会被重新执行

import React, { PureComponent, memo } from  react 
    
    // MemoHeader: 没有依赖props,不会被重新调用render渲染
    const MemoHeader = memo(function Header() {
      console.log( Header被调用 )
      return <h2>我是Header组件</h2>
    })

## React知识点总结脑图 ##

![15e22db069b76a94cd4d9a414390490b.png][]

[d16498332be98c4f67a1c8598254094c.png]: /images/20221022/b11d363c36cb46929fb356d8a4b7e28c.png
[2ec549b7a940a65e5459eddc7a12d943.png]: /images/20221022/7e1df6229abd4d51939578e51ec4c4fd.png
[5a21ac855806d0e53e10d9d280ec5a1e.png]: /images/20221022/eb064fab5f4e452b94a1cf96640fb92c.png
[d8226709d4e695216fd10ccd6538f0e1.png]: /images/20221022/aa20ac61bd0d44a5b0898cddd1c4d385.png
[38e16441d78d8a37896fcd78d57b28e6.png]: /images/20221022/c1bdca00e12c40769badb47774e6dede.png
[aeb3088da8da164bb2cb7f27322eee31.png]: /images/20221022/005800eebff842079e0a185840714e1b.png
[5e9db563b974dc0745ccf4928cf45af8.png]: /images/20221022/971b10e40aa14517b04535ea6979fada.png
[753844952a97de0149aea0ce2db9179c.png]: /images/20221022/b20c0f401925482da6fa66f97715fdc1.png
[6b6c2f127d31f5ea43fe1377f55ce3ef.png]: /images/20221022/5cef08c0508f44c4a2cf299d37af7b06.png
[7242bd0e747bdc19797cd8dc040f2b05.png]: /images/20221022/23016b5bf7364a60bf085f0511a8ccfe.png
[949fec06294d3df5c5ec63a53c09f2ee.png]: /images/20221022/96d0432a791c45dab6fce164f2fee57a.png
[327e81fe31842a671ad98eadc259a6f6.png]: /images/20221022/ecae048816de47dc9ecc61f51bb2a7cc.png
[0196c32bbe181a5b23d9292c8738d723.png]: /images/20221022/573a915b5bbd42efab07a29a071dda4d.png
[931b70081c436157eac76c2409fb0ec0.png]: /images/20221022/4b3e402b81dc4b288bd510e7a3f6b58d.png
[3c2613156b3fa42de797e8ca814d3c59.png]: /images/20221022/94d10a65c41a4c1d98d62d88cacfebb6.png
[efb08a8f67252493b8adc9404ef080ad.png]: /images/20221022/202a6311dbb24391a08f7e773816d6a5.png
[3c77bd3b43eeef60cb8c983849ba2acd.png]: /images/20221022/88df8e9de2b44c79ab986b47a88a2a27.png
[df348b037462abb59ef2531606c847bf.png]: /images/20221022/be0fefea5532453f8da61d2d9f833cc3.png
[d0a4fcbf48eafad28e47a93effb53fc4.png]: /images/20221022/f9c0291c31a94c7ab1ce24236e3edce3.png
[6ae434a8115f31917138766b1eb4cd36.png]: /images/20221022/9a361aa8aed848769a251e080936379a.png
[8f1ed599cade0f18a11796992a6fe134.png]: https://img-blog.csdnimg.cn/img_convert/8f1ed599cade0f18a11796992a6fe134.png
[399b78e0c5d5b74b8c68c290b344e6fc.png]: /images/20221022/c98ffc9793f14519a24579745bb35895.png
[f4c3b1c9acb35588d79f2f6b81dd4750.png]: /images/20221022/1368db0501d848f19a4e46ed77c96849.png
[15e22db069b76a94cd4d9a414390490b.png]: /images/20221022/d2396330aefe4e05b126da5791023b4b.png