setState详解与React性能优化

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

• 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 性能优化

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