【译】使用 Chrome DevTools 为 React 16 进行性能画像

739 阅读5分钟
原文链接: blog.shockw4ver.com

【译】使用 Chrome DevTools 为 React 16 进行性能画像

By shockw4ver No comments

原文:building.calibreapp.com/debugging-r…

React 是最早凭借其渲染性能而不仅仅是名声进行推广的前端框架之一。React 的虚拟 dom 以其高效的组件渲染能力著称——但是什么让这些组件不再让人感觉响应迅速了呢?你发现过这个问题吗?你又是如何解决它的?

今天我将结合真实的 React 代码和 Chrome DevTools 来演示一些让人眼前一亮的高效性能追踪方式以及如何通过它们来诊断出导致渲染速度减慢的组件。

这个新的性能工具包含以下三个元素:

  • 开启 React 16 的开发模式(development mode)
  • 将 sourcemap 和你的 JS 文件一同打包(非必要,但非常建议这样做)
  • 使用 Chrome 或 Chromium 的 DevTools(现在所有的 release 版本都支持)

开启你的评审!

首先,你需要一些空间做个深呼吸,然后弹出 DevTools。缩放至屏幕极限。“Ahh,看起来好多了!”

Sources 
Filtg 
Netwwk 
Security

面向真实世界的需求是我们在做性能评审时很重要的一点。并不是每个用户都拥有价值 3000 刀以上的电脑或最新型号的手机。

幸运的是 Chrome 已经考虑到了这个问题——我们将人为的减慢 JavaScript 的执行速度。这会使得性能问题更加显著,如果你的应用在软硬配置都相对更差的移动设备上能快速运行,那么它将在桌面设备上飞起来。

将最新型号的 Macbook 放慢 4 倍可以得到在 Motorola Moto G4 上一样的性能表现。

可视化性能追踪

在开发模式下,React 16 会在渲染的时候给每个组件加上“mark 和 measure”事件。

导航到你想要测试的页面(在 localhost 下),点击“Start profiling and reload page”按钮来开始性能分析评审。

这将绘制当前页面的渲染执行过程。Chrome 会在页面加载完成后自动停止记录。

Cor— Sources 
C Screenshots Cj 
JavaSc•ipt ples 
CJ Enable advanced paint instrurnentation (slow) 
Developer Tools • http:mocaIhost:3000/ 
Network A P&forrnarwe Merrw•y Appleation 
Memory 
Network; Online 
CPU: 4 g Slowdown 
Sæurity 
Audits 
the button 
or hit E to Start a recording. 
Click the reload button C or hit O E to record the page load. 
After recording, select an area Of interest in the Overview by dragging, 
Then. zcx:yrn and pan the timeline with the mousewheel or WASD keys. 
The Perforrnance panel provides the combin«i functionality of 
Timeline and JavaScript CPU profiler- 
The JavaScript CPU profiler will be removed Meanwhile, ts 
available under Mcye Tools JavaScript Profiler.

也可以使用快捷键 ⌘+⇧E 来启动

绘制完成后,你会得到类似下图的结果:

Elements Console Sources 
C Screen shots 
O Disable JavaScript samples 
o 
Enable advanced paint instrumentation (slow) 
1000 ms 
Developer Tools - http://localhost:3000/home 
Network A 
Performance Memory Application 
Memory 
Network: Online 
CPU: 4x slowdown 
Security 
Audits 
CPU 
500 ms 
Frames 
1000 ms 
1500 ms 
Call Tree 
429.4 ms 
2456.0 ms 
326.6 ms 
76.1 ms 
1708.8 ms 
1215.4 ms 
2000 ms 
1927.1 ms 
Event Log 
Loading 
Scripting 
Rendering 
Painting 
Other 
Idle 
2500 ms 
30 
ms 
3500 ms 
4000 ms 4500 ms 
1493.0 ms 
5000 ms 5500 ms 
525.2 ms 
6000 ms 
Summary Bottom-up 
Range: O — 6.21 s 
6212 ms

从左到右我们看到的是页面的加载和初始化时间线。

我想花一丁点儿时间向刚刚接触 Performance 标签页的开发者指出一些不那么显而易见的地方:

  1. 这个红色的条状指标显示在整个时间线的这个部分发生了明显的“CPU burn”(一些长时任务)。我们很可能需要对这个地方进行进一步的评审。
  2. 顶部图表中的不同颜色对应不同的活动类型。每种活动都有不同的起因,解决方案和分析方式。

今天我们将注意力主要集中在“Scripting”(JavaScript 运行时表现)部分。

放大窗口,点开 user timing,通过快照时间线来查看页面的绘制过程。

现在我们想要检查那块发生 CPU-burn 的区域。可以看到,在那段时间,页面主要是在渲染页面上的各个元素。

拖动图标来放大时间线。你注意到那个⚛️图标了吗?

通过这个操作,user-timing 相关的信息很快展示了出来,同时我们发现了一个标签为“Pulse”的组件(渲染它花费了 500ms)。

查看“Pulse”组件的内部,其主要是一些子组件的渲染,尽管这些子组件各自的指标并未显示较多的执行时间花费。

探索执行较慢的函数

  1. 点击你要检查的组件——在该例中即是“Pulse”。这将会调整窗口下方来专注于仅发生于 Pulse 组件中的行为。
  2. 选择“Bottom-Up”
  3. 将整个时间段进行降序排列。有时候,你可能希望以 Self time 为准或者 URL 以外的什么指标进行排序,取决于怎样更方便于你的检查。
  1. 点击三角形箭头知道你能将检查定位到某块代码中去。在这个例子中,map 方法的调用有些可疑。在 90ms 内它执行了很多次。
  2. 此时就体现了 sourcemap 的必要性:点击 MetricStore.js:59 将会把你带到代码中去!

执行耗时较长的代码会在左边进行指出。(向世界展示我的代码可能不是个好主意)

当你知其所以然的时候,优化并不非是件难事

在应用这个“窍门”的几周时间里,我设法从我秉持着“这很复杂,所以会花些时间”的代码中“争分夺秒”。现在我明确的知道了如何以及在哪里探索 JavaScript 的性能。我确定我以后会好好写 UI 组件。🙈

为什么 Chrome 中有明确的 React 相关指标内置?

React 通过 User Timing API 来推出这些计量工具,这也可以用来在你的代码中标记时间点。

想想下“0.4s 内完成组件初始化”或“用户会用 15s 来确认点击购买按钮”这类场景

进一步了解 User Timing API,可以参考 Alex Danilo’s 发布于 2014 年的那篇宝藏般的 HTML5 文章 “User Timing API” 。

主流浏览器都支持 User Timing API,但 Chrome 的 Performance 标签页在方便地调试 React 应用这件事上走得更远。

着手优化你的 JavaScript

我由衷的希望本文能提高您的 JavaScript 性能评审能力。希望您能留下评论——关于您学到了什么或在应用优化这件事上有什么收获。Enjoy!