深入浅出FE（六）React性能优化指南

柔光的暖阳◎ 2023-07-17 11:22 111阅读 0赞

## 1.使用纯组件pureCommponent ##

如果 React 组件为相同的状态和 props 渲染相同的输出，则可以将其视为纯组件。

对于像 this 的类组件来说，React 提供了 PureComponent 基类。扩展 React.PureComponent 类的类组件被视为纯组件。

`React.PureComponent` 中以浅层对比 prop 和 state 的方式来实现了该函数。它与普通组件是一样的，只是 PureComponents 负责 shouldComponentUpdate——它对状态和 props 数据进行浅层比较（shallow comparison）。如果浅层比较相同则组件不会重新渲染。

缺点是可能会因深层的数据不一致而产生错误的否定判断。

使用pureCommponent来实现浅比较，比较的是nextProps和nextState,根据最佳实践，PureComponent不仅会影响本身，而且会影响子组件，所以PureComponent最佳情况是展示组件。

1、每次调用React组件都会重新创建组件，就算传入的对象或者值没有改变，他们的引用地址也会改变。style不要写成这样

这样每次渲染时style都是新对象，要将style提前赋值成常量，不要使用自变量

const defaultStyle = {};
    <APP style={
       {this.props.style || defaultStyle}}/>

2、设置props并通过事件绑定在元素上

通过在constructor中设置绑定this，在render中直接使用this.xxx即可

3、设置子组件

当父组件中props变化时，子组件会发生不必要的渲染，可以给子组件设置PureComponent（即react-addons-pure-render-mixin）

，内部会实现shouldComponentUpdate方法，会进行一个浅比较，如果没有变化就不会渲染。

**什么是浅层渲染？**

在对比先前的 props 和状态与下一个 props 和状态时，浅层比较将检查它们的基元是否有相同的值（例如：1 等于 1 或真等于真），还会检查更复杂的 JavaScript 值（如对象和数组）之间的引用是否相同。

比较基元和对象引用的开销比更新组件视图要低。

因此，查找状态和 props 值的变化会比不必要的更新更快。

## 2.使用 React.memo 进行组件记忆 ##

react15.6引入的特性，默认情况下其只会对复杂对象做浅层对比。它会对组件做一个缓存，但是缺点是只会对传入的props做对比。如果你想要控制对比过程，那么请将自定义的比较函数通过第二个参数传入来实现。

# 3.使用shouldCommponentUpdate #

这个原理也和pureComponent类似，主要就是利用nextprops和nextState防止重复渲染，可以在方法内部根据业务逻辑判断当前的props和state来判断组件是否需要更新。

# 4.reselector库 #

可以处理将多个state转化为组件渲染所需要的数据做一些逻辑处理，同时对这些处理过程进行缓存，对较大计算函数有缓存作用。

# 5.connect函数第三第四个参数 #

第三个参数：mergeProps

第四个参数：自定义areStateEqual

# 6.recompose库 #

目的是将组件力度转化为props粒度，根据每个prop变化来渲染组件

@pure props变化才渲染

@onlyUpdateForKeys(\['props1, ''props2'\])

# 7.不要在reder中执行与渲染无关的操作 #

即不要在render中执行计算等逻辑，或者执行一些业务处理，所有业务处理都应该在render之外，render只作为渲染react组件的函数。

# 8.state和props结构要扁平化 #

如题所示

# 9.immutiblejs #

JavaScript 中的对象一般是可变的（Mutable），因为使用了引用赋值，新的对象简单的引用了原始对象，改变新的对象将影响到原始对象。如 \`foo=\{a: 1\}; bar=foo; bar.a=2\` 你会发现此时 \`foo.a\` 也被改成了 \`2\`。虽然这样做可以节约内存，但当应用复杂后，这就造成了非常大的隐患，Mutable 带来的优点变得得不偿失。为了解决这个问题，一般的做法是使用 shallowCopy（浅拷贝）或 deepCopy（深拷贝）来避免被修改，但这样做造成了 CPU 和内存的浪费。

但对immutable对象修改、添加或者删除操作，会返回一个新的inmutable对象，，原理是使用持久化的数据结构，也就是使用旧数据创建新数据时，要保证同时可用且不变。同时为了避免深拷贝把所有节点都复制一遍带来的性能损耗，Immutable使用了结构共享，即如果对象树中一个节点发生变化，只修改这个节点和受他影响的父节点，其他节点则进行共享。

目前流行的 Immutable 库有两个：

1. immutable.js

Facebook 工程师 Lee Byron 花费 3 年时间打造，与 React 同期出现，但没有被默认放到 React 工具集里（React 提供了简化的 Helper）。它内部实现了一套完整的 Persistent Data Structure，还有很多易用的数据类型。像 \`Collection\`、\`List\`、\`Map\`、\`Set\`、\`Record\`、\`Seq\`。有非常全面的\`map\`、\`filter\`、\`groupBy\`、\`reduce\`\`find\`函数式操作方法。同时 API 也尽量与 Object 或 Array 类似。

其中有 3 种最重要的数据结构说明一下：（Java 程序员应该最熟悉了）

*  Map：键值对集合，对应于 Object，ES6 也有专门的 Map 对象
 *  List：有序可重复的列表，对应于 Array
 *  Set：无序且不可重复的列表

2. seamless-immutable

与 Immutable.js 学院派的风格不同，seamless-immutable 并没有实现完整的 Persistent Data Structure，而是使用 \`Object.defineProperty\`（因此只能在 IE9 及以上使用）扩展了 JavaScript 的 Array 和 Object 对象来实现，只支持 Array 和 Object 两种数据类型，API 基于与 Array 和 Object 操持不变。代码库非常小，压缩后下载只有 2K。而 Immutable.js 压缩后下载有 16K。

## Immutable 优点 ##

1. Immutable 降低了 Mutable 带来的复杂度

可变（Mutable）数据耦合了 Time 和 Value 的概念，造成了数据很难被回溯。

比如下面一段代码：

function touchAndLog(touchFn) {
      let data = { key: 'value' };
      touchFn(data);
      console.log(data.key); // 猜猜会打印什么？
    }

在不查看 \`touchFn\` 的代码的情况下，因为不确定它对 \`data\` 做了什么，你是不可能知道会打印什么（这不是废话吗）。但如果 \`data\` 是 Immutable 的呢，你可以很肯定的知道打印的是 \`value\`。

2. 节省内存

Immutable.js 使用了 Structure Sharing 会尽量复用内存。没有被引用的对象会被垃圾回收。

import { Map} from 'immutable';
    let a = Map({
      select: 'users',
      filter: Map({ name: 'Cam' })
    })
    let b = a.set('select', 'people');
    
    a === b; // false
    
    a.get('filter') === b.get('filter'); // true

上面 a 和 b 共享了没有变化的 \`filter\` 节点。

3. Undo/Redo，Copy/Paste，甚至时间旅行这些功能做起来小菜一碟

因为每次数据都是不一样的，只要把这些数据放到一个数组里储存起来，想回退到哪里就拿出对应数据即可，很容易开发出撤销重做这种功能。

后面我会提供 Flux 做 Undo 的示例。

4. 并发安全

传统的并发非常难做，因为要处理各种数据不一致问题，因此『聪明人』发明了各种锁来解决。但使用了 Immutable 之后，数据天生是不可变的，**并发锁就不需要了**。然而现在并没什么卵用，因为 JavaScript 还是单线程运行的啊。但未来可能会加入，提前解决未来的问题不也挺好吗？

5. 拥抱函数式编程

Immutable 本身就是函数式编程中的概念，纯函数式编程比面向对象更适用于前端开发。因为只要输入一致，输出必然一致，这样开发的组件更易于调试和组装。

像 ClojureScript，Elm 等函数式编程语言中的数据类型天生都是 Immutable 的，这也是为什么 ClojureScript 基于 React 的框架 --- Om 性能比 React 还要好的原因。

我们来代码看看二者的不同

// 原来的写法
    let foo = {a: {b: 1}};
    let bar = foo;
    bar.a.b = 2;
    console.log(foo.a.b);  // 打印 2
    console.log(foo === bar);  //  打印 true
    
    // 使用 immutable.js 后
    import Immutable from 'immutable';
    foo = Immutable.fromJS({a: {b: 1}});
    bar = foo.setIn(['a', 'b'], 2);   // 使用 setIn 赋值
    console.log(foo.getIn(['a', 'b']));  // 使用 getIn 取值，打印 1
    console.log(foo === bar);  //  打印 false
    
    // 使用  seamless-immutable.js 后
    import SImmutable from 'seamless-immutable';
    foo = SImmutable({a: {b: 1}})
    bar = foo.merge({a: { b: 2}})   // 使用 merge 赋值
    console.log(foo.a.b);  // 像原生 Object 一样取值，打印 1
    
    console.log(foo === bar);  //  打印 false

## 使用 Immutable 的缺点 ##

1. 需要学习新的 API

No Comments

2. 增加了资源文件大小

No Comments

3. 容易与原生对象混淆

这点是我们使用 Immutable.js 过程中遇到最大的问题。写代码要做思维上的转变。

虽然 Immutable.js 尽量尝试把 API 设计的原生对象类似，有的时候还是很难区别到底是 Immutable 对象还是原生对象，容易混淆操作。

Immutable 中的 Map 和 List 虽对应原生 Object 和 Array，但操作非常不同，比如你要用 \`map.get('key')\` 而不是 \`map.key\`，\`array.get(0)\` 而不是 \`array\[0\]\`。另外 Immutable 每次修改都会返回新对象，也很容易忘记赋值。

当使用外部库的时候，一般需要使用原生对象，也很容易忘记转换。

下面给出一些办法来避免类似问题发生：

*  使用 Flow 或 TypeScript 这类有静态类型检查的工具
 *  约定变量命名规则：如所有 Immutable 类型对象以 \`$$\` 开头。
 *  使用 \`Immutable.fromJS\` 而不是 \`Immutable.Map\` 或 \`Immutable.List\` 来创建对象，这样可以避免 Immutable 和原生对象间的混用。

# 9.使用唯一key #

子组件使用唯一的key，关于使用key的介绍在这里：[https://reactjs.org/docs/lists-and-keys.html][https_reactjs.org_docs_lists-and-keys.html]

### 10.使用hooks ###

通过hooks可以解决大型组件的维护及高阶组件带来的深层嵌套测试问题和一些复杂动画问题，以及自定义hooks的使用。

还有useMemo（缓存值，类似React.momo）和useCallback(缓存函数)可以做缓存。

useMemo和useCallback的关系是：

useCallback(fn, deps) 相当于useMemo(() => fn, deps)

### 11.使用redux中间件 ###

比如redux-saga、redux-thunk或者其他一些库完成异步dispatch

### 12.在reducer使用web worker ###

通过中间件的形式使用web worker，用于改善在reducer中的计算量较大问题

### 13. 为组件创建错误边界 ###

组件渲染错误是很常见的情况。

在这种情况下，组件错误不应该破坏整个应用。创建错误边界可避免应用在特定组件发生错误时中断。

错误边界是一个 React 组件，可以捕获子组件中的 JavaScript 错误。我们可以包含错误、记录错误消息，并为 UI 组件故障提供回退机制。

错误边界是基于高阶组件的概念。

详细信息参阅：[ https://levelup.gitconnected.com/introduction-to-reacts-higher-order-components-hocs-c42182fb634][https_levelup.gitconnected.com_introduction-to-reacts-higher-order-components-hocs-c42182fb634]

错误边界涉及一个高阶组件，包含以下方法：static getDerivedStateFromError() 和 componentDidCatch()。

static 函数用于指定回退机制，并从收到的错误中获取组件的新状态。

componentDidCatch 函数用来将错误信息记录到应用中。

### 14. SSR ###

使用服务端渲染能能节省代码量，有利于seo及首屏加载时间的优化。

### 15.事件节流和防抖 ###

节流（throttling）和防抖（debouncing）可用来限制在指定时间内调用的事件处理程序的数量。

事件处理程序是响应不同事件（如鼠标单击和页面滚动）而调用的函数。事件触发事件处理程序的速率是不一样的。

节流的概念

节流意味着延迟函数执行。

这些函数不会立即执行，在触发事件之前会加上几毫秒延迟。

比如在页面滚动时，我们不会过于频繁地触发滚动事件，而是将事件延迟一段时间以便将多个事件堆叠在一起。

它确保函数在特定时间段内至少调用一次。如果函数最近运行过了，它将阻止函数运行，确保函数以固定间隔定期运行。

当我们处理无限滚动并且当用户接近页面底部必须获取数据时，我们可以使用节流。

### 16.使用 CDN ###

CDN 是可在你的应用中使用的外部资源。我们甚至可以创建私有 CDN 并托管我们的文件和资源。

使用 CDN 有以下好处：

*  **不同的域名**。浏览器限制了单个域名的并发连接数量，具体取决于浏览器设置。假设允许的并发连接数为 10。如果要从单个域名中检索 11 个资源，那么同时完成的只有 10 个，还有 1 个需要再等一会儿。CDN 托管在不同的域名 / 服务器上。因此资源文件可以分布在不同的域名中，提升了并发能力。
 *  **文件可能已被缓存**。有很多网站使用这些 CDN，因此你尝试访问的资源很可能已在浏览器中缓存好了。这时应用将访问文件的已缓存版本，从而减少脚本和文件执行的网络调用和延迟，提升应用性能。
 *  **高容量基础设施**。这些 CDN 由大公司托管，因此可用的基础设施非常庞大。他们的数据中心遍布全球。向 CDN 发出请求时，它们将通过最近的数据中心提供服务，从而减少延迟。这些公司会对服务器做负载平衡，以确保请求到达最近的服务器并减少网络延迟，提升应用性能。

如果担心安全性，可以使用私有 CDN。

### 17. 用 CSS 动画代替 JavaScript 动画 ###

在 HTML 5 和 CSS 3 出现之前，动画曾经是 JavaScript 的专属，但随着 HTML 5 和 CSS 3 的引入情况开始变化。现在动画甚至可以由 CSS 3 来处理了。

我们可以制定一些规则：

*  如果 CSS 可以实现某些 JS 功能，那就用 CSS。
 *  如果 HTML 可以实现某些 JS 功能，那就用 HTML。

理由如下：

1.  破损的 CSS 规则和样式不会导致网页损坏，而 JavaScript 则不然。
2.  解析 CSS 是非常便宜的，因为它是声明性的。我们可以为样式并行创建内存中的表达，可以推迟样式属性的计算，直到元素绘制完成。
3.  为动画加载 JavaScript 库的成本相对较高，消耗更多网络带宽和计算时间。
4.  虽然 JavaScript 可以提供比 CSS 更多的优化，但优化过的 JavaScript 代码也可能卡住 UI 并导致 Web 浏览器崩溃。

详细信息参阅：[ https://developers.google.com/web/fundamentals/design-and-ux/animations/css-vs-javascript][https_developers.google.com_web_fundamentals_design-and-ux_animations_css-vs-javascript]

### 18. 在 Web 服务器上启用 gzip 压缩 ###

压缩是节省网络带宽和加速应用的最简单方法。

我们可以把网络资源压缩到更小的尺寸。Gzip 是一种能够快速压缩和解压缩文件的数据压缩算法。

它可以压缩几乎所有类型的文件，例如图像、文本、JavaScript 文件、样式文件等。Gzip 减少了网页需要传输到客户端的数据量。

当 Web 服务器收到请求时，它会提取文件数据并查找 Accept-Encoding 标头以确定如何压缩应用。

如果服务器支持 gzip 压缩，资源会被压缩后通过网络发送。每份资源的压缩副本（添加了 Content-Encoding 标头）指定使用 gzip 解压。

然后，浏览器将内容解压缩原始版本在渲染给用户。

只是 gzip 压缩需要付出成本，因为压缩和解压缩文件属于 CPU 密集型任务。但我们还是建议对网页使用 gzip 压缩。

详细信息参阅：[ https://royal.pingdom.com/can-gzip-compression-really-improve-web-performance][https_royal.pingdom.com_can-gzip-compression-really-improve-web-performance]

### 19.[Ramda][]  ###

是一个由许多高阶函数组成、功能强大的函数库。换句话说，就是许多用于创建函数的函数。由于我们的映射函数也不过只是函数而已，所以我们可以利用 Ramda 方便地创建 selectors。Ramda 可以完成所有 selectors 可以完成的工作，而且还不止于此。[Ramda cookbook][] 中介绍了一些 Ramda 的应用示例。

具体可以参见阮一峰写的这篇内容[http://www.ruanyifeng.com/blog/2017/03/ramda.html][http_www.ruanyifeng.com_blog_2017_03_ramda.html]

### 20.懒加载组件 ###

导入多个文件合并到一个文件中的过程叫打包，使应用不必导入大量外部文件。

所有主要组件和外部依赖项都合并为一个文件，通过网络传送出去以启动并运行 Web 应用。

这样可以节省大量网络调用，但这个文件会变得很大，消耗大量网络带宽。

应用需要等待这个文件的加载和执行，所以传输延迟会带来严重的影响。

为了解决这个问题，我们引入代码拆分的概念。

像 webpack 这样的打包器支持就支持代码拆分，它可以为应用创建多个包，并在运行时动态加载，减少初始包的大小。

为此我们使用 React的API ---Suspense 和 lazy这种新的api避免首次渲染页面加载大量代码块，只引入我们需要的代码块。

或者使用Loadable等库来实现懒加载。

参考书目：

1.《深入react技术栈》

2.《react状态管理与同构实践》

3.《react进阶之路》

4.《react设计模式与最佳实践》

可以加我vx：一起学习前端开发，一起成长。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTQ3NDQxMTg_size_16_color_FFFFFF_t_70][]

[https_reactjs.org_docs_lists-and-keys.html]: https://reactjs.org/docs/lists-and-keys.html
[https_levelup.gitconnected.com_introduction-to-reacts-higher-order-components-hocs-c42182fb634]: https://levelup.gitconnected.com/introduction-to-reacts-higher-order-components-hocs-c42182fb634
[https_developers.google.com_web_fundamentals_design-and-ux_animations_css-vs-javascript]: https://developers.google.com/web/fundamentals/design-and-ux/animations/css-vs-javascript
[https_royal.pingdom.com_can-gzip-compression-really-improve-web-performance]: https://royal.pingdom.com/can-gzip-compression-really-improve-web-performance
[Ramda]: https://link.juejin.im/?target=http%3A%2F%2Framdajs.com%2F
[Ramda cookbook]: https://link.juejin.im?target=https%3A%2F%2Fgithub.com%2Framda%2Framda%2Fwiki%2FCookbook
[http_www.ruanyifeng.com_blog_2017_03_ramda.html]: http://www.ruanyifeng.com/blog/2017/03/ramda.html
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTQ3NDQxMTg_size_16_color_FFFFFF_t_70]: /images/20230528/644e13b3812a407ca70cb9329783c160.png