【React】从 setState 聊到 React 性能优化

╰半夏微凉° 2022-09-04 03:58 201阅读 0赞

![57211e258731123c26aca87da16b6130.png][]

## setState的同步和异步 ##

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

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

![d2fe50b172fb27f82f337b0917f80516.png][]

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

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

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

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

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

![69a0d46ad4b63b22acb4cf22aa1acf93.png][]

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

![047a95244c6052986906963155606a27.png][]

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

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

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

![7b308172c0b358b498eb4fb490a892f1.png][]

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

![06d25e04544ba40531dedc4c5762a668.png][]

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

![db5881a39e16b183657539fe8492bdab.png][]

## setState的合并 ##

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

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

![7a28c14ec258afd8d074581373d347f1.png][]

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

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

![1fc6c0c614a919ee7b1a2dc70dc657db.png][]

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

![23e683cac920d146db8454486d2d6b1f.png][]

## React 更新机制 ##

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

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

![3f70563d796ca469913c7ed7ccf25d05.png][]

*  那么 React 的更新流程呢?

![a03a33e45a181d0778e1326a641f793b.png][]

*  React基本流程

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

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

![eca2d2a650e1edda13a2e7688f268bc3.png][]

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

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

![39de798d85b22028803897b5f01e72c9.png][]

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

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

![18f9be30bf7d4ecf516b33b4ab88b6cd.png][]

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

![2854e97aed05c19003a587ac92ef3dc0.png][]

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

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

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

## React 性能优化 ##

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

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

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

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

![6ff7e0c9a4983721d80b26c4bf9bc16e.png][] ![45299357c55b328c597961d91c8fd13d.png][]

### 5.shallowEqual方法 ###

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

*  本文作者：风不识途
 *  本文链接：https://segmentfault.com/a/1190000039776687

![f326ebd56dff9e65903c28f1347a3c98.gif][]

[1. JavaScript 重温系列（22篇全）][1. JavaScript _22]

[2. ECMAScript 重温系列（10篇全）][2. ECMAScript _10]

[3. JavaScript设计模式 重温系列（9篇全）][3. JavaScript_ _9]

4. [正则 / 框架 / 算法等 重温系列（16篇全）][_ _ _ _ _16]

5. [Webpack4 入门（上）][Webpack4]|| [Webpack4 入门（下）][Webpack4 1]

6. [MobX 入门（上）][MobX] || [MobX 入门（下）][MobX 1]

7. 120[\+篇原创系列汇总][Link 1]

![d16195c8e8f57bf4fa29171baa16911d.gif][]

回复“**加群**”与大佬们一起交流学习~

点击“**阅读原文**”查看 120+ 篇原创文章

[57211e258731123c26aca87da16b6130.png]: /images/20220829/20c7d78c342e4308845b75b62e31e26f.png
[d2fe50b172fb27f82f337b0917f80516.png]: /images/20220829/363e2ec5fe104b1796948962700f4dd3.png
[339b6dd2219ff21a7f5a5f44a1391fd2.png]: /images/20220829/ffabaf9d8aad45b6adece78998f2cc03.png
[69a0d46ad4b63b22acb4cf22aa1acf93.png]: /images/20220829/70b22df8e0384b4e8be8a4ec3f8530c7.png
[047a95244c6052986906963155606a27.png]: /images/20220829/0412446d692a4058b115a3578ea8e761.png
[7b308172c0b358b498eb4fb490a892f1.png]: /images/20220829/eb8c69815190457fbecf33bc85b60a38.png
[06d25e04544ba40531dedc4c5762a668.png]: /images/20220829/8cc584c9eed34938b77f4ac8693433b7.png
[db5881a39e16b183657539fe8492bdab.png]: /images/20220829/ab0bb0f8b17b4d8a8b705ba61057ad86.png
[7a28c14ec258afd8d074581373d347f1.png]: /images/20220829/0fe17876be4445bfb633dfb211ea1bf7.png
[1fc6c0c614a919ee7b1a2dc70dc657db.png]: /images/20220829/983437147d32438795e4546eb6f10f96.png
[23e683cac920d146db8454486d2d6b1f.png]: /images/20220829/44ab9b40ff6244ce90a638378e390d2c.png
[3f70563d796ca469913c7ed7ccf25d05.png]: /images/20220829/e2fe7f0f9d23423fa714c12dd4b7c1fb.png
[a03a33e45a181d0778e1326a641f793b.png]: /images/20220829/201a95e35ee544c2af6e5e09cb7335b0.png
[eca2d2a650e1edda13a2e7688f268bc3.png]: /images/20220829/0177c56b20894044a3f94d3cb4c055b8.png
[39de798d85b22028803897b5f01e72c9.png]: /images/20220829/4882e4b101a9446aadd9973a0c12b59d.png
[18f9be30bf7d4ecf516b33b4ab88b6cd.png]: /images/20220829/9434fc1aa2524939893601078c039ec7.png
[2854e97aed05c19003a587ac92ef3dc0.png]: /images/20220829/26e4bd398a8840caa85805e946ae55f1.png
[ccb1f4e7631790b7d9f40c64b853bb1f.png]: /images/20220829/1fcb16e132424daf9ac2bc1a1ebb1d7b.png
[fb733e5fe65b88a0feb91eff3aad3388.png]: /images/20220829/bab7314f9aa94338ae5c94d3e79eaafa.png
[76e2d9375919888887c0940f47af338f.png]: /images/20220829/8e405da8024949fe830fafe449f5c45f.png
[4712c8c14347e01662e4b057b8b8334c.png]: /images/20220829/207837a8aa0c4c8eaf874e2d08c32bb8.png
[6ff7e0c9a4983721d80b26c4bf9bc16e.png]: https://img-blog.csdnimg.cn/img_convert/6ff7e0c9a4983721d80b26c4bf9bc16e.png
[45299357c55b328c597961d91c8fd13d.png]: /images/20220829/5fb8478dc1514698b19d246ede75218f.png
[3d87ad20d6760f6337f085421a49afa3.png]: /images/20220829/89782a9ad713466392554c95d2b775e7.png
[f326ebd56dff9e65903c28f1347a3c98.gif]: /images/20220829/e03fc2c3208c498eb2387ebd1562d64f.png
[1. JavaScript _22]: http://mp.weixin.qq.com/s?__biz=MjM5MDc4MzgxNA%3D%3D&chksm=b1c224ea86b5adfc10c3aa1841be3879b9360d671e98cc73391c2490246f1348857b9821d32c&idx=1&mid=2458453187&scene=21&sn=a69b4d7d991867a07a933f86e66b9f55#wechat_redirect
[2. ECMAScript _10]: http://mp.weixin.qq.com/s?__biz=MjM5MDc4MzgxNA%3D%3D&chksm=b1c224e086b5adf6dad41a0d36b77a9bfb4bc9f0d29a816266b3e28c892e54274967dbce380b&idx=1&mid=2458453193&scene=21&sn=e5392cb77bc17c9e94b6c826b5f52a83#wechat_redirect
[3. JavaScript_ _9]: http://mp.weixin.qq.com/s?__biz=MjM5MDc4MzgxNA%3D%3D&chksm=b1c224e386b5adf554ab928cdeaf7ee16dbb2d895be17f2a12a59054a75b913470ca7649bbc7&idx=1&mid=2458453194&scene=21&sn=e7f0734b04484bee5e10a85a7cbb85c1#wechat_redirect
[_ _ _ _ _16]: http://mp.weixin.qq.com/s?__biz=MjM5MDc4MzgxNA%3D%3D&chksm=b1c224e286b5adf432850f82db18cc8647d639836798cf16b478d9a6f7c81df87c6da5257684&idx=1&mid=2458453195&scene=21&sn=1e0c8b7ea8ddc207b523ec0a636a5254#wechat_redirect
[Webpack4]: http://mp.weixin.qq.com/s?__biz=MjM5MDc4MzgxNA%3D%3D&chksm=b1c2251f86b5ac09dbbbb7c8e1d80c6cbd793a523cdfa690f8734def57812e616b9906aeec79&idx=1&mid=2458453302&scene=21&sn=904e40a421024ea0d394e9850b674012#wechat_redirect
[Webpack4 1]: http://mp.weixin.qq.com/s?__biz=MjM5MDc4MzgxNA%3D%3D&chksm=b1c2251e86b5ac08464872cd880811423e0d1bbcebbe11dcac9d99fa38c5332c089c06d65d95&idx=1&mid=2458453303&scene=21&sn=422f2b5e22c3b0e91a8353ee7e53fed9#wechat_redirect
[MobX]: http://mp.weixin.qq.com/s?__biz=MjM5MDc4MzgxNA%3D%3D&chksm=b1c2264c86b5af5aa7300a04d55efead6223e310d68e10222cd3577a25c783d3429f00767960&idx=1&mid=2458453605&scene=21&sn=0a506769d5eeb7953f676e93fb4d18eb#wechat_redirect
[MobX 1]: http://mp.weixin.qq.com/s?__biz=MjM5MDc4MzgxNA%3D%3D&chksm=b1c2264086b5af5611524eedb0d409afe86d859dce6ceff1c17ddab49d353c385e45611a73fa&idx=1&mid=2458453609&scene=21&sn=f0c22e82f2537204d9b173161bae6b82#wechat_redirect
[Link 1]: http://mp.weixin.qq.com/s?__biz=MjM5MDc4MzgxNA%3D%3D&chksm=b1c224dd86b5adcbd98189315e60de6a0106993690b69927cc1c1f19fd8f591fefce4e3db51f&idx=2&mid=2458453236&scene=21&sn=daf00392f960c115463c5aaf980620b4#wechat_redirect
[d16195c8e8f57bf4fa29171baa16911d.gif]: /images/20220829/293ce89b16f44a93a3f1edecddbfffa8.png