本文分为三部分,首先介绍 React 的工作流,让读者对 React 组件更新流程有宏观的认识。然后列出笔者总结的一系列优化技巧,并为稍复杂的优化技巧准备了 CodeSandbox 源码,以便读者实操体验。最后分享笔者使用 React Profiler 的一点心得,帮助读者更快定位性能瓶颈。
清水河ssl适用于网站、小程序/APP、API接口等需要进行数据传输应用场景,ssl证书未来市场广阔!成为创新互联的ssl证书销售渠道,可以享受市场价格4-6折优惠!如果有意向欢迎电话联系或者加微信:13518219792(备注:SSL证书合作)期待与您的合作!
React 是声明式 UI 库,负责将 State 转换为页面结构(虚拟 DOM 结构)后,再转换成真实 DOM 结构,交给浏览器渲染。当 State 发生改变时,React 会先进行调和(Reconciliation)阶段,调和阶段结束后立刻进入提交(Commit)阶段,提交阶段结束后,新 State 对应的页面才被展示出来。
React 的调和阶段需要做两件事。1、计算出目标 State 对应的虚拟 DOM 结构。2、寻找「将虚拟 DOM 结构修改为目标虚拟 DOM 结构」的最优更新方案。 React 按照深度优先遍历虚拟 DOM 树的方式,在一个虚拟 DOM 上完成两件事的计算后,再计算下一个虚拟 DOM。第一件事主要是调用类组件的 render 方法或函数组件自身。第二件事为 React 内部实现的 Diff 算法,Diff 算法会记录虚拟 DOM 的更新方式(如:Update、Mount、Unmount),为提交阶段做准备。
React 的提交阶段也需要做两件事。1、将调和阶段记录的更新方案应用到 DOM 中。2、调用暴露给开发者的钩子方法,如:componentDidUpdate、useLayoutEffect 等。 提交阶段中这两件事的执行时机与调和阶段不同,在提交阶段 React 会先执行 1,等 1 完成后再执行 2。因此在子组件的 componentDidMount 方法中,可以执行 document.querySelector('.parentClass') ,拿到父组件渲染的 .parentClass DOM 节点,尽管这时候父组件的 componentDidMount 方法还没有被执行。useLayoutEffect 的执行时机与 componentDidMount 相同,可参考线上代码进行验证。
由于调和阶段的「Diff 过程」和提交阶段的「应用更新方案到 DOM」都属于 React 的内部实现,开发者能提供的优化能力有限,本文仅有一条优化技巧(列表项使用 key 属性[1])与它们有关。实际工程中大部分优化方式都集中在调和阶段的「计算目标虚拟 DOM 结构」过程,该过程是优化的重点,React 内部的 Fiber 架构和并发模式也是在减少该过程的耗时阻塞。对于提交阶段的「执行钩子函数」过程,开发者应保证钩子函数中的代码尽量轻量,避免耗时阻塞,相关的优化技巧参考本文的避免在 didMount、didUpdate 中更新组件 State[2]。
拓展知识
本文为了叙述方便, 将调和阶段中「计算目标虚拟 DOM 结构」过程称为 Render 过程 。触发 React 组件的 Render 过程目前有三种方式,分别为 forceUpdate、State 更新、父组件 Render 触发子组件 Render 过程。
本文将优化技巧分为三大类,分别为:
这类优化是在组件状态发生变更后,通过减少不必要的组件更新来实现,是本文优化技巧的主要部分。
1. PureComponent、React.memo
在 React 工作流中,如果只有父组件发生状态更新,即使父组件传给子组件的所有 Props 都没有修改,也会引起子组件的 Render 过程。从 React 的声明式设计理念来看,如果子组件的 Props 和 State 都没有改变,那么其生成的 DOM 结构和副作用也不应该发生改变。当子组件符合声明式设计理念时,就可以忽略子组件本次的 Render 过程。PureComponent 和 React.memo 就是应对这种场景的,PureComponent 是对类组件的 Props 和 State 进行浅比较,React.memo 是对函数组件的 Props 进行浅比较。
2. shouldComponentUpdate
在 React 刚开源的那段时期,数据不可变性还没有现在这样流行。当时 Flux 架构就使用的模块变量来维护 State,并在状态更新时直接修改该模块变量的属性值,而不是使用展开语法[5]生成新的对象引用。例如要往数组中添加一项数据时,当时的代码很可能是 state.push(item),而不是 const newState = [...state, item]。这点可参考 Dan Abramov 在演讲 Redux 时[6]演示的 Flux 代码。
在此背景下,当时的开发者经常使用 shouldComponentUpdate 来深比较 Props,只在 Props 有修改才执行组件的 Render 过程。如今由于数据不可变性和函数组件的流行,这样的优化场景已经不会再出现了。
接下来介绍另一种可以使用 shouldComponentUpdate 来优化的场景。在项目初始阶段,开发者往往图方便会给子组件传递一个大对象作为 Props,后面子组件想用啥就用啥。当大对象中某个「子组件未使用的属性」发生了更新,子组件也会触发 Render 过程。在这种场景下,通过实现子组件的 shouldComponentUpdate 方法,仅在「子组件使用的属性」发生改变时才返回 true,便能避免子组件重新 Render。
但使用 shouldComponentUpdate 优化第二个场景有两个弊端。
B 组件的 shouldComponentUpdate 中只比较了 data.a 和 data.b,目前是没任何问题的。之后开发者想在 C 组件中使用 data.c,假设项目中 data.a 和 data.c 是一起更新的,所以也没任何问题。但这份代码已经变得脆弱了,如果某次修改导致 data.a 和 data.c 不一起更新了,那么系统就会出问题。而且实际业务中代码往往更复杂,从 B 到 C 可能还有若干中间组件,这时就很难想到是 shouldComponentUpdate 引起的问题了。
拓展知识
1. 第二个场景最好的解决方案是使用发布者订阅者模式,只是代码改动要稍多一些,可参考本文的优化技巧「发布者订阅者跳过中间组件 Render 过程[7]」。
2. 第二个场景也可以在父子组件间增加中间组件,中间组件负责从父组件中选出子组件关心的属性,再传给子组件。相比于 shouldComponentUpdate 方法,会增加组件层级,但不会有第二个弊端。
3. 本文中的跳过回调函数改变触发的 Render 过程[8]也可以用 shouldComponentUpdate 实现,因为回调函数并不参与组件的 Render 过程。
3. useMemo、useCallback 实现稳定的 Props 值
如果传给子组件的派生状态或函数,每次都是新的引用,那么 PureComponent 和 React.memo 优化就会失效。所以需要使用 useMemo 和 useCallback 来生成稳定值,并结合 PureComponent 或 React.memo 避免子组件重新 Render。
拓展知识
useCallback 是「useMemo 的返回值为函数」时的特殊情况,是 React 提供的便捷方式。在 React Server Hooks 代码[9] 中,useCallback 就是基于 useMemo 实现的。尽管 React Client Hooks 没有使用同一份代码,但 useCallback[10] 的代码逻辑和 useMemo[11] 的代码逻辑仍是一样的。
4. 发布者订阅者跳过中间组件 Render 过程
React 推荐将公共数据放在所有「需要该状态的组件」的公共祖先上,但将状态放在公共祖先上后,该状态就需要层层向下传递,直到传递给使用该状态的组件为止。
每次状态的更新都会涉及中间组件的 Render 过程,但中间组件并不关心该状态,它的 Render 过程只负责将该状态再传给子组件。在这种场景下可以将状态用发布者订阅者模式维护,只有关心该状态的组件才去订阅该状态,不再需要中间组件传递该状态。当状态更新时,发布者发布数据更新消息,只有订阅者组件才会触发 Render 过程,中间组件不再执行 Render 过程。
只要是发布者订阅者模式的库,都可以进行该优化。比如:redux、use-global-state、React.createContext 等。例子参考:发布者订阅者模式跳过中间组件的渲染阶段[12],本示例使用 React.createContext 进行实现。
- import { useState, useEffect, createContext, useContext } from "react"
- const renderCntMap = {}
- const renderOnce = name => {
- return (renderCntMap[name] = (renderCntMap[name] || 0) + 1)
- }
- // 将需要公共访问的部分移动到 Context 中进行优化
- // Context.Provider 就是发布者
- // Context.Consumer 就是消费者
- const ValueCtx = createContext()
- const CtxContainer = ({ children }) => {
- const [cnt, setCnt] = useState(0)
- useEffect(() => {
- const timer = window.setInterval(() => {
- setCnt(v => v + 1)
- }, 1000)
- return () => clearInterval(timer)
- }, [setCnt])
- return
{children} - }
- function CompA({}) {
- const cnt = useContext(ValueCtx)
- // 组件内使用 cnt
- return
组件 CompA Render 次数:{renderOnce("CompA")}- }
- function CompB({}) {
- const cnt = useContext(ValueCtx)
- // 组件内使用 cnt
- return
组件 CompB Render 次数:{renderOnce("CompB")}- }
- function CompC({}) {
- return
组件 CompC Render 次数:{renderOnce("CompC")}- }
- export const PubSubCommunicate = () => {
- return (
优化后场景
- 将状态提升至最低公共祖先的上层,用 CtxContainer 将其内容包裹。
- 每次 Render 时,只有组件A和组件B会重新 Render 。
- 父组件 Render 次数:{renderOnce("parent")}
- )
- }
- export default PubSubCommunicate
- 复制代码
5. 状态下放,缩小状态影响范围
如果一个状态只在某部分子树中使用,那么可以将这部分子树提取为组件,并将该状态移动到该组件内部。如下面的代码所示,虽然状态 color 只在 和
中使用,但 color 改变会引起
- import { useState } from "react"
- export default function App() {
- let [color, setColor] = useState("red")
- return (
- setColor(e.target.value)} />
Hello, world!
- )
- }
- function ExpensiveTree() {
- let now = performance.now()
- while (performance.now() - now < 100) {
- // Artificial delay -- do nothing for 100ms
- }
- return
I am a very slow component tree.
- }
- 复制代码
通过将 color 状态、 和
提取到组件 Form 中,结果如下。
- export default function App() {
- return (
- <>
- >
- )
- }
- function Form() {
- let [color, setColor] = useState("red")
- return (
- <>
- setColor(e.target.value)} />
Hello, world!
- >
- )
- }
- 复制代码
这样调整之后,color 改变就不会引起组件 App 和 ExpensiveTree 重新 Render 了。
如果对上面的场景进行扩展,在组件 App 的顶层和子树中都使用了状态 color ,但
- import { useState } from "react"
- export default function App() {
- let [color, setColor] = useState("red")
- return (
- setColor(e.target.value)} />
Hello, world!
- )
- }
- 复制代码
在这种场景中,我们仍然将 color 状态抽取到新组件中,并提供一个插槽来组合
- import { useState } from "react"
- export default function App() {
- return
}> - }
- function ColorContainer({ expensiveTreeNode }) {
- let [color, setColor] = useState("red")
- return (
- setColor(e.target.value)} />
- {expensiveTreeNode}
Hello, world!
- )
- }
- 复制代码
这样调整之后,color 改变就不会引起组件 App 和 ExpensiveTree 重新 Render 了。
该优化技巧来源于 before-you-memo[13],Dan 认为这种优化方式在 Server Component 场景下更有效,因为
6. 列表项使用 key 属性
当渲染列表项时,如果不给组件设置不相等的属性 key,就会收到如下报警。
相信很多开发者已经见过该报警成百上千次了,那 key 属性到底在优化了什么呢?举个 ,在不使用 key 时,组件两次 Render 的结果如下。
- Duke
- Villanova
- Connecticut
- Duke
- Villanova
- 复制代码
此时 React 的 Diff 算法会按照
如果加上 React 的 key 属性,两次 Render 结果如下。
- Duke
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 结果如下。
- dataA
切换到第二页后,由于所有
尽管存在以上场景,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 相比有以下优势:
例子参考: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 (
- 组件「{name}」 Render 次数:{renderCntMap[name]}
- )
- }
- 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
- }, [])
- return (
- {comp}
- )
- }
- 复制代码
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 (
- 跳过『与 Render 无关的 Props』改变触发的重新 Render
- Render 次数为:{++renderCnt}
- 点我回调,回调弹出值为 1000(优化成功)
- )
- }
- 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]
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 (
set(state => !state)}>- Render 次数:{++renderCnt}
- class="c back"
- style={{ opacity: opacity.interpolate(o => 1 - o), transform }}
- />
- class="c front"
- style={{
- opacity,
- transform: transform.interpolate(t => `${t} rotateX(180deg)`),
- }}
- />
- )
- }
- 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
分享题目:React 性能优化 :包括原理、技巧、Demo、工具使用
浏览路径:http://www.shufengxianlan.com/qtweb/news25/100525.html网站建设、网络推广公司-创新互联,是专注品牌与效果的网站制作,网络营销seo公司;服务项目有等
声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 创新互联