前言：咱们从 React 源码动手，联合有道精品课大前端的具体业务，使用三大准则对系统进行外科手术式的优化。同时介绍 React Profiler 这款工具如何帮咱们定位性能瓶颈前言：咱们从 React 源码动手，联合有道精品课大前端的具体业务，使用三大准则对系统进行外科手术式的优化。同时介绍 React Profiler 这款工具如何帮咱们定位性能瓶颈

作者 / 安增平

编辑 / Ein

React 性能优化是在业务迭代过程中不得不思考的问题，大部分状况是因为我的项目启动之初，没有充分考虑到我的项目的复杂度，定位该产品的用户体量及技术场景并不简单，那么咱们在业务后期可能并不需要思考性能优化。然而随着业务场景的复杂化，性能优化就变得分外重要。

咱们从 React 源码动手，联合有道精品课大前端的具体业务，使用优化技巧对系统进行外科手术式的优化。同时介绍一下 React Profiler 这款性能优化的利器是如何帮咱们定位性能瓶颈的。

本文中的我的项目代码全副是在有道大前端组开发我的项目中的工作记录，如有有余欢送在留言区探讨交换，笔芯❤

页面加载流程

1. 假如用户首次关上页面（无缓存），这个时候页面是齐全空白的；
2. html 和援用的 css 加载结束，浏览器进行 首次渲染；
3. react、react-dom、业务代码加载结束，利用第一次渲染，或者说 首次内容渲染；
4. 利用的代码开始执行，拉取数据、进行动静 import、响应事件等等，结束后页面进入 可交互 状态；
5. 接下来 lazyload 的图片等多媒体内容开始逐步加载结束；
6. 直到页面的其它资源（如谬误上报组件、打点上报组件等）加载结束，整个页面加载实现。

咱们次要来针对 React 进行分析：

React 针对渲染性能优化的三个方向，也实用于其余软件开发畛域，这三个方向别离是:

1. 缩小计算的量：React 中就是缩小渲染的节点或通过索引缩小渲染复杂度；
2. 利用缓存：React 中就是防止从新渲染（利用 memo 形式来防止组件从新渲染）；
3. 准确从新计算的范畴：React 中就是绑定组件和状态关系, 准确判断更新的 ’ 机会 ’ 和 ’ 范畴 ’. 只从新渲染变更的组件（缩小渲染范畴）。

如何做到这三点呢？咱们从 React 自身的个性动手剖析。

React 工作流

React 是申明式 UI 库，负责将 State 转换为页面构造（虚构 DOM 构造）后，再转换成实在 DOM 构造，交给浏览器渲染。State 产生扭转时，React 会先进行 Reconciliation，完结后立即进入 Commit 阶段，Commit 完结后，新 State 对应的页面才被展现进去。

React 的 Reconciliation 须要做两件事：

1. 计算出指标 State 对应的虚构 DOM 构造。
2. 寻找「将虚构 DOM 构造批改为指标虚构 DOM 构造」的最优计划。

React 依照深度优先遍历虚构 DOM 树的形式，在一个虚构 DOM 上实现 Render 和 Diff 的计算后，再计算下一个虚构 DOM。Diff 算法会记录虚构 DOM 的更新形式（如：Update、Mount、Unmount），为 Commit 做筹备。

React 的 Commit 也须要做两件事：

1. 将 Reconciliation 后果利用到 DOM 中。
2. 调用裸露的 hooks 如：componentDidUpdate、useLayoutEffect 等。

上面咱们将针对三个优化方向进行精准剖析。

缩小计算的量

对于以上 Reconciliation 与Commit两个阶段的优化方法，我在实现的过程中遵循 缩小计算量 的办法进行优化（列表项应用 key 属性 ) 该过程是优化的重点，React 外部的 Fiber 构造和并发模式也是在缩小该过程的耗时阻塞。对于 Commit 在执行 hooks 时，开发者应保障 hooks 中的代码尽量轻量，防止耗时阻塞，同时应防止在 CDM、CDU周期中更新组件。

列表项应用 key 属性

特定框架中，提醒也做的非常敌对。如果你没有在列表中增加 key 属性，控制台会为你展现一片大红

零碎会时刻揭示你记得加 Key 哦~~

优化 Render 过程

Render 过程：即 Reconciliation 中计算出指标 State 对应的虚构 DOM 构造这一阶段。

触发 React 组件的 Render 过程目前有三种形式：

1. forceUpdate、
2. State 更新、
3. 父组件 Render 触发子组件 Render 过程。

优化技巧

PureComponent、React.memo

在 React 工作流中，如果只有父组件产生状态更新，即便父组件传给子组件的所有 Props 都没有批改，也会引起子组件的 Render 过程。

从 React 的申明式设计理念来看，如果子组件的 Props 和 State 都没有扭转，那么其生成的 DOM 构造和副作用也不应该产生扭转。当子组件合乎申明式设计理念时，就能够疏忽子组件本次的 Render 过程。

PureComponent 和 React.memo 就是应答这种场景的，PureComponent 是对类组件的 Props 和 State 进行浅比拟，React.memo 是对函数组件的 Props 进行浅比拟。

useMemo、useCallback 实现稳固的 Props 值

如果传给子组件的派生状态或函数，每次都是新的援用，那么 PureComponent 和 React.memo 优化就会生效。所以须要应用 useMemo 和 useCallback 来生成稳固值，并联合 PureComponent 或 React.memo 防止子组件从新 Render。

useMemo 缩小组件 Render 过程耗时

useMemo 是一种缓存机制提速，当它的依赖未产生扭转时，就不会触发从新计算。个别用在「计算派生状态的代码」十分耗时的场景中，如：遍历大列表做统计信息。

显然 useMemo 的作用是缓存低廉的计算(防止在每次渲染时都进行高开销的计算)，在业务中应用它去控制变量来更新表格

shouldComponentUpdate

在类组件中，例如要往数组中增加一项数据时，过后的代码很可能是 state.push(item)，而不是 const newState = […state, item]。

在此背景下，过后的开发者常常应用

shouldComponentUpdate 来深比拟 Props，只在 Props 有批改才执行组件的 Render 过程。现在因为数据不可变性和函数组件的风行，这样的优化场景曾经不会再呈现了。

为了贴合 shouldComponentUpdate 的思维：给子组件传 props 的时候肯定只传其须要的而并非一股脑全副传入：

传入到子组件的参数肯定保障其在自组件中被应用到。

批量更新，缩小 Render 次数

在 React 治理的事件回调和生命周期中，setState 是异步的，而其余时候 setState 都是同步的。这个问题根本原因就是 React 在本人治理的事件回调和生命周期中，对于 setState 是批量更新的，而在其余时候是立刻更新的。

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

假如有如下组件代码，该组件在 getData() 的 API 申请后果返回后，别离更新了两个 State。

该组件会在 setList(data.list) 后触发组件的 Render 过程，而后在 setInfo(data.info) 后再次触发 Render 过程，造成性能损失。那咱们该如何解决呢：

1. 将多个 State 合并为单个 State。例如 useState({list: null, info: null}) 代替 list 和 info 两个 State。
2. 应用 React 官网提供的 unstable_batchedUpdates 办法，将屡次 setState 封装到 unstable_batchedUpdates 回调中。

批改后代码如下：

精细化渲染阶段

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

优先级更新是批量更新的逆向操作，其思维是：优先响应用户行为，再实现耗时操作。常见的场景是：页面弹出一个 Modal，当用户点击 Modal 中的确定按钮后，代码将执行两个操作：

1. 敞开 Modal。
2. 页面解决 Modal 传回的数据并展现给用户。

当操作 2 须要执行 500ms 时，用户会显著感觉到从点击按钮到 Modal 被敞开之间的提早。

以下为个别的实现形式，将 slowHandle 函数作为用户点击按钮的回调函数。

slowHandle() 执行过程耗时长，用户点击按钮后会显著感觉到页面卡顿。

如果让页面优先暗藏输入框，用户便能立即感知到页面更新，不会有卡顿感。

实现优先级更新的要点是将耗时工作挪动到下一个宏工作中执行，优先响应用户行为。

例如在该例中，将 setNumbers 挪动到 setTimeout 的回调中，用户点击按钮后便能立刻看到输入框被暗藏，不会感知到页面卡顿。mhd 我的项目中优化后的代码如下：

发布者订阅者跳过两头组件 Render 过程

React 举荐将公共数据放在所有「须要该状态的组件」的公共先人上，但将状态放在公共先人上后，该状态就须要层层向下传递，直到传递给应用该状态的组件为止。

每次状态的更新都会波及两头组件的 Render 过程，但两头组件并不关怀该状态，它的 Render 过程只负责将该状态再传给子组件。在这种场景下能够将状态用发布者订阅者模式保护，只有关怀该状态的组件才去订阅该状态，不再须要两头组件传递该状态。

当状态更新时，发布者公布数据更新音讯，只有订阅者组件才会触发 Render 过程，两头组件不再执行 Render 过程。

只有是发布者订阅者模式的库，都能够应用 useContext 进行该优化。比方：redux、use-global-state、React.createContext 等。

业务代码中的应用如下：

从图中可看出，优化后只有应用了公共状态的组件 renderTable 才会产生更新，由此可见这样做能够大大减少父组件和 其余 renderSon… 组件的 Render 次数(缩小叶子节点的重渲染)。

useMemo 返回虚构 DOM 可跳过该组件 Render 过程

利用 useMemo 能够缓存计算结果的特点，如果 useMemo 返回的是组件的虚构 DOM，则将在 useMemo 依赖不变时，跳过组件的 Render 阶段。

该形式与 React.memo 相似，但与 React.memo 相比有以下劣势：

1. 更不便。React.memo 须要对组件进行一次包装，生成新的组件。而 useMemo 只需在存在性能瓶颈的中央应用，不必批改组件。
2. 更灵便。useMemo 不必思考组件的所有 Props，而只需思考以后场景中用到的值，也可应用 useDeepCompareMemo 对用到的值进行深比拟。

该例子中，父组件状态更新后，不应用 useMemo 的子组件会执行 Render 过程，而应用 useMemo 的子组件会按需执行更新。业务代码中的应用办法：

准确判断更新的 ’ 机会 ’ 和 ’ 范畴 ’

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

在搜寻组件中，当 input 中内容批改时就触发搜寻回调。当组件能很快解决搜寻后果时，用户不会感觉到输出提早。

但理论场景中，中后盾利用的列表页非常复杂，组件对搜寻后果的 Render 会造成页面卡顿，显著影响到用户的输出体验。

在搜寻场景中个别应用 useDebounce+ useEffect 的形式获取数据。

在搜寻场景中，只需响应用户最初一次输出，无需响应用户的两头输出值，debounce 更适宜。而 throttle 更适宜须要实时响应用户的场景中更适宜，如通过拖拽调整尺寸或通过拖拽进行放大放大（如：window 的 resize 事件）。

懒加载

在 SPA 中，懒加载优化个别用于从一个路由跳转到另一个路由。

还可用于用户操作后才展现的简单组件，比方点击按钮后展现的弹窗模块（大数据量弹窗）。

在这些场景下，联合 Code Split 收益较高。懒加载的实现是通过 Webpack 的动静导入和 React.lazy 办法。

实现懒加载优化时，不仅要思考加载态，还须要对加载失败进行容错解决。

懒渲染

懒渲染指当组件进入或行将进入可视区域时才渲染组件。常见的组件 Modal/Drawer 等，当 visible 属性为 true 时才渲染组件内容，也能够认为是懒渲染的一种实现。懒渲染的应用场景有：

1. 页面中呈现屡次的组件，且组件渲染费时、或者组件中含有接口申请。如果渲染多个带有申请的组件，因为浏览器限度了同域名下并发申请的数量，就可能会阻塞可见区域内的其余组件中的申请，导致可见区域的内容被提早展现。
2. 需用户操作后才展现的组件。这点和懒加载一样，但懒渲染不必动静加载模块，不必思考加载态和加载失败的兜底解决，实现上更简略。

懒渲染的实现中判断组件是否呈现在可视区域内借助 react-visibility-observer 依赖：

虚构列表

虚构列表是懒渲染的一种非凡场景。虚构列表的组件有 react-window 和 react-virtualized，它们都是同一个作者开发的。

react-window 是 react-virtualized 的轻量版本，其 API 和文档更加敌对。举荐应用 react-window，只须要计算每项的高度即可：

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

所以在开发过程中，遇到接口返回的是所有数据时，需提前预防这类会有展现的性能瓶颈的需要时，举荐应用虚构列表优化。应用示例：react-window​react-window.vercel.app

动画库间接批改 DOM 属性，跳过组件 Render 阶段

这个优化在业务中应该用不上，但还是十分值得学习的，未来能够利用到组件库中。

参考 react-spring 的动画实现，当一个动画启动后，每次动画属性扭转不会引起组件从新 Render，而是间接批改了 dom 上相干属性值：

防止在 didMount、didUpdate 中更新组件 State

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

React 工作流 commit阶段的第二步就是执行提交阶段钩子，它们的执行会阻塞浏览器更新页面。

如果在提交阶段钩子函数中更新组件 State，会再次触发组件的更新流程，造成两倍耗时。个别在提交阶段的钩子中更新组件状态的场景有：

1. 计算并更新组件的派生状态（Derived State）。在该场景中，类组件应应用 getDerivedStateFromProps 钩子办法代替，函数组件应应用函数调用时执行 setState 的形式代替。应用下面两种形式后，React 会将新状态和派生状态在一次更新内实现。
2. 依据 DOM 信息，批改组件状态。在该场景中，除非想方法不依赖 DOM 信息，否则两次更新过程是少不了的，就只能用其余优化技巧了。

use-swr 的源码就应用了该优化技巧。当某个接口存在缓存数据时，use-swr 会先应用该接口的缓存数据，并在 requestIdleCallback 时再从新发动申请，获取最新数据。模仿一个 swr：

1. 它的第二个参数 deps，是为了在申请带有参数时，如果参数扭转了就从新发动申请。
2. 裸露给调用方的 fetch 函数，能够应答被动刷新的场景，比方页面上的刷新按钮。

如果 use-swr 不做该优化的话，就会在 useLayoutEffect 中触发从新验证并设置 isValidating 状态为 true·，引起组件的更新流程，造成性能损失。

工具介绍——React Profiler

React Profiler 定位 Render 过程瓶颈

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

Note：react-dom 16.5+ 在 DEV 模式下才反对 Profiling，同时生产环境下也能够通过一个 profiling bundle react-dom/profiling 来反对。请在 fb.me/react-profi… 上查看如何应用这个 bundle。

“Profiler”的面板在刚开始的时候是空的。你能够点击 record 按钮来启动 profile：

Profiler 只记录了 Render 过程耗时

不要通过 Profiler 定位非 Render 过程的性能瓶颈问题

通过 React Profiler，开发者能够查看组件 Render 过程耗时，但无奈通晓提交阶段的耗时。

只管 Profiler 面板中有 Committed at 字段，但这个字段是绝对于录制开始工夫，基本没有意义。

通过在 React v16 版本上进行试验，同时开启 Chrome 的 Performance 和 React Profiler 统计。

如下图，在 Performance 面板中，Reconciliation 和 Commit 阶段耗时别离为 642ms 和 300ms，而 Profiler 面板中只显示了 642ms：

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

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

而后点击面板中的虚构 DOM 节点，右侧便会展现该组件从新 Render 的起因。

定位产生本次 Render 过程起因

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

在 Profiler 面板左侧的虚构 DOM 树结构中，从上到下审查每个产生了渲染的（不会灰色的）组件。

如果组件是因为 State 或 Hook 扭转触发了 Render 过程，那它就是咱们要找的组件，如下图：

站在伟人的肩膀上

Optimizing Performance React 官网文档，最好的教程, 利用好 React 的性能剖析工具。

Twitter Lite and High Performance React Progressive Web Apps at Scale 看看 Twitter 如何优化的。

-END-