从 setState 聊到 React 性能优化

叁歲伎倆 2022-09-09 11:57 171阅读 0赞

# 大厂技术 高级前端 Node进阶    #

点击上方 程序员成长指北，关注公众号

回复1，加入高级Node交流群

作者：风不识途

https://segmentfault.com/a/1190000039776687

## setState的同步和异步    ##

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

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

![3b2b86c4a4a6119343bcf61a3eb4611d.png][]

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

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

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

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

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

![001223aa375238f241779fb1bb2b2e2f.png][]

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

![3e9808f54b259355829fec8862099c6f.png][]

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

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

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

![96ec2ddbfa338f3d8bd072ce3593385e.png][]

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

![8f8b3008be284966445fc35c148752cc.png][]

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

![2f98a0b5ee2c918c4e6b5e278a6dae65.png][]

## setState的合并 ##

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

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

![10d2c0fae2d6fb6bd019f3291ca9ddb9.png][]

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

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

![f03a41180def62fc0e161f87b60b094d.png][]

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

![116cfa193ba82da0d78c303d58a578e7.png][]

## React 更新机制 ##

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

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

![f10ec3eb7aedb65be847690bb63daba9.png][]

*  那么 React 的更新流程呢?

![d85136b6af56ba266466f73256760ac0.png][]

*  React基本流程

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

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

![58b096b6ca6106a4757ea12eb474d96d.png][]

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

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

![3b455efb60aa8a11527f99d7c8ee00b6.png][]

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

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

![0428edfc962207264b4b4f9104de15f7.png][]

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

![a179008a3198d0951a6912a358c2912b.png][]

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

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

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

## React 性能优化 ##

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

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

![b4f7b51ff00e41abd029100a9508510d.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 函数都会被重新调用**

![ae80cee547a10e71d3db225dbee2d5c7.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`函数

![c2d18d1bdf0118946c6709cdfaaecd34.png][] ![2bb104d1005b8a16e8f130e22bace2b7.png][]

### 5.shallowEqual方法 ###

> 这个方法中，调用 `!shallowEqual(oldProps, newProps) || !shallowEqual(oldState, newState)`，这个 `shallowEqual`就是进行**浅层比较：**
> 
> ![0a46dc507a739900ba7a9cefcee0b93c.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>
    })

Node 社群

我组建了一个氛围特别好的 Node.js 社群，里面有很多 Node.js小伙伴，如果你对Node.js学习感兴趣的话（后续有计划也可以），我们可以一起进行Node.js相关的交流、学习、共建。下方加 考拉 好友回复「Node」即可。

![d40d100d6a08f2eb138da61827b0dbd5.png][]

**“分享、点赞、在看” 支持一波** ![64b00b97884832981069cbeb600a2e23.png][]

[3b2b86c4a4a6119343bcf61a3eb4611d.png]: /images/20220829/2d55a3e2e1fa41dcaf04d294ac536f44.png
[c5a0953e8d88c8e010ee77796b11ddb2.png]: /images/20220829/4320380f5e57436d9b79e722fade235d.png
[001223aa375238f241779fb1bb2b2e2f.png]: /images/20220829/41e5116addf24b0e8e028356397d05ef.png
[3e9808f54b259355829fec8862099c6f.png]: /images/20220829/73051e1ca68746d98bb19968dad7ea06.png
[96ec2ddbfa338f3d8bd072ce3593385e.png]: /images/20220829/c1dfb338bc3b4e50877268a18e3012fa.png
[8f8b3008be284966445fc35c148752cc.png]: /images/20220829/478493abc45e4e3db1cac96abebd2413.png
[2f98a0b5ee2c918c4e6b5e278a6dae65.png]: /images/20220829/0b4090908c934afcac077eb16f58e7e4.png
[10d2c0fae2d6fb6bd019f3291ca9ddb9.png]: /images/20220829/288f2f1dbfbf460589374b71dd16ae1d.png
[f03a41180def62fc0e161f87b60b094d.png]: /images/20220829/e67927bbe9db4d2380677c3b4ac90bc1.png
[116cfa193ba82da0d78c303d58a578e7.png]: /images/20220829/91aca7c3a17c487e8325daa4790a275e.png
[f10ec3eb7aedb65be847690bb63daba9.png]: /images/20220829/bdfacb27feac44b0b1ca949aa38c30c1.png
[d85136b6af56ba266466f73256760ac0.png]: /images/20220829/7bdf0256061a418fa22b1ca99d310b3e.png
[58b096b6ca6106a4757ea12eb474d96d.png]: /images/20220829/8585cdecaf3e4a33a4d513d1c1e6e9fa.png
[3b455efb60aa8a11527f99d7c8ee00b6.png]: /images/20220829/540549f314604823b3e9e622517f7ebe.png
[0428edfc962207264b4b4f9104de15f7.png]: /images/20220829/00d9887d41194ad0becc56bd2a96d78e.png
[a179008a3198d0951a6912a358c2912b.png]: /images/20220829/d1f59efb0e9a4a3c8d9addb688c68e36.png
[b2d75ec734c5ed48d1ca7d0fac9a817f.png]: /images/20220829/1c8aaf442c4a4b3ba33a113dcf9c4e0c.png
[41db3f0980b7020cb0db7580f3909ddb.png]: /images/20220829/1e429be95eb14434a9ed6d3c9d285b7a.png
[b4f7b51ff00e41abd029100a9508510d.png]: /images/20220829/d680ef209c894c4ab35aa3459ecb63ea.png
[ae80cee547a10e71d3db225dbee2d5c7.png]: /images/20220829/5f2ff4d2d9bd4020a0e443b70275fea1.png
[c2d18d1bdf0118946c6709cdfaaecd34.png]: https://img-blog.csdnimg.cn/img_convert/c2d18d1bdf0118946c6709cdfaaecd34.png
[2bb104d1005b8a16e8f130e22bace2b7.png]: /images/20220829/e0ee492cb29843c0a94ade15eb606701.png
[0a46dc507a739900ba7a9cefcee0b93c.png]: /images/20220829/dd947601328e45a69776835ecf4335a5.png
[d40d100d6a08f2eb138da61827b0dbd5.png]: /images/20220829/c45a7ac31c4240d8aa04ccb36b1a94ef.png
[64b00b97884832981069cbeb600a2e23.png]: /images/20220829/ebdfc5509194491a93ab27542434b0a3.png