React 性能分析器介绍

注：本文翻译自 React 官方博客，并且已经更新到最新的 React 中文文档中，马上查看《 介绍 React 性能分析器 》

React 16.5 增加了对新的开发者工具 DevTools 性能分析插件的支持。 此插件使用 React 实验性的 Profiler API 来收集有关每个组件渲染的用时信息，以便识别 React 应用程序中的性能瓶颈。 它将与我们即将推出的 time slicing（时间分片） 和 suspense（悬停） 功能完全兼容。

此博客文章涵盖以下主题：

• 分析一个应用程序的性能
• • 没有为选定的 root 节点记录分析数据
  • 选中的 commit 没有显示计时数据

分析一个应用程序的性能（Profiling an application）

DevTools 将为支持新的 Profiler API 的应用显示 “Profiler” 选项卡：

注意：

注意： react-dom 16.5+ 在 DEV 模式下支持性能分析。如果生产环境的包需要用到，你可以试用 react-dom/profiling 。 你可以在 fb.me/react-profiling 中阅读有关如何使用该包的更多信息。

“Profiler”面板初始打开将是空的。单击 record(录制) 按钮就可以开始分析：

一旦开始录制，DevTools 将在每次应用程序渲染时自动收集性能信息。就像正常使用您的应用程序一样。当你想完成分析时，单击 “Stop(停止)” 按钮即可。

假设您的应用程序在分析时至少渲染过一次，那么 DevTools 将显示几种查看性能数据的方法。我们将在下面逐一说明。

查看性能数据

浏览 commits（Browsing commits）

从概念上讲，React 分两个阶段工作：

• render(渲染) 阶段，确定需要对DOM进行哪些更改。在此阶段，React 调用 render 方法，然后将结果与之前的渲染进行比较。
• commit(提交) 阶段，是 React 做出任何更新的阶段。(对于 React DOM 来时，这是React插入，更新和删除DOM节点的时候。) React 也在这个阶段调用 componentDidMount 和 componentDidUpdate 等生命周期函数。

DevTools Profiler(分析器) 根据 commits(提交) 对性能信息进行分组。commits(提交) 显示在靠近 Profiler(分析器) 顶部的条形图中：

图表中的每个条形表示单独的一次 commit(提交)，当前选定的 commit(提交) 颜色为黑色。 您可以单击条形栏（或左/右箭头按钮）以选择其他 commit(提交) 。

每个条形图的颜色和高度对应于 commit(提交) 渲染所需的时间 （较高的黄色竖条比较短的蓝色竖条耗时更长）。

过滤 commits（Filtering commits）

您录制的时间越长，您的应用渲染的次数就越多。 在某些情况下，您最终可能会有 很多次 的 commits(提交) 而很难轻松处理。 Profiler(分析器) 提供了一种过滤机制来帮助解决这个问题。 使用它来指定阈值，Profiler(分析器) 将隐藏所有比该值 更快 的 commits(提交) 。

火焰图表（Flame chart）

火焰图表视图表示特定 commits(提交) 对应的应用的状态。 图表中的每个横条代表一个 React 组件（例如 App ， Nav ）。 横条的大小和颜色表示渲染组件及其子组件所需的时间。 （横条的宽度表示组件上次渲染时花费的时间，颜色表示当前 commits(提交) 部分所花费的时间。）

注意：

横条的宽度表示在上次渲染时渲染组件（及其子组件）所需的时间。 如果组件未作为此次 commit 的一部分重新渲染，则时间表示先前的渲染。 组件越宽，渲染时间越长。

横条的颜色表示组件（及其子组件）在所选 commit 中渲染的时间。 黄色组件花费更多时间，蓝色组件花费更少时间，并且灰色组件在此 commit 期间根本不渲染。

例如，上面显示的 commit 总共需要 18.4 ms 进行渲染。 Router 组件渲染是耗时是最多（耗时 18.4 ms）。 大部分时间是因为它的两个子组件， Nav （8.4ms）和 Route （7.9ms）。 剩下的时间消耗分布在剩余的子节点之间，或者组件自身的 render 方法上。

您可以通过单击组件放大或缩小火焰图：

单击组件就可以选择它，并在右侧面板中显示信息，其中包括其 commit 时的 props 和 state 。 您可以深入了解这些内容以了解有关组件在提交期间实际渲染的内容的更多信息：

在某些情况下，选择一个组件并在 commit 之间进行切换时，还会提供有关组件渲染原因的提示：

上图显示 state.scrollOffset 在两次 commit 之间发生了变化。这可能是导致 List 组件重新渲染的原因。

排序图表（Ranked chart）

排序图视图表示单个 commit 。 图表中的每个横条代表一个 React 组件（例如 App ， Nav ）。 对图表进行排序，以便渲染时间最长的组件位于顶部。

注意：

组件的渲染时间包括渲染其子项所花费的时间，因此渲染时间最长的组件通常靠近树的顶部。

与火焰图一样，您可以通过单击组件放大或缩小 排序 图表。

组件图表（Component chart）

有时，在分析时需要查看特定组件的渲染次数。 组件图以柱状图的形式提供此信息。 图表中的每个竖条表示组件渲染的时间。 每个条的颜色和高度对应于组件在特定 commit中 相对于其他组件 渲染所花费的时间。

上图显示 List 组件渲染了 11 次。 它还表明，每次渲染时，它都是 commits 中最“昂贵”的组件（意味着它花费的时间最长）。

要查看此图表，请双击组件 或 选择组件，然后单击右侧详细信息窗格中的蓝色条形图图标。 您可以通过单击右侧详细信息窗格中的 “x” 按钮返回上一个图表。 您可以双击特定栏以查看有关该 commit 的更多信息。

如果在本次分析会话期间所选组件根本未渲染，则将显示以下消息：

交互（Interactions）

React 最近添加了另一个用于记录触发更新动作的API(实验中)。使用此 API 记录的 interactions 也将显示在 Profiler 中：

React 最近添加了另一个用于跟踪更新原因的 实验API 。跟踪此API的 “交互（interactions）” 也将显示在 Profiler(分析器) 中：

上图显示了一个跟踪四个交互（interactions）的分析会话。 每行代表一个被跟踪的交互（interactions）。 沿着行的彩色圆点表示与该交互（interactions）相关的 commit（提交 ）。

你还可以从火焰图和排名图中查看为某次 commit 记录的 interaction：

你可以通过单击它们，在 interaction 和 commits 之间互相切换：

跟踪API仍然是新的，我们将在以后的博客文章中更详细地介绍它。

发现并修复故障

没有为选定的 root 节点记录分析数据

如果您的应用程序有多个 “roots”，则在分析后可能会看到以下消息：

此消息表示 “Elements” 面板中选择的 root 节点没有分析数据。

在这种情况下，尝试在该面板中选择不同的 root 节点以查看该 root 节点的分析信息：

选中的 commit 没有显示计时数据

有时可能会因为 commits 太快，以至于 performance.now() 还没有把相关有意义的时序信息传递给 DevTools。在这种情况下，将显示以下界面：

深入视频

以下视频演示了如何使用 React Profiler(分析器) 来检测和改善实际 React 应用程序中的性能瓶颈。