当前位置: 首页 > news >正文

【译】React性能工程(下) -- 深入研究React性能调试

24 February 2016 on React

本文是 React 性能工程系列文章的 第二篇(共两篇). 在第一篇 译文,我们讲述了如何使用React性能工具和一些普遍存在的性能瓶颈,以及一些调试相关的技巧。如果你还没阅读上一篇文章,建议读一读!

本文我们将深入研究调试的工作流 -- 有了这些ideas之后,我们又要怎么实践呢?我们找了一些实际开发中遇到的例子,使用 Chrome 开发工具来诊断、修复这些性能问题。(如果你有好的建议或补充,欢迎让我们知悉!)

我们通过下面的示例代码来看下 -- 你将看到一个用React实现的简单版 todo list。点击下面 JS fiddle 中的 "RESULT" 查看交互效果、完成性能复制。我们将一步步更新 JS fiddle 来查看性能调试。

实例研究 #1: TodoList

从这个 TodeList 开始吧。快速地输入没有经过优化的代码,你会发现它运行缓慢。

我们打开 Chrome 开发者工具 Timeline profiler,它会展示浏览器的详细执行情况,包括执行用户事件、运行JS和渲染页面。在Input框输入一个字符,然后中止 timeline profiler。由于我们只是输入一个简单字符,所以这种迟缓并不明显,但它却是生成性能分析所需最小信息量的最快方式。

我们注意到 Event (textInput) 的长条,在脚本处理上总计耗时121.10毫秒。从 timeline profiler 可以看出,导致性能缓慢的是脚本问题,不是样式或计算引起的。

因此我们来看下脚本处理,切换到 Profiles 面板。Timeline 展示浏览器的概览并且支持JS Profile,而Profiles 则提供多种可视化工具,允许我们深入研究JS-land。以下是另一个 Profile 记录,表明性能的缓慢不是来源于我们的应用代码:

看下这个Profile,Total 这列根据占用时间递减排列,可以看出绝大部分时间是花在React的batchedUpdates的调用上,这点相当明确地暗示了是在React-land这一层。相反, Self 一栏评估了花费在函数本身的时间(排除耗费在子函数的时间),这样可以看出是否有一些特别耗时的函数。从这两个方面看来,用户层函数并没有明显的性能瓶颈。因此,我们换用React的性能工具来试下。

为了给这个缓慢的action生成一个测量概况,我们在控制台调用 React.addons.Perf.start(), 输入一个字符来执行这个action,随后调用 React.addons.Perf.stop() 完成这个流程。这样我们就可以看到React.addons.Perf.printWasted() 花费了一些不必要的时间:

第一列表明 TodoItem 是由 Todos 渲染出来的;然而,Perf.printWasted() 的打印结果表明:如果避免重新渲染,可以节省100毫秒。这个似乎是主要的优化项之一。

为了诊断为何 TodeItem 会浪费这么多时间,我们创建了一个自定义 mixin, 并把它命名为 WhyDidYouUpdateMixin。把它 hook 到组件中,哪部分代码更新及其更新的原因都打印出来。以下就是我们的代码,你可以根据自己所需,随意适配。

一旦我们把这个 mixin 放到 TodoItem 里面,我们可以看到这样的结果:

呀!我们看到 tagsbeforeafter 是一样的 -- mixin 告诉我们如果两个对象相等(不严格相等)是可以避免更新的。另一方面,计算出两个方法是否相等的过程也是很耗时的,因为 Function.bind 尽管带同样的参数,也会生成一个新函数。虽然这些都是有用的线索 -- 我们回头看下在 tagsdeleteItem 我们是怎么做的,似乎就是我们每传一个新的值,都创建了一个 TodoItem

如果我们通过一个未绑定的函数来传递给TodoItem,并用一个常量来储存tags,就可以避免这个问题了:

现在 WhyDidYouUpdateMixin 显示前一个props和新的props是浅相等的。我们可以使用 PureRenderMixin,如果前后两个props(和state)浅相等,则不用更新。

当我们再次运行 profiler,发现现在只是用了35毫秒(比之前快了4倍):

这样比起之前已经好很多了,但仍不够理想。Input 框的输入不应该这么耗时。因此,我们继续优化这个问题。刚刚仅仅是减少了常量,我们仍然需要对每个 item 做浅对比。

在这点上,你或许觉得一个 todo list上面有1000个 item 已经很特殊了,30毫秒对于你的应用来说是可以接受的。但是,如果你要支持上千个子item,这样就不符合理想中的60fps(每帧16毫秒)。

下一步比较合理的做法是把一个组件拆分成多个子组件 (这也可以说是有效的第一步)。我们注意到 Todos 组件实际上包括两个互不相交的子组件:一个AddTaskForm子组件包含了输入框和按钮,另一个 TodoItem 子组件包含items的列表。

每一步重构都能获得性能的提升:

  • 假设我们用 PureRenderMixin 创建一个TodoItems组件,它不用重新渲染每个item,就可省去部分优化工作,这时prevProps.items === this.props.items

  • 假设我们创建了一个 AddTaskForm 组件,文本输入后的状态就已经更新在那里了。当输入框文本变化时,Todos 组件就不用再重新渲染了。

这两步结合起来,每次按键只需要10毫秒!

实例研究 #2:

方案: 当用户的任务项太多( >3000)时,我们就渲染一个 warning,并且给这些 todo items 添加样式,这样其它每个item就都有一个背景颜色。

实践:

  • 我们用一个类似于 todo list 的例子,伴随着 TodoItems 的执行 -- 在这个例子中,我们把input框中的内容储存在组件状态的top-level

  • 我们创建一个 TaskWarning 组件,根据任务项的数量来渲染提示信息。要在组件内部封装这些逻辑,如果不用渲染,我们就让它返回null。

  • 我们给div:nth-child(even)添加灰色背景。

观察报告: 在Input框快速输入,页面变得有点迟缓(不超过3000个任务)。如果我们第一次给 todo list 再添加一项( > 3000 个任务),在按下按钮的那一瞬间,这种迟缓反而销声匿迹了。太令人惊讶了,添加更多的任务反而能够修复页面迟缓的问题!

调试: timeline profile 展示了一些非常有趣的报告:

基于某种原因,输入一个简单的字符会造成大量样式被重新计算,这个会耗时30毫秒(这也是为什么当我们输入的速度大于 30毫秒/字符时,可以观察到闪退的原因)。

查看 First invalidated 这一行,它表明 Danger.dangerouslyReplaceNodeWithMarkup 造成布局失效,需要重新计算样式。以下是 react-with-addons.js: 2301:

`oldChild.parentNode.replaceChild(newChild, oldChild);` 

基于某些原因,React用一个全新的DOM节点来替换原来的DOM节点。重新调用那些DOM操作是很耗性能的!使用 Perf.printDOM() ,可以查看到React是怎样进行DOM操作的:

update attributes 表明在 input 框输入 abc 时,TaskWarning 还是不可见的。然而,replace 指出React正准备接触DOM来调用 TaskWarning 组件,尽管它看似有完全一致的虚拟DOM。

正如这里所表明的,React (<= v0.13) 使用一个 noscript 标签来渲染 no component, 但却不恰当地把这两个标签的功能处理得不一致:末尾的 noscript 标签是不需要用另一个noscript标签来代替的。 此外,之前我们给每个div添加了灰色背景。基于CSS,3000个item节点里面每个独立个体的渲染都取决于它的兄弟节点。每次 noscript 标签被替换,其后的DOM节点都会重新计算它们的样式。

为了解决这个问题,我们可以这样做:

  • TaskWarning 返回一个空的 div

  • TaskWarning 组件移到一个 div 里面,这样它就不会影响到其后节点的CSS选择器。

  • 升级React :-)

但这是脱离本意的。这里主要是我们知道怎么通过 timeline profiler 去诊断这些性能问题。

总结

希望这章能够帮助大家了解 React 的性能问题是如何在开发者工具呈现出来的 -- 把 TimelineProfiles 和React性能工具结合起来用大有帮助。

有上千个items的 todo lists 随意着色似乎是别扭的,但当渲染大量的文件和样式表,或者构建一个电子手册,我们都会遇到非常相似的问题。而且,我们仍然在壮大我们的团队 -- 如果你有兴趣构建复杂的React apps,欢迎联系我们。

相关文章:

  • 【转】一个班37人考进清华北大,老师发来一则短信,家长都沉默了!
  • 编译安装redis
  • 1040 统计单词个数
  • 详解RocketMQ中的consumer
  • PHP中使用XMLReader读取xml文档内容
  • 学习Android路上的一些感慨和总结,慢慢来,比较快!
  • UVA 11212 Editing a Book
  • tomcat报错:java.net.SocketException: Permission denied[http-nio-80]
  • 入手阿里云新服务器的部署NODE
  • C#组件系列——又一款Excel处理神器Spire.XLS,你值得拥有
  • 运行时添加log4j2的appender
  • win产品密钥大搜集
  • PowerShell查询AD域内长期没有登录的计算机对象
  • 取distinct数据同时还取其他字段
  • RHCS+Conga+GFS+cLVM共享存储的高可用性web集群
  • Android开源项目规范总结
  • Android组件 - 收藏集 - 掘金
  • canvas 绘制双线技巧
  • input实现文字超出省略号功能
  • Java编程基础24——递归练习
  • jQuery(一)
  • Koa2 之文件上传下载
  • PAT A1120
  • PV统计优化设计
  • 初识 beanstalkd
  • 基于Mobx的多页面小程序的全局共享状态管理实践
  • 两列自适应布局方案整理
  • 排序(1):冒泡排序
  • 七牛云 DV OV EV SSL 证书上线,限时折扣低至 6.75 折!
  • 前端_面试
  • 前端学习笔记之原型——一张图说明`prototype`和`__proto__`的区别
  • 浅谈JavaScript的面向对象和它的封装、继承、多态
  • 如何将自己的网站分享到QQ空间,微信,微博等等
  • 使用Swoole加速Laravel(正式环境中)
  • 新版博客前端前瞻
  • 延迟脚本的方式
  • $forceUpdate()函数
  • $分析了六十多年间100万字的政府工作报告,我看到了这样的变迁
  • (6)【Python/机器学习/深度学习】Machine-Learning模型与算法应用—使用Adaboost建模及工作环境下的数据分析整理
  • (Python) SOAP Web Service (HTTP POST)
  • (附源码)springboot家庭财务分析系统 毕业设计641323
  • (十八)SpringBoot之发送QQ邮件
  • (十二)devops持续集成开发——jenkins的全局工具配置之sonar qube环境安装及配置
  • (原創) 如何解决make kernel时『clock skew detected』的warning? (OS) (Linux)
  • (转)微软牛津计划介绍——屌爆了的自然数据处理解决方案(人脸/语音识别,计算机视觉与语言理解)...
  • (转)一些感悟
  • .NET Core IdentityServer4实战-开篇介绍与规划
  • .net中生成excel后调整宽度
  • .net最好用的JSON类Newtonsoft.Json获取多级数据SelectToken
  • @TableLogic注解说明,以及对增删改查的影响
  • [BUUCTF]-Reverse:reverse3解析
  • [c++] 自写 MyString 类
  • [C++]类和对象【下】
  • [caffe(二)]Python加载训练caffe模型并进行测试1
  • [CTF]php is_numeric绕过