从 setState 聊到 React 性能优化

爱被打了一巴掌 2023-01-13 09:09 114阅读 0赞

##  ##

![125f4259f0c71885111f027eab2ff2e6.png][]作者：风不识途

https://segmentfault.com/a/1190000039776687

## setState的同步和异步    ##

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

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

![9a7ec18784d764cad545617bf721822b.png][]

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

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

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

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

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

![198461f9df653baf0ae213cf20db43d3.png][]

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

![eaa8b13f1646f919555f637cd3c6b47e.png][]

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

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

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

![9223a7f7ac7ede87a5646f1af86b35a8.png][]

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

![3f3bc1166276ec6b956464b2ebab58ee.png][]

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

![5aad453396cee8027fb36097340b7642.png][]

## setState的合并 ##

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

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

![4079007e87a779d52de1f62c5eca9901.png][]

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

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

![8a578b774bc70e4cf89c25ca58b5629d.png][]

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

![16c39a39e564b972b1d604ede05e9b06.png][]

## React 更新机制 ##

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

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

![ddf0f7a16b45e741187b24a99e343f55.png][]

*  那么 React 的更新流程呢?

![57bc7a10cb560d6018663efeb0a4bff1.png][]

*  React基本流程

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

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

![2e000e8402cf2ba776de979a1dcb6e63.png][]

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

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

![ccf930fabb3bc8c0c8b76c53d5e83845.png][]

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

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

![768bee55ed02e6f7fc40e7c18cf7c8f0.png][]

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

![35d0793cfafebc1cf4bf1eb47f106099.png][]

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

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

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

## React 性能优化 ##

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

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

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

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

![185c0e94807ecd86c0d7895309023161.png][] ![ed7cc81ea8b515aca27c40e39277f38e.png][]

### 5.shallowEqual方法 ###

> 这个方法中，调用 `!shallowEqual(oldProps, newProps) || !shallowEqual(oldState, newState)`，这个 `shallowEqual` 就是进行**浅层比较：**
> 
> ![dcecebb730cdc7e29eccb8b5765eef59.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知识点总结脑图 ##

![6f2a6dea9708192ab2c39b9d60623ad0.png][]

## 最后 ##

欢迎关注【前端瓶子君】✿✿ヽ(°▽°)ノ✿

回复「算法」，加入前端算法源码编程群，每日一刷（工作日），每题瓶子君都会很认真的解答哟！

回复「交流」，吹吹水、聊聊技术、吐吐槽！

回复「阅读」，每日刷刷高质量好文！

如果这篇文章对你有帮助，「在看」是最大的支持

》》面试官也在看的算法资料《《

“在看和转发”就是最大的支持

[125f4259f0c71885111f027eab2ff2e6.png]: /images/20221022/ffce370157c546d1a85e37362d9d4540.png
[9a7ec18784d764cad545617bf721822b.png]: /images/20221022/8948fa7388d84d85b9832700e0433df2.png
[a351e7dd104b191aa0178e66d35a31f0.png]: /images/20221022/940e6e7eee75492080b3a64f5bca2961.png
[198461f9df653baf0ae213cf20db43d3.png]: /images/20221022/d91320583b214aae9aaa1a5fff742696.png
[eaa8b13f1646f919555f637cd3c6b47e.png]: /images/20221022/3ec2ba8b088747638c8be3f3bc38b28c.png
[9223a7f7ac7ede87a5646f1af86b35a8.png]: /images/20221022/f1d10da76fa647eb942d13f2151da75f.png
[3f3bc1166276ec6b956464b2ebab58ee.png]: /images/20221022/505fc3adc86a4250b285d938422887db.png
[5aad453396cee8027fb36097340b7642.png]: /images/20221022/50e944460f194adead359d685db483fe.png
[4079007e87a779d52de1f62c5eca9901.png]: /images/20221022/5efe934ccdb243328daf757ed16a4623.png
[8a578b774bc70e4cf89c25ca58b5629d.png]: /images/20221022/4773e0822b8047208eda69998fc575f9.png
[16c39a39e564b972b1d604ede05e9b06.png]: /images/20221022/bd977a5aa57749469f88e2a068c569e7.png
[ddf0f7a16b45e741187b24a99e343f55.png]: /images/20221022/f8d85d0dc0ca4a799525dd66d1dd414b.png
[57bc7a10cb560d6018663efeb0a4bff1.png]: /images/20221022/c5883547b5e341c8bde4ee81002f116a.png
[2e000e8402cf2ba776de979a1dcb6e63.png]: /images/20221022/284aef8a458c457e81480468c6e39189.png
[ccf930fabb3bc8c0c8b76c53d5e83845.png]: /images/20221022/14e8d4e7f5064c5d9ce5e85cecfd9f8e.png
[768bee55ed02e6f7fc40e7c18cf7c8f0.png]: /images/20221022/994da3f79e8a486389b42c64dceb9f4d.png
[35d0793cfafebc1cf4bf1eb47f106099.png]: /images/20221022/d780e05aa13c4030a5e425179398a9e0.png
[ab99b39ce59f8aac0b0740b16b994472.png]: /images/20221022/3e69accc765f49f4a5c513475faf16dc.png
[80d1642b0a4d24592051c22493dce4f4.png]: /images/20221022/05a973608b4e4f6ca0758fd1154357e2.png
[d566c53959d647dff4a330f87ea34952.png]: /images/20221022/66b1778f57214e3183202ad01ec71895.png
[4c0f2a4a0c78f0a1e4991366dc2d936a.png]: /images/20221022/3fb2517024db48ff9d75afbdbf48f03e.png
[185c0e94807ecd86c0d7895309023161.png]: https://img-blog.csdnimg.cn/img_convert/185c0e94807ecd86c0d7895309023161.png
[ed7cc81ea8b515aca27c40e39277f38e.png]: /images/20221022/0886f6c6f3644193a2e444e4dec5f2bd.png
[dcecebb730cdc7e29eccb8b5765eef59.png]: /images/20221022/56d2725a18c2455ba274eb7945e61721.png
[6f2a6dea9708192ab2c39b9d60623ad0.png]: /images/20221022/d8aa9b5d5fda4789b5b81791b3ca7d03.png