从 setState 聊到 React 性能优化

妖狐艹你老母 2022-09-10 14:11 188阅读 0赞

点击上方 前端Q，关注公众号

回复加群，加入前端Q技术交流群

作者：风不识途

https://segmentfault.com/a/1190000039776687

## setState的同步和异步    ##

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

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

![818a0ea56a7abaa09658631c5da9c22a.png][]

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

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

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

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

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

![1b626bbd7a5abe4c67c91e256345812b.png][]

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

![136afc9677814ea9e0152e3d6ce30c52.png][]

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

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

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

![3f069ffd10432f623c7dd96dd459d52f.png][]

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

![0c11522bd0094f9e95eee77d84d1dc5e.png][]

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

![a50a53c71e54d4f5401bee955bc10217.png][]

## setState的合并 ##

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

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

![136e29544a0d8f6422125f19b9e3e3ad.png][]

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

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

![7e67c0313ef5be106cc4f613d01ab76b.png][]

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

![2b62019564f676ac89d5ff904ee70e63.png][]

## React 更新机制 ##

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

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

![aa42b08de137fa351f47c68e19552c6c.png][]

*  那么 React 的更新流程呢?

![8b204a293203dc24df922ee9bad3909e.png][]

*  React基本流程

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

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

![0ea2a757940a97690e26c6beb47b6a69.png][]

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

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

![0ab627f07c929876aa4905074ccda645.png][]

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

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

![27e8b184b955637e9d9b6fc015d0660d.png][]

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

![44b01aff43e405fcaf998d26f0e26c98.png][]

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

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

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

## React 性能优化 ##

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

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

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

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

![6c79349adfa132d7916c312e96444d3e.png][] ![6a7dfa19dd001522a8cf0dfb02338355.png][]

### 5.shallowEqual方法 ###

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

声明：文章著作权归作者所有，如有侵权，请联系小编删除。

![abb261d93fb27b10034215416a8141fa.png][]

往期推荐

[大厂面试过程复盘(微信/阿里/头条,附答案篇)][Link 1]

![15433e5914daa2307356b89486100c6d.png][]

[面试题：说说事件循环机制(满分答案来了)][Link 2]

![bb3a92b532e458c409be22cad62a75e1.png][]

[专心工作只想搞钱的前端女程序员的2020][2020]

![8185b96c68e1de8fae5b551032394d25.png][]

最后

*  欢迎加我微信，拉你进技术群，长期交流学习...  
    
 *  欢迎关注「前端Q」,认真学前端，做个专业的技术人...

![785b5fea580b3308c608f684bc20cbdb.png][]

![df1ff00388e7a80ed65ed1b7aacb9b6d.png][]

点个**在看**支持我吧

![a213f3fb9ab92e3a545e212ee171ca4a.gif][]

[818a0ea56a7abaa09658631c5da9c22a.png]: /images/20220829/ff623d9d19bd4af591e29d7c8a6e80f7.png
[3641d90c3d9252eee4786fe4af1a7dbc.png]: /images/20220829/96942a291b074282928a153c8bd120d0.png
[1b626bbd7a5abe4c67c91e256345812b.png]: /images/20220829/9e8a4af878c84560acd4906353b9e934.png
[136afc9677814ea9e0152e3d6ce30c52.png]: /images/20220829/75edc869b5d24da585ee183f1a13f0c7.png
[3f069ffd10432f623c7dd96dd459d52f.png]: /images/20220829/76f84ba9cb774028b13d8f204fd7ed33.png
[0c11522bd0094f9e95eee77d84d1dc5e.png]: /images/20220829/c3169f6d36774c82b6e9e692ff36d30f.png
[a50a53c71e54d4f5401bee955bc10217.png]: /images/20220829/1342183602d347f4b57291b6412a334e.png
[136e29544a0d8f6422125f19b9e3e3ad.png]: /images/20220829/08eef833d2a64ef3b5e742242459f20b.png
[7e67c0313ef5be106cc4f613d01ab76b.png]: /images/20220829/8f46d6535e31461eae0b8dceb5ebbf7f.png
[2b62019564f676ac89d5ff904ee70e63.png]: /images/20220829/e62411f252dd47f4866977da960f330a.png
[aa42b08de137fa351f47c68e19552c6c.png]: /images/20220829/836c296e0fdf47498122ce7ffad94acd.png
[8b204a293203dc24df922ee9bad3909e.png]: /images/20220829/15b7c0e9b0d449b1bd499994839c03bf.png
[0ea2a757940a97690e26c6beb47b6a69.png]: /images/20220829/7242df2d28d3457b8d9f0d0fd25d61d9.png
[0ab627f07c929876aa4905074ccda645.png]: /images/20220829/50191c13ebcc4abaaaf6a1707bf895d0.png
[27e8b184b955637e9d9b6fc015d0660d.png]: /images/20220829/d8e32b113cf84f2980a629dd709a4d78.png
[44b01aff43e405fcaf998d26f0e26c98.png]: /images/20220829/46782bc84b99499c984eb84db1e9ee44.png
[820180c1d609645f35c7d0675a150d77.png]: /images/20220829/3d795b4a5db343d391b7364491eb2cc5.png
[1be8bbca4b687be80e7491c7c1e35551.png]: /images/20220829/7c1f7bf76bfb48d6b03a2826b653f438.png
[5d73b2720e643c20d92eeee96228d5fd.png]: /images/20220829/a5ce51caea584e1aa02276ffb7d09725.png
[3305428ab68b3c608ca67bc273f2f794.png]: /images/20220829/d17428d152064cdba0aa92332be1caef.png
[6c79349adfa132d7916c312e96444d3e.png]: https://img-blog.csdnimg.cn/img_convert/6c79349adfa132d7916c312e96444d3e.png
[6a7dfa19dd001522a8cf0dfb02338355.png]: /images/20220829/4b95b12661c047d4ade88f2daa4fb4f9.png
[47c7f5f97ecda8a9819a74726e1de6b2.png]: /images/20220829/0afaec25e39f4f9b93907d47de6abd58.png
[abb261d93fb27b10034215416a8141fa.png]: /images/20220829/d985aa7274714132a642326b354e9391.png
[Link 1]: http://mp.weixin.qq.com/s?__biz=MzI0MzIyMDM5Ng%3D%3D&chksm=f175e460c6026d76bcdfc6dd42cfe80a3f14ea832d1922d65043f666d6de22bd17b09e779ed9&idx=2&mid=2649829027&scene=21&sn=1a433047a8d6e8af65012bfa0bd27e3f#wechat_redirect
[15433e5914daa2307356b89486100c6d.png]: /images/20220829/454a2aa3bd5843b7b9e09dd72ecef059.png
[Link 2]: http://mp.weixin.qq.com/s?__biz=MzI0MzIyMDM5Ng%3D%3D&chksm=f175ef9ec60266880a86f33085ff43f95e3180846c5f139cb9b1b33c3245201157f39d949e9a&idx=1&mid=2649826653&scene=21&sn=9e5e2de78a8ef4de3820769ff3ab7c02#wechat_redirect
[bb3a92b532e458c409be22cad62a75e1.png]: /images/20220829/1328dbe4d4064d64a58dc33f6df9c997.png
[2020]: http://mp.weixin.qq.com/s?__biz=MzI0MzIyMDM5Ng%3D%3D&chksm=f175f306c6027a1029967cde600630a5107fbbfdd125b64ba3f2c9d9b570b102162ab4c3b373&idx=1&mid=2649831877&scene=21&sn=9352cf4624308602c50a6fd10379d132#wechat_redirect
[8185b96c68e1de8fae5b551032394d25.png]: /images/20220829/fee24761f17347c787186886776a7900.png
[785b5fea580b3308c608f684bc20cbdb.png]: /images/20220829/a19a1dd68a3a43918a749c9c8988402e.png
[df1ff00388e7a80ed65ed1b7aacb9b6d.png]: /images/20220829/b64c1d272da0466f8b9ab5c6223f5176.png
[a213f3fb9ab92e3a545e212ee171ca4a.gif]: /images/20220829/17e4fd4d0ee74cbeb1a9fddccbb2180f.png