从 setState 聊到 React 性能优化

做者：风不识途前端

https://segmentfault.com/a/1190000039776687react

setState的同步和异步

1.为何使用setState

开发中咱们并 不能直接经过修改 state 的值来 让界面发生更新：

由于咱们修改了 state 以后, 但愿 React 根据最新的 Stete 来从新渲染界面, 可是这种方式的修改 React 并不知道数据发生了变化
React 并无实现相似于 Vue2 中的 Object.defineProperty 或者 Vue3 中的 Proxy的方式来监听数据的变化
咱们必须经过 setState 来告知 React 数据已经发生了变化

疑惑: 在组件中并无实现 steState 方法, 为何能够调用呢?

缘由很简单: setState方法是从 Component 中 继承过来的

2.setState异步更新

setState是异步更新的 web

为何 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 的更新流程呢?

React基本流程

2.React 更新流程

React在 props 或 state 发生改变时，会调用 React 的 render 方法，会建立一颗不一样的树面试
React须要基于这两颗不一样的树之间的差异来判断如何有效的更新UI：算法
若是一棵树参考另一棵树进行彻底比较更新, 那么即便是最早进的算法, 该算法的复杂程度为 O(n 3 ^3 3)，其中 n 是树中元素的数量编程

若是在 React 中使用了该算法, 那么展现 1000 个元素所须要执行的计算量将在 十亿的量级范围

这个开销太过昂贵了, React的更新性能会变得很是低效segmentfault
因而，React对这个算法进行了优化，将其优化成了O(n)，如何优化的呢？性能优化

同层节点之间相互比较，不会跨节点比较微信
不一样类型的节点，产生不一样的树结构app
开发中，能够经过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 性能优化

1.key的优化

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

方式一：在最后位置插入数据

这种状况，有无 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 函数都会被从新调用

那么，咱们能够思考一下，在之后的开发中，咱们只要是修改了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函数

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知识点总结脑图

最后

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

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

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

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

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

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

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

本文分享自微信公众号 - 前端瓶子君（pinzi_com）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。