setState详解与React性能优化
source link: https://segmentfault.com/a/1190000039776687
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
setState的同步和异步
1.为什么使用setState
开发中我们并不能直接通过修改
state
的值来让界面发生更新:- 因为我们修改了
state
之后, 希望React
根据最新的Stete
来重新渲染界面, 但是这种方式的修改React
并不知道数据发生了变化 React
并没有实现类似于Vue2
中的Object.defineProperty
或者Vue3
中的Proxy
的方式来监听数据的变化- 我们必须通过
setState
来告知React
数据已经发生了变化
- 因为我们修改了
疑惑: 在组件中并没有实现
steState
方法, 为什么可以调用呢?- 原因很简单:
setState
方法是从Component
中继承过来的
- 原因很简单:
2.setState异步更新
<details>
<summary>setState是异步更新的</summary>
<img src="https://gitee.com/xmkm/cloudPic/raw/master/img/20201001214531.png" />
</details>
为什么
setState
设计为异步呢?setState
设计为异步其实之前在GitHub
上也有很多的讨论- React核心成员(Redux的作者)Dan Abramov也有对应的回复, 有兴趣的可以看一下
简单的总结:
setState
设计为异步, 可以显著的提高性能- 如果每次调用
setState
都进行一次更新, 那么意味着render
函数会被频繁的调用界面重新渲染, 这样的效率是很低的 - 最好的方法是获取到多个更新, 之后进行批量更新
- 如果每次调用
如果同步更新了
state
, 但还没有执行render
函数, 那么state
和props
不能保持同步state
和props
不能保持一致性, 会在开发中产生很多的问题
3.如何获取异步的结果
- 如何获取
setState
异步更新state
后的值? 方式一:
setState
的回调setState
接收两个参数: 第二个参数是回调函数(callback
), 这个回调函数会在state
更新后执行
- 方式二:
componentDidUpdate
生命周期函数
3.setState一定是异步的吗?
- 其实可以分成两种情况
- 在组件生命周期或React合成事件中,
setState
是异步的- 在
setTimeou
或原生DOM事件中,setState
是同步的
- 验证一: 在
setTimeout
中的更新 —> 同步更新
- 验证二: 在原生
DOM
事件 —> 同步更新
4.源码分析
setState的合并
1.数据的合并
通过
setState
去修改message
,是不会对其他state
中的数据产生影响的- 源码中其实是有对 原对象 和 新对象 进行合并的
2.多个state的合并
- 当我们的多次调用了
setState
, 只会生效最后一次state
setState
合并时进行累加: 给setState传递函数, 使用前一次state
中的值
React 更新机制
1.React 更新机制
- 我们在前面已经学习
React
的渲染流程:
- 那么 React 的更新流程呢?
2.React 更新流程
React
在props
或state
发生改变时,会调用React
的render
方法,会创建一颗不同的树React
需要基于这两颗不同的树之间的差别来判断如何有效的更新UI
:如果一棵树参考另外一棵树进行完全比较更新, 那么即使是最先进的算法, 该算法的复杂程度为 O(n$^3$),其中 n 是树中元素的数量
- 如果在
React
中使用了该算法, 那么展示1000
个元素所需要执行的计算量将在十亿
的量级范围
- 如果在
- 这个开销太过昂贵了, React的更新性能会变得非常低效
于是,
React
对这个算法进行了优化,将其优化成了O(n)
,如何优化的呢?- 同层节点之间相互比较,不会跨节点比较
- 不同类型的节点,产生不同的树结构
- 开发中,可以通过key来指定哪些节点在不同的渲染下保持稳定
情况一: 对比不同类型的元素
当节点为不同的元素,React会拆卸原有的树,并且建立起新的树:
- 当一个元素从
<a>
变成<img>
,从<Article>
变成<Comment>
,或从<button>
变成<div>
都会触发一个完整的重建流程 - 当卸载一棵树时,对应的
DOM
节点也会被销毁,组件实例将执行componentWillUnmount()
方法 - 当建立一棵新的树时,对应的
DOM
节点会被创建以及插入到DOM
中,组件实例将执行componentWillMount()
方法,紧接着componentDidMount()
方法
- 当一个元素从
比如下面的代码更改:
- React 会销毁 Counter 组件并且重新装载一个新的组件,而不会对Counter进行复用
情况二: 对比同一类型的元素
- 当比对两个相同类型的 React 元素时,React 会保留 DOM 节点,仅对比更新有改变的属性
比如下面的代码更改:
- 通过比对这两个元素,
React
知道只需要修改DOM
元素上的className
属性
- 通过比对这两个元素,
比如下面的代码更改:
- 当更新
style
属性时,React
仅更新有所改变的属性。 - 通过比对这两个元素,
React
知道只需要修改DOM
元素上的color
样式,无需修改fontWeight
- 当更新
如果是同类型的组件元素:
- 组件会保持不变,
React
会更新该组件的props
,并且调用componentWillReceiveProps()
和componentWillUpdate()
方法 - 下一步,调用
render()
方法,diff
算法将在之前的结果以及新的结果中进行递归
- 组件会保持不变,
情况三: 对子节点进行递归
在默认条件下,当递归
DOM
节点的子元素时,React
会同时遍历两个子元素的列表;当产生差异时,生成一个mutation
我们来看一下在最后插入一条数据的情况:👇
- 前面两个比较是完全相同的,所以不会产生mutation
- 最后一个比较,产生一个mutation,将其插入到新的DOM树中即可
但是如果我们是在前面插入一条数据:
- React会对每一个子元素产生一个mutation,而不是保持
<li>星际穿越</li>
和<li>盗梦空间</li>
的不变 - 这种低效的比较方式会带来一定的性能问题
- React会对每一个子元素产生一个mutation,而不是保持
React 性能优化
1.key的优化
- 我们在前面遍历列表时,总是会提示一个警告,让我们加入一个
key
属性:
方式一:在<font color='red'>最后</font>位置插入数据
- 这种情况,有无
key
意义并不大
- 这种情况,有无
方式二:在<font color='red'>前面</font>插入数据
- 这种做法,在没有
key
的情况下,所有的<li>
都需要进行修改
- 这种做法,在没有
在下面案例: 当子元素 (这里的
li
元素) 拥有key
时React
使用key
来匹配原有树上的子元素以及最新树上的子元素:- <details>
<summary>下面这种场景下, key为 111 和 222 的元素仅仅进行位移,不需要进行任何的修改</summary>
<img src="04-React性能优化与SetState详解.assets/image-20200815145010219.png" style="zoom:80%;" />
</details> - 将
key
为333
的元素插入到最前面的位置即可
key
的注意事项:
key
应该是唯一的key
不要使用随机数(随机数在下一次render时,会重新生成一个数字)- 使用
index
作为key
,对性能是没有优化的
2.render函数被调用
我们使用之前的一个嵌套案例:
- 在App中,我们增加了一个计数器的代码
当点击
+1
时,会重新调用App
的render
函数- 而当 App 的 render函数被调用时,所有的子组件的 render 函数都会被重新调用
那么,我们可以思考一下,在以后的开发中,我们只要是修改 了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
已经默认帮我们实现好了, 如何实现呢?- <font color='red'>将 class 继承自 PureComponent</font>
- 内部会进行浅层对比最新的
state
和porps
, 如果组件内没有依赖porps
或state
将不会调用render
- 解决的问题: 比如某些子组件没有依赖父组件的
state
或props
, 但却调用了render
函数
5.shallowEqual方法
这个方法中,调用
!shallowEqual(oldProps, newProps) || !shallowEqual(oldState, newState)
,这个shallowEqual
就是进行浅层比较:
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知识点总结脑图
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK