浅谈React组件之性能优化

高德纳: "我们应该忘记忽略很小的性能优化,可以说97%的情况下,过早的优化是万恶之源,而我们应该关心对性能影响最关键的另外3%的代码。"

不要将性能优化的精力浪费在对整体性能提高不大的代码上,而对性能有关键影响的部分,优化并不嫌早。因为,对性能影响最关键的部分,往往涉及解决方案核心,决定整体的架构,将来要改变的时候牵扯更大。

1. 单个React组件的性能优化

React利用Virtual DOM来提升渲染性能,虽然每一次页面更新都是最组件的从新渲染,但是并不是将之前的渲染内容全部抛弃重来,借助Virtual DOM,React能够计算出对DOM树的最少修改,这就是React默认情况下渲染都很迅速的秘诀;

不过,虽然Virtual DOM能够将每次DOM操作量减少到最小,但,计算和比较Virtual DOM依然是一个复杂的过程;

当然,如果能够在开始计算Virtual DOM之前就判断渲染的结果不会有变化,那么就可以不进行Virtual DOM计算和比较,速度就会更快。

2.shouldComponentUpdate的默认实现方式

既然可以对组件在开始计算Virtual DOM之前判断渲染结果不会有变化时,阻止渲染的进行,从而提升性能,那么我们自然想到使用shouldComponentUpdate(nextProp,nextState)

shouldComponentUpdate函数在render函数之前调用,决定“什么时候不需要从新渲染”;

即返回一个布尔值,决定更新是否进行下去,默认返回true,若返回false则中断更新;

shouldComponentUpdate(nextProp,nextState){
  return (nextProp.completed !== this.props.completed) ||
    (nextProp.text !== this.props.text)
}

其中nextProps为此次更新传入的props,对于这个组件,影响渲染内容的prop只有completed和text,只要确保这两个prop没有变化,shouldComponentUpdate就可以返回false阻止没必要的更新

但是,上述的比较只是‘浅层比较',如果类型是基本类型,只要值相同,那么“浅层比较”

也会认为二者相同:

那,如果prop的类型是复杂的对象怎么办?

对于复杂对象,‘浅层比较'的方式只看这两个prop是不是同一个对象的引用,如果不是,哪怕对象中的内容完全一样也会认为是不同的两个prop。那么使用“深层比较”:但对对象的结构是无法预知的,如果递归对每个字段都进行“深层比较”,不光会让代码更加复杂,也可能会造成性能问题。

所以,要想判断前后的对象类型的prop是相同的,就必须要保证prop是指向同一个JavaScript对象:

<Foo styleProp = {{color: "red"}}>

要避免使用上面的传入方式,应为每次渲染都会重新创建{color: "red"}对象,引用地址每次都不同,将导致每次的styleProp都不同。

const footStyle = {color: "red"};//确保这个初始化只执行一次,不要放在render函数中
<Foo styleProp = {footStyle}>

使用‘单例模式'确保传入的styleProp指向同一个对象

如果是函数呢?

<Foo onToggle={() => onToggleTodo(item.id)}/>

应该避免使用上面的函数传递模式,因为这里赋值的是一个匿名函数,而且是在赋值的时候产生的,也就是说每次渲染都会产生一个新的函数,这就是问题所在。

如果要传递的prop很多呢?

恩~~用React-Redux的话,有对shouldComponentUpdate的默认实现。

3. 对多个React组件的性能优化

当一个React组件被装载、更新和卸载时,组件的一序列生命周期函数会被调用。不过,这些生命周期函数是针对一个特定的React组件函数,在一个应用中,从上而下有很多React组件组合起来,它们之间的渲染过程要更加复杂。

同样一个组件的渲染过程也要考虑三个过程:装载阶段、更新阶段、卸载阶段

对于装载阶段,组件无论如何都要彻底渲染一次,从这个React组件往下的所有子组件,都要经历一遍React组件的装载生命
周期,所以并没有多少优化的事情可做。

对于卸载阶段,只有一个生命周期函数componentWillUnmount,这个函数只是清理componentDidMount添加的事件处理监听等收尾工作,所以,也没有什么可优化的空间;

4. React更新阶段的调和(Reconciliation)过程

在组件更新过程,会构建更新Virtual DOM,并将其与之前的Virtual DOM进行比较,从而找出不同之处,使用最少的DOM操作进行更新

调和过程:即React更新中对Virtual DOM找不同的过程,通常对比两个N个节点的树形结构的算法,时间复杂度是O(n*3),如果直接

使用默认对比,节点过多的话,需要操作的数量太多,而React不可能采用这种算法;

React实际采用的算法时间复杂度是O(N)(时间复杂度只是对一个算法最好和最差情况下需要的指令操作数量级的估量)

React的Reconciliation算法并不复杂,首先检查两个树形的根节点的类型是否相同,根据相同或者不同有不同的处理方式:

节点类型不同的情况

如果树形节点的类型不相同,那就意味着改动很大,直接认为原来的那个树形结构已经没用,可以扔掉,需要从新构建DOM树,原有的树形上的React组件便会经历“卸载”的生命周期;

也就是说,对于Virtual DOM树这是一个“更新”过程,但是却可能引发这个树结构上某些组件的“装载”和“卸载”过程
如:

更新前

 <div>
  <Todos />
 </div>

我们想要更新成这样:

 <span>
   <Todos />
 </span>

>1. 那么在作比较的时候,一看根节点原来是div,新的是span,类型就不一样了,那么这个算法就废弃之前的div包括里面的所有子节点,从新构建一个span节点和子节点;

>2. 很明显因为根节点不同就将所有的子节点从新构建,这很浪费,但是为了避免O(N*3)的时间复杂度,React这能选择这种比较简单、快捷的方法;

>3. 所以,作为开发者,我们一定要避免上面的浪费的情景出现

节点类型相同的情况

如果两个节点类型相同时,对于DOM元素,React会保留节点对应的DOM元素,只对其节点的属性和内容做对比,然后只修改更新的部分;

节点类型相同时,对于React组件类型,React做得是根据新节点的props去更新节点的组件实例,引发组件的更新过程;

在处理完根节点对比后,React的算法会对根节点的每一个子节点重复一样的操作

多个相同子组件的情况

如果最初组件状态为:

<ul>
  <TodoItem text = "First" />
  <TodoItem text = "Second" />

</ul>

更新后为:

<ul>
  <TodoItem text = "First" />
  <TodoItem text = "Second" />
  <TodoItem text = "Third" />
</ul>

那么React会创建一个新的TodoItem组件实例,而前两个则进行正常的更新过程但是,如果更新后为:

<ul>
  <TodoItem text = "Zero" />
  <TodoItem text = "First" />
  <TodoItem text = "Second" />

</ul>

(这将暴露一个问题)理想处理方式是,创建一个新的TodoItem组件实例放在第一位,后两个进入自然更新过程
但是要让react按照这种方式,就必须找两个子组件的不同之处,而现有计算两个序列差异的算法时间是O(N*2),显然则
不适合对性能要求很高的场景,所以React选择了一个看起来很傻的办法,即挨个比较每个子组件;

React首先认为把text为First的组件的text改为Zero,Second的改为First,最后创建一个text为Second的组件,这样便会破原有的两个组件完成一个更新过程,并创建一个text为Second的新组件

这显然是一个浪费,React也意到,并提供了方克服,不过需要开发人员提供一点帮助,这就是key

Key的使用

key属性可以明确的告诉React每个组件的唯一标识

如果最初组件状态为:

<ul>
  <TodoItem key={1} text = "First" />
  <TodoItem key={2} text = "Second" />

</ul>

更新后为:

<ul>
  <TodoItem key={0} text = "Zero" />
  <TodoItem key={1} text = "First" />
  <TodoItem key={2} text = "Second" />
</ul>

因为有唯一标识key,React可以根据key值,知道现在的第二和第三个组件就是之前的第一和第二个,便用原来的props启动更新过程,这样shouldComponentUpdate就会发生作用,避免无谓的更新;

注意:因为作为组件的唯一标识,所以key必须唯一,且不可变

下面的代码是错误的例子:

<ul>
  todos.map((item,index) => {
      <TodoItem
        key={index}
        text={item.text}
      />
    })
</ul>

使用数组下标作为key值,看起来唯一,但不稳定,因为随着todos数组值的不同,同样一个组件实例在不同的更新过程中数组的下标完全可能不同,把下标当做可以就会让React乱套,记住key不仅要唯一还要确保稳定不可变

需要注意:虽然key是一个prop,但是接受key的组件不能读取key的值,因为key和ref是React保留的两个特殊prop,并没有预期让组将直接访问。

以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持我们。

您可能感兴趣的文章:

  • 使用store来优化React组件的方法
时间: 2018-02-27

使用store来优化React组件的方法

在使用 React 编写组件的时候,我们常常会碰到两个不同的组件之间需要共享状态情况,而通常的做法就是提升状态到父组件.但是这样做会有一个问题,就是尽管只有两个组件需要这个状态,但是因为把状态提到了父组件,那么在状态变化的时候,父组件以及其下面的所有子组件都会重新 render,如果你的父组件比较复杂,包含了其他很多子组件的话,就有可能引起性能问题. Redux 通过把状态放在全局的 store 里,然后组件去订阅各自需要的状态,当状态发生变化的时候,只有那些订阅的状态发生变化的组件才重新 r

用react-redux实现react组件之间数据共享的方法

上篇文章写到了redux实现组件数据共享的方法,但是在react中,redux作者提供了一个更优雅简便的模块实现react组件之间数据共享.那就是利用react-redux 利用react-redux实现react组件数据之间数据共享 1.安装react-redux $ npm i --save react-redux 2.从react-redux导入Prodiver组件将store赋予Provider的store属性, 将根组件用Provider包裹起来. import {Provider,c

react性能优化达到最大化的方法 immutable.js使用的必要性

一行代码胜过千言万语.这篇文章呢,主要讲述我一步一步优化react性能的过程,为什么要用immutable.js呢.毫不夸张的说.有了immutable.js(当然也有其他实现库)..才能将react的性能发挥到极致!要是各位看官用过一段时间的react,而没有用immutable那么本文非常适合你.那么我开始吧! 1.对于react的来说,如果父组件有多个子组件 想象一下这种场景,一个父组件下面一大堆子组件.然后呢,这个父组件re-render.是不是下面的子组件都得跟着re-render.可

为react组件库添加typescript类型提示的方法

以我自己的组件react-better-countdown为例, 首先在package.json里面添加types: types/index.d.ts, , 然后文件目录上添加对应文件夹和文件, 最后是index.d.ts文件的编写,具体看代码: import * as React from 'react'; interface CountdownProps { count?: number; dayText?: string | React.ReactElement; hourText?: s

React教程之封装一个Portal可复用组件的方法

Portal简介 所以我们需要的一个通用组件,它做如下的事情: 可以声明式的写在一个组件中 并不真正render在被声明的地方 支持过渡动画 那么,像modal.tooltip.notification等组件都是可以基于这个组件的.我们叫这个组件为Portal. 使用了React16+的你,对Portal至少有所了解或者熟练使用. Portal可以创建一个在你的root元素之外的DOM. 1.通常你的网站只有一个root <body> <div id="root"&g

react 组件传值的三种方法

整理 react 组件传值 三种方式 父组件向子组件传值(通过props传值) 子组件: class Children extends Component{ constructor(props){ super(props); } render(){ return( <div>这是:{this.props.name}</div> // 这是 父向子 ) } } 父组件: class App extends React.Component{ render(){ return( <

React组件对子组件children进行加强的方法

问题 如何对组件的children进行加强,如:添加属性.绑定事件,而不是使用<div>{this.props.children}</div>在<div>上进行处理. 前车之鉴 今天写组件遇到这个问题,在网上查阅了很多资料,都说可以使用React.cloneElement进行处理,但是结果并不是预期想要的. 先看看这个东西有什么用: React.cloneElement(element, [props], [...childrn]) 根据React官网的说法,以上代码等

React组件的三种写法总结

React 专注于 view 层,组件化则是 React 的基础,也是其核心理念之一,一个完整的应用将由一个个独立的组件拼装而成. 截至目前 React 已经更新到 v15.4.2,由于 ES6 的普及和不同业务场景的影响,我们会发现目前主要有三种创建 React 组件的写法:1. ES5写法React.createClass,2. ES6写法React.Component,3. 无状态的函数式写法(纯组件-SFC). 你们最钟爱哪种写法呢?萝卜青菜各有所爱~ 每个团队都有自己的代码规范和开发模

编写React组件项目实践分析

当我刚开始写React的时候,我看过很多写组件的方法.一百篇教程就有一百种写法.虽然React本身已经成熟了,但是如何使用它似乎还没有一个"正确"的方法.所以我(作者)把我们团队这些年来总结的使用React的经验总结在这里.希望这篇文字对你有用,不管你是初学者还是老手. 开始前: 我们使用ES6.ES7语法如果你不是很清楚展示组件和容器组件的区别,建议您从阅读这篇文章开始如果您有任何的建议.疑问都清在评论里留言 基于类的组件 现在开发React组件一般都用的是基于类的组件.下面我们就来