正式学习 React(三)番外篇 reactjs性能优化之shouldComponentUpdate

性能优化

每当开发者选择将React用在真实项目中时都会先问一个问题:使用react是否会让项目速度更快,更灵活,更容易维护。此外每次状态数据发生改变时都会进行重新渲染界面的处理做法会不会造成性能瓶颈?而在react内部则是通过使用一些精妙的技巧来最小化每次造成ui更新的昂贵的dom操作从而保证性能的。

避免直接作用于DOM

react实现了一层虚拟dom,它用来映射浏览器的原生dom树。通过这一层虚拟的dom,可以让react避免直接操作dom,因为直接操作浏览器dom的速度要远低于操作JavaScript对象。每当组件的属性或者状态发生改变时,react会在内存中构造一个新的虚拟dom与原先老的进行对比,用来判断是否需要更新浏览器的dom树,这样就尽可能的优化了渲染dom的性能损耗。

在此之上,react提供了组件生命周期函数,shouldComponentUpdate,组件在决定重新渲染(虚拟dom比对完毕生成最终的dom后)之前会调用该函数,该函数将是否重新渲染的权限交给了开发者,该函数默认直接返回true,表示默认直接出发dom更新:

shouldComponentUpdate: function(nextProps, nextState) {
      return true;
}

值得注意的是,react会非常频繁的调用该函数,所以如果你打算自己实现该函数的逻辑,请尽可能保证性能。

比方说,你有一个拥有多个帖子的聊天应用,如果此时只有一个发生了变化,如果你如下实现了shouldComponentUpdate,react会根据情况避免重新渲染那些没有发生变化的帖子:

shouldComponentUpdate: function(nextProps, nextState) {
      // TODO: return whether or not current chat thread is different to former one.
      // 根据实际情况判断当前帖子的状态是否和之前不同
}

总之,react尽可能的避免了昂贵的dom操作,并且允许开发者干涉该行为。

shouldComponentUpdate实战

这里举个包含子元素的组件例子,如下图:

图中每个圆点表示一个dom节点,当某个dom节点的shouldComponentUpdate返回false时(例如c2),react就无需为其更新dom,注意,react甚至根本不会去调用c4和c5节点的shouldComponentUpdate函数哦~

图中c1和c3的shouldComponentUpdate返回了true,因此react会检查检查其它们包含的直接子节点。最有趣的是c8节点,虽然调用它的shouldComponentUpdate方法返回的是true,但react检查后发现其dom结构并未发生改变,所以react最终是不会重新渲染其浏览器dom的。

上图的情况下,react最终只会重新渲染c6,原因你应该懂的。

那么我们应该如何实现shouldComponentUpdate函数呢?假设你有一个只包含字符串的组件,如下:

React.createClass({
      propTypes: {
        value: React.PropTypes.string.isRequired
      },

      render: function() {
        return <div>{this.props.value}</div>;
      }
});

我们可以简单的直接实现shouldComponentUpdate如下:

shouldComponentUpdate: function(nextProps, nextState) {
      return this.props.value !== nextProps.value;
}

目前为止一切都很顺利,处理基础类型的属性和状态是很简单的,我们可以直接使用js语言提供的===比对来实现一个mix并注入到所有组件中,事实上,react自身已经提供了一个类似的:PureRenderMixin

但是如果你的组件所拥有的属性或状态不是基础类型呢,而是复合类型呢?比方说是一个js对象,{foo: ‘bar‘}

React.createClass({
      propTypes: {
        value: React.PropTypes.object.isRequired
      },

      render: function() {
        return <div>{this.props.value.foo}</div>;
      }
});

这种情况下我们刚才实现的那种shouldComponentUpdate就歇菜了:

// 假设 this.props.value 是 { foo: ‘bar‘ }
// 假设 nextProps.value 是 { foo: ‘bar‘ },
// 但是nextProps和this.props对应的引用不相同
this.props.value !== nextProps.value; // true

要想修复这个问题,简单粗暴的方法是我们直接比对foo的值,如下:

shouldComponentUpdate: function(nextProps, nextState) {
      return this.props.value.foo !== nextProps.value.foo;
}

我们当然可以通过深比对来确定属性或状态是否确实发生了改变,但是这种深比对是非常昂贵的,还记得我们刚出说过shouldComponentUpdate函数的调用非常频繁么?更何况我们为每个model去单独实现一个匹配的深比对逻辑,对于开发人员来说也是非常痛苦的。最重要的是,如果我们不是很小心的处理对象引用关系的话,还会带来灾难。例如下面这个组件:

React.createClass({
      getInitialState: function() {
        return { value: { foo: ‘bar‘ } };
      },

      onClick: function() {
        var value = this.state.value;
        value.foo += ‘bar‘; // ANTI-PATTERN!
        this.setState({ value: value });
      },

      render: function() {
        return (
              <div>
                <InnerComponent value={this.state.value} />
                <a onClick={this.onClick}>Click me</a>
              </div>
        );
      }
});

起初,InnerComponent组件进行渲染,它得到的value属性为{foo: ‘bar‘}。当用户点击链接后,父组件的状态将会更新为{ value: { foo: ‘barbar‘ } },触发了InnerComponent组件的重新渲染,因为它得到了一个新的属性:{ foo: ‘barbar‘ }

看上去一切都挺好的,其实问题在于,父组件和子组件供用了同一个对象的引用,当用户触发click事件时,InnerComponent的prop将会发生改变,因此它的shouldComponentUpdate函数将会被调用,而此时如果按照我们目前的shouldComponentUpdate比对逻辑的话,this.props.value.foonextProps.value.foo是相等的,因为事实上,它们同时引用同一个对象哦~所以,我们将会看到,InnerComponent的ui并没有更新。哎~,不信的话,我贴出完整代码:

<!DOCTYPE html>
<html>
    <head>
        <meta charset="utf-8">
        <title>demo</title>
        <!--引入React库-->
        <script src="lib/react.min.js"></script>
        <!--引入JSX转换库-->
        <script src="lib/JSXTransformer.js"></script>
        <!--组件样式-->
    </head>
    <body>
        <!--定义容器-->
        <div id="content"></div>

        <!--声明脚本类型为JSX-->
        <script type="text/jsx">

            var InnerComponent = React.createClass({
                shouldComponentUpdate: function(nextProps, nextState) {
                      return this.props.value.foo !== nextProps.value.foo;
                },
                  render: function() {
                    return (
                          <div>
                            {this.props.value.foo}
                          </div>
                    );
                  }
            });

            var OutComponent = React.createClass({
                  getInitialState: function() {
                    return { value: { foo: ‘bar‘ } };
                  },

                  onClick: function() {
                    var value = this.state.value;
                    value.foo += ‘bar‘; // ANTI-PATTERN!
                    this.setState({ value: value });
                  },

                  render: function() {
                    return (
                          <div>
                            <InnerComponent value={this.state.value} />
                            <a onClick={this.onClick}>Click me</a>
                          </div>
                    );
                  }
            });

            React.render(<OutComponent />, document.querySelector("#content"));

        </script>
    </body>
</html>
时间: 2025-01-11 10:38:02

正式学习 React(三)番外篇 reactjs性能优化之shouldComponentUpdate的相关文章

《Mycat学习笔记》 番外篇一.客户端使用latin1字符集,后端MySQL为UTF8字符集,MyCat日志分析。

其实这个番外篇比较无聊——即客户端为lantin字符集,后面MySQL为U8字符集,MyCat在中间到底会起什么作用. 再说下本次验证的环境: Mac OS 10.11.2 MySQL 5.6 MyCat 1.5 OK,开始我们的验证工作. 1) 由于数据库与操作系统已被默认设置为U8编码,计划通过修改Mysql  “character_set_client” 参数调整客户端字符集配置进行验证. 关于MYSQL字符集较全面的介绍,请参考 <mysql_query("set names gb

正式学习 react(三)

有了基础的webpack基础,我们要对react的基本语法进行学习. 我这个教程全部用es6 实现.可能会忽略一些最基本的语法讲解,这些你在官网上或者其他别的地方都比我讲的全. 今天我要讲一下react用的较多的bind函数. 源码分析一波: 1 Function.prototype.bind = function() { 2 var __method = this; 3 var args = Array.prototype.slice.call(arguments); 4 var object

正式学习React( 三)

最基本的jsx语法什么的,我就不介绍了,唯一觉得有用点的,就是声明周期了. 下面的内容是转来的,自己也可以网上去搜,我觉得别人归纳的挺不错的,不过写法可能不是es6的,不影响学习. 在组件的整个生命周期中,随着该组件的props或者state发生改变,它的DOM表现也将有相应的变化.组件本质上是状态机:对于特定的输入,它总会返回一致的输出. ???????React为每个组件提供的生命周期分三个阶段:  一.实例化: getDefaultProps:组件初次实例化创建(不管是否成功)才会被调用,

《Mycat 学习笔记》 番外篇之系统命令 —— reload config

1)基础说明 Mycat (1.5版本)默认开通2个端口,可以在server.xml中进行修改. 8066 数据访问端口,即进行 DML 和 DDL 操作. 9066 数据库管理端口,即 mycat 服务管理控制功能. Mac 环境验证不通过,mysql 命令连接不到 mycat 服务端. 2)在 schema.xml 文件中增加一个新的数据表配置,下面红字标识 <schema name="TRDB" checkSQLschema="false" sqlMax

Monkey源码分析番外篇之Android注入事件的三种方法比较

原文:http://www.pocketmagic.net/2012/04/injecting-events-programatically-on-android/#.VEoIoIuUcaV 往下分析monkey事件注入源码之前先了解下在android系统下事件注入的方式,翻译一篇国外文章如下. Method 1: Using internal APIs 方法1:使用内部APIs This approach has its risks, like it is always with intern

编程珠玑番外篇

1.Plan 9 的八卦 在 Windows 下喜欢用 FTP 的同学抱怨 Linux 下面没有如 LeapFTP 那样的方便的工具. 在苹果下面用惯了 Cyberduck 的同学可能也会抱怨 Linux 下面使用 FTP 和 SFTP 是一件麻烦的事情. 其实一点都不麻烦, 因为在 LINUX 系统上压根就不需要用 FTP. 为什么呢? 因为一行简单的配置之后, 你就可以像使用本机文件一样使用远程的任何文件. 无论是想编辑, 查看还是删除重命名, 都和本机文件一样的用. 这么神奇的功能到底如何

【转载】数学之美番外篇:平凡而又神奇的贝叶斯方法

数学之美番外篇:平凡而又神奇的贝叶斯方法 BY 刘未鹏 – SEPTEMBER 21, 2008POSTED IN: 数学, 机器学习与人工智能, 计算机科学 概率论只不过是把常识用数学公式表达了出来. ——拉普拉斯 记得读本科的时候,最喜欢到城里的计算机书店里面去闲逛,一逛就是好几个小时:有一次,在书店看到一本书,名叫贝叶斯方法.当时数学系的课程还没有学到概率统计.我心想,一个方法能够专门写出一本书来,肯定很牛逼.后来,我发现当初的那个朴素归纳推理成立了——这果然是个牛逼的方法. ——题记 目

[uboot] (番外篇)uboot 驱动模型(转)重要

[uboot] uboot流程系列:[project X] tiny210(s5pv210)上电启动流程(BL0-BL2)[project X] tiny210(s5pv210)从存储设备加载代码到DDR[uboot] (第一章)uboot流程——概述[uboot] (第二章)uboot流程——uboot-spl编译流程[uboot] (第三章)uboot流程——uboot-spl代码流程[uboot] (第四章)uboot流程——uboot编译流程[uboot] (第五章)uboot流程——u

(apache+tomcat集群+memcached番外篇)单台tomcat的session信息的2种持久化方式

为什么要实现搭建tomcat集群环境呢?主要因为单个tomcat无论从吞吐量和并发数上,会达到一定的极限.如果访问量超过单个tomcat的承受能力的话,tomcat一般要么拒绝提供服务,要么直接宕掉.所以,必须要依靠tomcat集群技术.举个最简单的例子,拿"送快件"比喻,如果一个人,5分钟送一件,一小时之内,送10个,一个人完全能胜任这项工作.假设现在到了双十一,要求1小时,送100个, 那怎么办?只能安排更多的人加入"送快件"这项工作中来.这其实和集群一个道理.