React 性能优化 ：包括原理、技巧、Demo、工具使用

如果加上 React 的 key 属性，两次 Render 结果如下。 

  
<ul>  
  <li key="2015">Dukeli>  
  <li key="2016">Villanovali>  
ul>  
  
<ul>  
  <li key="2014">Connecticutli>  
  <li key="2015">Dukeli>  
  <li key="2016">Villanovali> 
ul>  
复制代码 

React Diff 算法会把 key 值为 2015 的虚拟 DOM 进行比较，发现 key 为 2015 的虚拟 DOM 没有发生修改，不用更新。同样，key 值为 2016 的虚拟 DOM 也不需要更新。结果就只需要创建 key 值为 2014 的虚拟 DOM。相比于不使用 key 的代码，使用 key 节省了两次 DOM 更新操作。

如果把例子中的

React 官方推荐[14]将每项数据的 ID 作为组件的 key，以达到上述的优化目的。并且不推荐使用_每项的索引_作为 key，因为传索引作为 key 时，就会退化为不使用 key 时的代码。那么是否在所有列表渲染的场景下，使用 ID 都优于使用索引呢？

答案是否定的，在常见的分页列表中，第一页和第二页的列表项 ID 都是不同，假设每页展示三条数据，那么切换页面前后组件 Render 结果如下。 

  
<li key="a">dataAli>  
<li key="b">dataBli>  
<li key="c">dataCli>  
  
<li key="d">dataDli>  
<li key="e">dataEli>  
<li key="f">dataFli>  
复制代码 

切换到第二页后，由于所有

尽管存在以上场景，React 官方仍然推荐使用 ID 作为每项的 key 值。其原因有两：

    1.  在列表中执行删除、插入、排序列表项的操作时，使用 ID 作为 key 将更高效。而翻页操作往往伴随着 API 请求，DOM 操作耗时远小于 API 请求耗时，是否使用 ID 在该场景下对用户体验影响不大。

    2.  使用 ID 做为 key 可以维护该 ID 对应的列表项组件的 State。举个例子，某表格中每列都有普通态和编辑态两个状态，起初所有列都是普通态，用户点击第一行第一列，使其进入编辑态。然后用户又拖拽第二行，将其移动到表格的第一行。如果开发者使用索引作为 key，那么第一行第一列的状态仍然为编辑态，而用户实际希望编辑的是第二行的数据，在用户看来就是不符合预期的。尽管这个问题可以通过将「是否处于编辑态」存放在数据项的数据中，利用 Props 来解决，但是使用 ID 作为 key 不是更香吗？

7. useMemo 返回虚拟 DOM

利用 useMemo 可以缓存计算结果的特点，如果 useMemo 返回的是组件的虚拟 DOM，则将在 useMemo 依赖不变时，跳过组件的 Render 阶段。该方式与 React.memo 类似，但与 React.memo 相比有以下优势：

1.  更方便。React.memo 需要对组件进行一次包装，生成新的组件。而 useMemo 只需在存在性能瓶颈的地方使用，不用修改组件。
2.  更灵活。useMemo 不用考虑组件的所有 Props，而只需考虑当前场景中用到的值，也可使用 useDeepCompareMemo[16] 对用到的值进行深比较。

例子参考：useMemo 跳过组件 Render 过程[17]。该例子中，父组件状态更新后，不使用 useMemo 的子组件会执行 Render 过程，而使用 useMemo 的子组件不会执行。 

import { useEffect, useMemo, useState } from "react"  
import "./styles.css"  
const renderCntMap = {}  
function Comp({ name }) {  
  renderCntMap[name] = (renderCntMap[name] || 0) + 1  
  return (  
    <div>  
      组件「{name}」 Render 次数：{renderCntMap[name]}  
    div>  
  )  
}   
export default function App() {  
  const setCnt = useState(0)[1]  
  useEffect(() => {  
    const timer = window.setInterval(() => {  
      setCnt(v => v + 1)  
    }, 1000)  
    return () => clearInterval(timer)  
  }, [setCnt])   
  const comp = useMemo(() => {  
    return <Comp name="使用 useMemo 作为 children" />  
  }, [])  
  return (  
    <div className="App">  
      <Comp name="直接作为 children" />  
      {comp}  
    div>  
  ) 
}  
复制代码 

8. 跳过回调函数改变触发的 Render 过程

React 组件的 Props 可以分为两类。a) 一类是在对组件 Render 有影响的属性，如：页面数据、getPopupContainer[18] 和 renderProps 函数。b) 另一类是组件 Render 后的回调函数，如：onClick、onVisibleChange[19]。b) 类属性并不参与到组件的 Render 过程，因为可以对 b) 类属性进行优化。当 b)类属性发生改变时，不触发组件的重新 Render ，而是在回调触发时调用最新的回调函数。

Dan Abramov 在 A Complete Guide to useEffect[20] 文章中认为，每次 Render 都有自己的事件回调是一件很酷的特性。但该特性要求每次回调函数改变就触发组件的重新 Render ，这在性能优化过程中是可以取舍的。

例子参考：跳过回调函数改变触发的 Render 过程[21]。Demo 中通过拦截子组件的 Props 实现，仅仅是因为笔者比较懒不想改了，这种实现方式也能开阔读者视野吧。实际上该优化思想应该通过 useMemo/React.memo 实现，且使用 useMemo 实现时也更容易理解。 

import { Children, cloneElement, memo, useEffect, useRef } from "react"  
import { useDeepCompareMemo } from "use-deep-compare"  
import omit from "lodash.omit"  
let renderCnt = 0  
export function SkipNotRenderProps({ children, skips }) {  
  if (!skips) {  
    // 默认跳过所有回调函数  
    skips = prop => prop.startsWith("on")  
  }  
  const child = Children.only(children)  
  const childchildProps = child.props  
  const propsRef = useRef({})  
  const nextSkippedPropsRef = useRef({})  
  Object.keys(childProps)  
    .filter(it => skips(it))  
    .forEach(key => {  
      // 代理函数只会生成一次，其值始终不变  
      nextSkippedPropsRef.current[key] =  
        nextSkippedPropsRef.current[key] ||  
        function skipNonRenderPropsProxy(...args) {  
          propsRef.current[key].apply(this, args)  
        }  
    })  
  useEffect(() => {  
    propsRef.current = childProps  
  })  
  // 这里使用 useMemo 优化技巧  
  // 除去回调函数，其他属性改变生成新的 React.Element  
  return useShallowCompareMemo(() => {  
    return cloneElement(child, {  
      ...child.props,  
      ...nextSkippedPropsRef.current,  
    })  
  }, [omit(childProps, Object.keys(nextSkippedPropsRef.current))])  
}  
// SkipNotRenderPropsComp 组件内容和 Normal 内容一样  
export function SkipNotRenderPropsComp({ onClick }) {  
  return (  
    <div className="case">  
      <div className="caseHeader">  
        跳过『与 Render 无关的 Props』改变触发的重新 Render  
      div>  
      Render 次数为：{++renderCnt}  
      <div>  
        <button onClick={onClick} style={{ color: "blue" }}>  
          点我回调，回调弹出值为 1000（优化成功）  
        button>  
      div>  
    div>  
  )  
}  
export default SkipNotRenderPropsComp  
复制代码 

9. Hooks 按需更新

如果自定义 Hook 暴露多个状态，而调用方只关心某一个状态，那么其他状态改变就不应该触发组件重新 Render。 

export const useNormalDataHook = () => {  
  const [data, setData] = useState({ info: null, count: null })  
  useEffect(() => {  
    const timer = setInterval(() => {  
      setData(data => ({  
        ...data,  
        count: data.count + 1,  
      }))  
    }, 1000)  
    return () => {  
      clearInterval(timer)  
    }  
  })  
  return data  
}  
复制代码 

如上所示，useNormalDataHook 暴露了两个状态 info 和 count 给调用方，如果调用方只关心 info 字段，那么 count 改变就没必要触发调用方组件 Render。

按需更新主要通过两步来实现，参考Hooks 按需更新[22]

1.  根据调用方使用的数据进行依赖收集，Demo 中使用 Object.defineProperties 实现。
2.  只在依赖发生改变时才触发组件更新。

10. 动画库直接修改 DOM 属性

这个优化在业务中应该用不上，但还是非常值得学习的，将来可以应用到组件库中。参考 react-spring[23] 的动画实现，当一个动画启动后，每次动画属性改变不会引起组件重新 Render ，而是直接修改了 dom 上相关属性值。

例子演示：CodeSandbox 在线 Demo[24] 

import React, { useState } from "react"  
import { useSpring, animated as a } from "react-spring"  
import "./styles.css"  
let renderCnt = 0  
export function Card() {  
  const [flipped, set] = useState(false)  
  const { transform, opacity } = useSpring({  
    opacity: flipped ? 1 : 0,  
    transform: `perspective(600px) rotateX(${flipped ? 180 : 0}deg)`,  
    config: { mass: 5, tension: 500, friction: 80 },  
  })  
  // 尽管 opacity 和 transform 的值在动画期间一直变化  
  // 但是并没有组件的重新 Render  
  return (  
    <div onClick={() => set(state => !state)}>  
      <div style={{ position: "fixed", top: 10, left: 10 }}>  
        Render 次数：{++renderCnt}  
      div>  
      <a.div  
        class="c back"  
        style={{ opacity: opacity.interpolate(o => 1 - o), transform }}  
      />  
      <a.div  
        class="c front"  
        style={{  
          opacity,  
          transform: transform.interpolate(t => `${t} rotateX(180deg)`),  
        }}  
      />  
    div>  
  )  
}  
export default Card  
复制代码 

提交阶段优化

这类优化的目的是减少提交阶段耗时，该分类中仅有一条优化技巧。

1. 避免在 didMount、didUpdate 中更新组件 State

这个技巧不仅仅适用于 didMount、didUpdate，还包括 willUnmount、useLayoutEffect 和特殊场景下的 useEffect（当父组件的 cDU/cDM 触发时，子组件的 useEffect 会同步调用），本文为叙述方便将他们统称为「提交阶段钩子」。

React 工作流[25]提交阶段的第二步就是执行提交阶段钩子，它们的执行会阻塞浏览器更新页面。如果在提交阶段钩子函数中更新组件 State，会再次触发组件的更新流程，造成两倍耗时。

一般在提交阶段的钩子中更新组件状态的场景有：

    1.  计算并更新组件的派生状态（Derived State）。在该场景中，类组件应使用 getDerivedStateFromProps[26] 钩子方法代替，函数组件应使用函数调用时执行 setState[27]的方式代替。使用上面两种方式后，React 会将新状态和派生状态在一次更新内完成。

    2.  根据 DOM 信息，修改组件状态。在该场景中，除非想办法不依赖 DOM 信息，否则两次更新过程是少不了的，就只能用其他优化技巧了。

use-swr 的源码[28]就使用了该优化技巧。当某个接口存在缓存数据时，use-swr 会先使用该接口的缓存数据，并在 requestIdleCallback 时再重新发起请求，获取最新数据。如果 use-swr 不做该优化的话，就会在 useLayoutEffect 中触发重新验证并设置 isValidating 状态为 true[29]，引起组件的更新流程，造成性能损失。

前端通用优化

这类优化在所有前端框架中都存在，本文的重点就在于将这些技巧应用在 React 组件中。

1. 组件按需挂载

组件按需挂载优化又可以分为懒加载、懒渲染和虚拟列表三类。

懒加载

在 SPA 中，懒加载优化一般用于从一个路由跳转到另一个路由。还可用于用户操作后才展示的复杂组件，比如点击按钮后展示的弹窗模块（有时候弹窗就是一个复杂页面 😌）。在这些场景下，结合 Code Split 收益较高。

懒加载的实现是通过 Webpack 的动态导入和 React.lazy 方法，

参考例子 lazy-loading[30]。实现懒加载优化时，不仅要考虑加载态，还需要对加载失败进行容错处理。 

import { lazy, Suspense, Component } from "react"  
import "./styles.css"  
// 对加载失败进行容错处理  
class ErrorBoundary extends Component {  
  constructor(props) {  
    super(props)  
    this.state = { hasError: false }  
  }  
  static getDerivedStateFromError(error) {  
    return { hasError: true }  
  }  
  render() {  
    if (this.state.hasError) {  
      return <h1>这里处理出错场景h1>  
    }  
    return this.props.children  
  }  
}  
const Comp = lazy(() => {  
  return new Promise((resolve, reject) => {  
    setTimeout(() => {  
      if (Math.random() > 0.5) {  
        reject(new Error("模拟网络出错"))  
      } else {  
        resolve(import("./Component"))  
      }  
    }, 2000)  
  })  
})  
export default function App() {  
  return (  
    <div className="App">  
      <div style={{ marginBottom: 20 }}>  
        实现懒加载优化时，不仅要考虑加载态，还需要对加载失败进行容错处理。 
      div>  
      <ErrorBoundary>  
        <Suspense fallback="Loading...">  
          <Comp />  
        Suspense>  
      ErrorBoundary>  
    div>  
  )  
}  
复制代码 

懒渲染

懒渲染指当组件进入或即将进入可视区域时才渲染组件。常见的组件 Modal/Drawer 等，当 visible 属性为 true 时才渲染组件内容，也可以认为是懒渲染的一种实现。

懒渲染的使用场景有：

    1.  页面中出现多次的组件，且组件渲染费时、或者组件中含有接口请求。如果渲染多个带有请求的组件，由于浏览器限制了同域名下并发请求的数量，就可能会阻塞可见区域内的其他组件中的请求，导致可见区域的内容被延迟展示。

    2.  需用户操作后才展示的组件。这点和懒加载一样，但懒渲染不用动态加载模块，不用考虑加载态和加载失败的兜底处理，实现上更简单。

懒渲染的实现中判断组件是否出现在可视区域内是通过 react-visibility-observer[31] 进行监听。

例子参考：懒渲染[32] 

import { useState, useEffect } from "react"  
import VisibilityObserver, {  
  useVisibilityObserver,  
} from "react-visibility-observer"  
const VisibilityObserverChildren = ({ callback, children }) => {  
  const { isVisible } = useVisibilityObserver()  
  useEffect(() => {  
    callback(isVisible)  
  }, [callback, isVisible])  
  return <>{children}>  
}  
export const LazyRender = () => {  
  const [isRendered, setIsRendered] = useState(false)  
  if (!isRendered) {  
    return (  
      <VisibilityObserver rootMargin={"0px 0px 0px 0px"}>  
        <VisibilityObserverChildren 
           callback={isVisible => {  
            if (isVisible) {  
              setIsRendered(true)  
            }  
          }}  
        >  
          <span />  
        VisibilityObserverChildren>  
      VisibilityObserver>  
    )  
  }  
  console.log("滚动到可视区域才渲染")  
  return <div>我是 LazyRender 组件div>  
}  
export default LazyRender 
复制代码 

虚拟列表

虚拟列表是懒渲染的一种特殊场景。虚拟列表的组件有 react-window[33] 和 react-virtualized，它们都是同一个作者开发的。react-window 是 react-virtualized 的轻量版本，其 API 和文档更加友好。所以新项目中推荐使用 react-window，而不是使用 Star 更多的 react-virtualized。

使用 react-window 很简单，只需要计算每项的高度即可。下面代码中每一项的高度是 35px。

例子参考：官方示例[34] 

import { FixedSizeList as List } from "react-window"  
const Row = ({ index, style }) => <div style={style}>Row {index}div>  
const Example = () => (  
  <List  
    height={150}  
    itemCount={1000}  
    itemSize={35} // 每项的高度为 35  
    width={300}  
  >  
    {Row}  
  List>  
)  
复制代码 

如果每项的高度是变化的，可给 itemSize 参数传一个函数。

对于这个优化点，笔者遇到一个真实案例。在公司的招聘项目中，通过下拉菜单可查看某个候选人的所有投递记录。平常这个列表也就几十条，但后来用户反馈『下拉菜单点击后要很久才能展示出投递列表』。该问题的原因就是这个候选人在我们系统中有上千条投递，一次性展示上千条投递导致页面卡住了。所以在开发过程中，遇到接口返回的是所有数据时，需提前预防这类 bug，使用虚拟列表优化。

2. 批量更新

我们先回忆一道前几年的 React 面试常考题，React 类组件中 setState 是同步的还是异步的？如果对类组件不熟悉也没关系，可以将 setState 理解为 useState 的第二个返回值。

balabala...

答案是：在 React 管理的事件回调和生命周期中，setState 是异步的，而其他时候 setState 都是同步的。这个问题根本原因就是 React 在自己管理的事件回调和生命周期中，对于 setState 是批量更新的，而在其他时候是立即更新的。读者可参考线上示例 setState 同步还是异步[35]，并自行验证。

批量更新 setState 时，多次执行 setState 只会触发一次 Render 过程。相反在立即更新 setState 时，每次 setState 都会触发一次 Render 过程，就存在性能影响。

假设有如下组件代码，该组件在 getData() 的 API 请求结果返回后，分别更新了两个 State 。线上代码实操参考：batchUpdates 批量更新[36]。 

function NormalComponent() {  
  const [list, setList] = useState(null)  
  const [info, setInfo] = useState(null)  
  useEffect(() => {  
    ;(async () => {  
      const data = await getData()  
      setList(data.list)  
      setInfo(data.info)  
    })()  
  }, [])  
  return <div>非批量更新组件时 Render 次数：{renderOnce("normal")}div>  
}  
复制代码 

该组件会在 setList(data.list) 后触发组件的 Render 过程，然后在 setInfo(data.info) 后再次触发 Render 过程，造成性能损失。遇到该问题，开发者有两种实现批量更新的方式来解决该问题：

    1.  将多个 State 合并为单个 State。例如使用 `const [data, setData] = useState({ list: null, info: null })` 替代 list 和 info 两个 State。

    2.  使用 React 官方提供的 unstable\_batchedUpdates 方法，将多次 setState 封装到 unstable\_batchedUpdates 回调中。修改后代码如下。 

function BatchedComponent() {  
  const [list, setList] = useState(null)  
  const [info, setInfo] = useState(null)  
  useEffect(() => {  
    ;(async () => {  
      const data = await getData()  
      unstable_batchedUpdates(() => {  
        setList(data.list)  
        setInfo(data.info)  
      })  
    })()  
  }, [])  
  return <div>批量更新组件时 Render 次数：{renderOnce("batched")}div>  
}  
复制代码 

拓展知识

        1.  推荐阅读为什么 setState 是异步的？[37]

        2.  为什么面试官不会问“函数组件中的 setState 是同步的还是异步的？”？因为函数组件中生成的函数是通过闭包引用了 state，而不是通过 this.state 的方式引用 state，所以函数组件的处理函数中 state 一定是旧值，不可能是新值。可以说函数组件已经将这个问题屏蔽掉了，所以面试官也就不会问了。可参考线上示例[38]。

        3.  根据官方文档[39]，在 React 并发模式中，将默认以批量更新方式执行 setState。到那时候，也可能就不需要这个优化了。

3. 按优先级更新，及时响应用户

优先级更新是批量更新的逆向操作，其思想是：优先响应用户行为，再完成耗时操作。

常见的场景是：页面弹出一个 Modal，当用户点击 Modal 中的确定按钮后，代码将执行两个操作。a) 关闭 Modal。b) 页面处理 Modal 传回的数据并展示给用户。当 b) 操作需要执行 500ms 时，用户会明显感觉到从点击按钮到 Modal 被关闭之间的延迟。

例子参考：CodeSandbox 在线 Demo[40]。在该例子中，用户添加一个整数后，页面要隐藏输入框，并将新添加的整数加入到整数列表，将列表排序后再展示。以下为一般的实现方式，将 slowHandle 函数作为用户点击按钮的回调函数。 

const slowHandle = () => {  
  setShowInput(false)  
  setNumbers([...numbers, +inputValue].sort((a, b) => a - b))  
}  
复制代码 

slowHandle() 执行过程耗时长，用户点击按钮后会明显感觉到页面卡顿。如果让页面优先隐藏输入框，用户便能立刻感知到页面更新，不会有卡顿感。实现优先级更新的要点是将耗时任务移动到下一个宏任务中执行，优先响应用户行为。 例如在该例中，将 setNumbers 移动到 setTimeout 的回调中，用户点击按钮后便能立即看到输入框被隐藏，不会感知到页面卡顿。优化后的代码如下。 

const fastHandle = () => {  
  // 优先响应用户行为  
  setShowInput(false)  
  // 将耗时任务移动到下一个宏任务执行  
  setTimeout(() => {  
    setNumbers([...numbers, +inputValue].sort((a, b) => a - b))  
  })  
}  
复制代码 

4. 缓存优化

缓存优化往往是最简单有效的优化方式，在 React 组件中常用 useMemo 缓存上次计算的结果。当 useMemo 的依赖未发生改变时，就不会触发重新计算。一般用在「计算派生状态的代码」非常耗时的场景中，如：遍历大列表做统计信息。

拓展知识

1.   React 官方并不保证 useMemo 一定会进行缓存，所以可能在依赖不改变时，仍然执行重新计算。参考 How to memoize calculations[41]
2.   useMemo 只能缓存最近一次函数执行的结果，如果想缓存更多次函数执行的结果，可使用 memoizee[42]。

5. debounce、throttle 优化频繁触发的回调

在搜索组件中，当 input 中内容修改时就触发搜索回调。当组件能很快处理搜索结果时，用户不会感觉到输入延迟。但实际场景中，中后台应用的列表页非常复杂，组件对搜索结果的 Render 会造成页面卡顿，明显影响到用户的输入体验。

在搜索场景中一般使用 useDebounce[43] + useEffect 的方式获取数据。

例子参考：debounce-search[44]。 

import { useState, useEffect } from "react"  
import { useDebounce } from "use-debounce"  
export default function App() {  
  const [text, setText] = useState("Hello")  
  const [debouncedValue] = useDebounce(text, 300)  
  useEffect(() => {  
    // 根据 debouncedValue 进行搜索 
  }, [debouncedValue])  
  return (  
    <div>  
      <input  
        defaultValue={"Hello"}  
        onChange={e => {  
          setText(e.target.value)  
        }}  
      /> 
       <p>Actual value: {text}p>  
      <p>Debounce value: {debouncedValue}p>  
    div>  
  )  
}  
复制代码 

为什么搜索场景中是使用 debounce，而不是 throttle 呢？

throttle 是 debounce 的特殊场景，throttle 给 debounce 传了 maxWait 参数，可参考 useThrottleCallback[45]。在搜索场景中，只需响应用户最后一次输入，无需响应用户的中间输入值，debounce 更适合使用在该场景中。而 throttle 更适合需要实时响应用户的场景中更适合，如通过拖拽调整尺寸或通过拖拽进行放大缩小（如：window 的 resize 事件）。实时响应用户操作场景中，如果回调耗时小，甚至可以用 requestAnimationFrame 代替 throttle。

React Profiler 定位 Render 过程瓶颈

React Profiler 是 React 官方提供的性能审查工具，本文只介绍笔者的使用心得，详细的使用手册请移步官网文档[46]。

Profiler 只记录了 Render 过程耗时

通过 React Profiler，开发者可以查看组件 Render 过程耗时，但无法知晓提交阶段的耗时。尽管 Profiler 面板中有 Committed at 字段，但这个字段是相对于录制开始时间，根本没有意义。所以提醒读者不要通过 Profiler 定位非 Render 过程的性能瓶颈问题。

通过在 React v16 版本上进行实验，同时开启 Chrome 的 Performance 和 React Profiler 统计。如下图，在 Performance 面板中，调和阶段和提交阶段耗时分别为 642ms 和 300ms，而 Profiler 面板中只显示了 642ms，没有提交阶段的耗时信息。

拓展知识

1.    React 在 v17 版本后已移除 User Timing 统计功能，具体原因可参考 PR#18417[47]。
2.    在 v17 版本上，笔者也通过测试代码[48]验证了 Profiler 中的统计信息并不包含提交阶段，有兴趣的读者可以看看。

开启「记录组件更新原因」

点击面板上的齿轮，然后勾选「Record why each component rendered while profiling.」，如下图。

然后点击面板中的虚拟 DOM 节点，右侧便会展示该组件重新 Render 的原因。

定位产生本次 Render 过程原因

由于 React 的批量更新（Batch Update）机制，产生一次 Render 过程可能涉及到很多个组件的状态更新。那么如何定位是哪些组件状态更新导致的呢？

在 Profiler 面板左侧的虚拟 DOM 树结构中，从上到下审查每个发生了渲染的（不会灰色的）组件。如果组件是由于 State 或 Hook 改变触发了 Render 过程，那它就是我们要找的组件，如下图。

结语

笔者是从年前开始写这篇文章，到发布时已经写了一个月了，期间断断续续将自己这几年对 React 的理解加入到文章中，然后调整措辞和丰富示例，最后终于在周四前完成（周四是我定的 deadline 😌）。

既然自己付出了那么多努力，那就希望它能成为一份优秀的 React 优化手册吧。