报名参加CloudWeGo黑客松,奖金直推双丰收! 了解详情
写点什么

什么时候要在 React 组件中写 shouldComponentUpdate?

  • 2016-06-30
  • 本文字数:3099 字

    阅读完需:约 10 分钟

生命中一半的时间都用来写 JavaScript 的 James K Nelson 最近发表了一篇文章,标题是《 Should I use shouldComponentUpdate? 》。他在这篇文章中介绍了应该在什么情况下使用 React 组件中的shouldComponentUpdate方法。

接触过 React 的人应该都知道它是一个非常快的前端框架,或许也听说过shouldComponentUpdate可以让它更快。但你知不知道它们在什么情况下才能发挥作用?也就是说,你知道什么时候需要动手写shouldComponentUpdate方法吗?

James 指出,如果你在 React 组件中写了shouldComponentUpdate方法后不能获得可测量的,并且是可察觉到的性能提升,那就不要写。

你的意思是我不应该用它?

按照 React 团队的说法,shouldComponentUpdate是保证性能的紧急出口,既然是紧急出口,那就意味着我们轻易用不到它。但既然有这样一个紧急出口,那说明有时候它还是很有必要的。所以我们要搞清楚到底什么时候才需要使用这个紧急出口。

为了讲清楚这个问题,James 对 React 的渲染机制做了深入地剖析。

他首先指出:

添加shouldComponentUpdate方法一般都会拖慢组件的更新速度。

为什么会这样呢?因为在他看来,React 基本上就是一个非常聪明的shouldComponentUpdate实现。它不仅知道应该在什么时候更新组件,还知道应该如何更新组件,并且这两件事情它都做得很好。那么 React 是如何知道是否应该更新组件的呢?这要从组件中的render方法说起。

尽管在写代码时,我们看到render返回的都是 JSX 或者ReactElement,但实际上,它返回的都是下面这种普通的 JavaScript 对象:

复制代码
{
type: 'ul',
props: { className: 'what-do-you-want-to-do-tonight' },
children: [{
type: 'li',
children: 'The same thing we do every night, pinky.'
},]
}

React 就是用这种对象来描述要在界面中渲染的标签。如果跟上次渲染时所用的对象比较,数据没有发生变化,显然就不用更新界面中的 DOM。

换句话说,React 已经替我们实现了一个shouldComponentUpdate。为了简化,我们可以假装props不是绑在组件的this上的,而是直接传给了render,那么 React 的实现基本上就是下面这样的:

复制代码
shouldComponentUpdate(nextProps) {
return !deepEquals(render(this.props), render(nextProps))
}

你是知道的,对于比较小的对象来说,deepEquals很快,但如果是个层层嵌套的大家伙,它的速度就不行了。因此我们可以得出第一条结论:

如果render的返回值很小,但props是个大家伙,那自己写shouldComponentUpdate很可能不会带来什么好结果。

那这是不是说,如果render返回的值足够大,我们自己写shouldComponentUpdate就会比较划算呢?实际上也不尽然。

讲到这里,James 又给出了他观察到的第二个事实:

使用shouldComponentUpdate得到的收益一般是微乎其微的。

他举了一个例子:比如要渲染一个table,我们从props中得到数据,然后又对这些数据做了些计算。并且这些数据都是放在 Immutable.js 的结构中的,因此通过比较引用是否相等就能判断出props是否发生了变化。

在这样一个场景中,如果我们自己写shouldComponentUpdate,那速度要比 React 默认实现的处理速度快很多。James 说他观察到的结果是最少快十倍!对,你没看错,他确实是这样说的,但他紧接着又说:

不足一毫秒的渲染时间在速度提升了 10 倍之后,依然也还是不足一毫秒。

嗯,我也觉得他这是在耍我们。

James 还搬出大神高德纳的那句名言来警告我们不要掉进过早优化的陷阱。为了引起足够的重视,他又指出了使用 shouldComponentUpdate所引发的问题:

shouldComponentUpdate很难维护

React 团队说shouldComponentUpdate是个紧急出口,而不是加速按钮应该就是出于这个原因。但 James 给出了一个更形象的比喻,他说用shouldComponentUpdate就是没有采取安全措施的性行为。

因为他觉得有时候很有必要写shouldComponentUpdate,并且那些时候shouldComponentUpdate肯定会让你的 app 有更好的表现。但是这也是导致 bug 的主要原因之一,并且还都是一些不太容易察觉的 bug。接着他又给出了几个具体的例子,并指出这些 bug 在测试中很难发现。如果在给客户演示的时候跳出来,那后果就不堪设想了。

什么时候需要写 shouldComponentUpdate?

因此还是回到了最初的那个问题上,什么时候需要自己动手写shouldComponentUpdate方法?他再次重申了前文中给出的那个答案:

只有经过测量,发现有了shouldComponentUpdate后组件的渲染速度确实有可察觉的提升,你才应该用它。

James 还在 fiddle 中给了一个例子,供我们练习如何测量,并比较使用 shouldComponentUpdate前后的渲染速度。

在开始测量之前先搞清楚如何在你的浏览器中打开分析器(如果你还不知道怎么做,Chrome 请看这里,Firefox 看这里)。

测量的过程很简单:

第一步:测量标准版

先从点击一个动作时render所花的时间开始测量:

  1. 在 fiddle 例子的窗口中打开 JavaScript 分析器。
  2. 开始记录。
  3. 点击"Toggle synergy!",让页面循环 5 秒钟左右。
  4. 点击开始记录时点过的那个按钮,停止记录。
  5. 按“self”时间排序,找到耗时最多的那个render方法,应该在列表的顶端附近。把它用的时长记下来,这里我们要的是“总时长”,即render本身所用的时间及它调用的函数所用的时间。

如果在这个列表顶部没找到render,那么恭喜你!你完全没必要写shouldComponentUpdate,最起码在解决掉其他性能问题之前没必要。

第二步:测量有shouldComponentUpdate的版本

这一步是要测量给App组件添加了shouldComponentUpdate之后渲染所花的时间。下面有个提前准备好的实现,你可以把它加到组件中:

复制代码
shouldComponentUpdate(nextProps, nextState) {
return !Immutable.is(this.state.synergy, nextState.synergy)
},

加好之后,按步骤一中的过程测量一遍。得到测量结果后,还要找到shouldComponentUpdate用的时间,然后加上去。应该差不多像下面这样:

组件中有shouldComponentUpdaterender

shouldComponentUpdate

就是这样,测过之后你就能 _ 大概 _ 知道shouldComponentUpdate能带来什么样的好处了。注意这里说的是 _ 大概 _,因为这种方法得不到精确的结果。一定要记住,真实结果跟测量结果比可能会有很大的差异,不信你可以多试几次。

做出决定

既然测量结果不精确,那我们凭什么做出决定呢?要凭好得不容置疑的测量结果。

那什么才算是好得不容置疑的结果呢?按照 James 的经验,如果加上shouldComponentUpdate之后渲染时间减少了一半,那用shouldComponentUpdate应该是真的对你有好处的。但同时也不要忘记,只有原来的渲染时间足够长时,这种性能上的提升才是有意义的。假如本来只用了 100ms,那你折腾半天加快的那点速度人们依然是感觉不到的。

所以在最终要做决定的时候,你要记住使用shouldComponentUpdate会带来维护上的挑战;并且测量结果是不准确的;而且性能改善的幅度还要是能感觉到的那种,只有记住这三点,你才能做出正确的决定。当然,这一切的前提是你的shouldComponentUpdate实现是没有问题的。

写出有效的 shouldComponentUpdate

在经过不懈地努力找到应该使用shouldComponentUpdate的点后,接下来的问题就是应该怎么写呢?

James 给出的答案非常:“Immutable.js!”。看到这个答案你的感觉是不是像看到下面这幅画一样?

当然,Immutable.js 不是唯一的答案,用Object.assign也可以,关键是不可变的状态。

如果你觉得 Immutable.js 也解决不了你的问题,James 又提出了一个更高级的解决方案:结构良好的状态。不过如果你想知道怎么才能做出结构良好的状态,只能听他下回分解了。


感谢韩婷对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ @丁晓昀),微信(微信号: InfoQChina )关注我们。

2016-06-30 18:0023747
用户头像

发布了 45 篇内容, 共 25.7 次阅读, 收获喜欢 11 次。

关注

评论

发布
暂无评论
发现更多内容

如何成为更好的AI专业人员?请查收这7条实战经验

Baihai IDP

人工智能 算法 数据科学

多方安全计算升级数据治理技术体系需考虑数据源合规性等

易观分析

多方安全计算

知名固件供应商百敖软件加入龙蜥社区

OpenAnolis小助手

开源 生态 龙蜥社区 CLA 百敖软件

2022观测云产品发布会前瞻:这是一份给IT工程师们的礼物

观测云

ArduBee|开源技术背后的创新

科技热闻

SVGIcon 组件的构建与使用

全象云低代码

前端 低代码 SVG 低代码平台 图标库

netty系列之:netty中的frame解码器

程序那些事

Netty 程序那些事 java 4月月更

P5直升P7!“阿里爸爸”最新出品年薪30W~120WJava架构师学习路线

Java全栈架构师

程序人生 IT java程序员 java面试 java架构

四川数字经济发展分析:四川21市州数字经济发展活跃度解密

易观分析

数字化转型 数字化经济

开源分布式图数据库的思考和实践

NebulaGraph

图数据库 知识图谱

Pulsar Summit Asia 2021|Pulsar在移动云智能运维平台的实践

移动云大数据

pulsar

带你了解什么是DHCP,为什么要用DHCP?

乌龟哥哥

DHCP 4月月更

基于云效Flow配置 Jenkins 源

阿里云云效

云计算 阿里云 运维 jenkins、 jenkins高级用法

不解决好这 3 大矛盾,就别搞 DevOps 了

飞算JavaAI开发助手

论语音社交视频直播平台与 Apache DolphinScheduler 的适配度有多高

白鲸开源

Web3 和区块链技术:数字资产所有权如何颠覆当前的商业模式

CECBC

恒源云(Gpushare)_炼丹萌新指南,这次错不了!

恒源云

深度学习 GPU算力 算法训练

【技术加油站】浅谈百度智能测试的三个阶段

百度Geek说

测试

Kernel SIG直播:让人头疼的“内核内存被改”和“内存泄露”怎么解?|第13期

OpenAnolis小助手

直播 内核 龙蜥社区 sig 龙蜥大讲堂

架构实战营模块九毕业项目

刘洋

#架构实战营 架构师实战营 「架构实战营」

阿里云PolarDB开源数据库社区与 Tapdata 联合共建开放数据技术生态

阿里云数据库开源

数据库 阿里云 polarDB PolarDB-X

2022年4月中国数据库排行榜:华为GaussDB 挺进前四,榜单前八得分扶摇直上

墨天轮

数据库 国产数据库 达梦 人大金仓 gbase8a

使用ORM与原始SQL的性能对比

杨彦星

Python MySQL sanic

数据挖掘:针对小样本与不均衡样本的机器学习算法实践

鲸品堂

数据挖掘

4. 堪比JMeter的.Net压测工具 - Crank 进阶篇 - 认识wrk、wrk2

MASA技术团队

C# .net 微软 测试 压测

《对话ACE》第二期:新数据库时代,DBA发展之路该如何选择

OceanBase 数据库

dba oceanbase

【直播预告】优化器及 Flink CDC + OceanBase 全增量一体化数据集成方案

OceanBase 数据库

OceanBase 社区版

ironSource 发行解决方案 Supersonic 两周年,游戏全球下载量突破 20 亿

极客天地

搭建一个可视化看板,仅需4步

阿里云云效

云计算 阿里云 看板 研发团队 可视化看板

测试权限

石子头

Cisco Nexus L2 Switch 进行 vPC 和 L3 改造以支持 K8S 部署

Qunar技术沙龙

#运维

什么时候要在React组件中写shouldComponentUpdate?_语言 & 开发_吴海星_InfoQ精选文章