React Profiler或者react-devtools相关 #333

cisen · 2019-03-26T02:35:18Z

说明

https://github.com/facebook/react-devtools
https://juejin.im/post/5ba0f8e4f265da0ab915bcf2
https://reactjs.org/blog/2018/09/10/introducing-the-react-profiler.html

转

原文地址：Introducing the React Profiler

原文作者：Brian Vaughn

译文出自：掘金翻译计划

本文永久链接：https://github.com/xitu/gold-miner/blob/master/TODO1/introducing-the-react-profiler.md

译者：CoderMing

校对者：CoolRice

React Profiler 介绍

React 16.5 添加了对新的 profiler DevTools 插件的支持。这个插件使用 React 的 Profiler 实验性 API 去收集所有 component 的渲染时间，目的是为了找出你的 React App 的性能瓶颈。它将会和我们即将发布的时间片特性完全兼容。（译者注：可以参考 Dan 在第一届中国 React 开发者大会上的视频）

这篇博文包括以下的话题：

Profile 一个 APP
查看性能数据
常见问题 & 解决方法
- 选择的根元素下没有 profile 数据被记录
- 选中的 commit 记录没有展示时间数据

Profile 一个 APP

DevTools 将会对支持新的 profiling API 的 APP 新加一个 “Profiler” tab 列：

Note：react-dom 16.5+ 在 DEV 模式下才支持 Profiling，同时生产环境下也可以通过一个 profiling bundle react-dom/profiling 来支持。请在 fb.me/react-profiling 上查看如何使用这个 bundle。

这个 “Profiler” 的面板在刚开始的时候是空的。你可以点击 record 按钮来启动 profile：

当你开始记录之后，DevTools 将会自动收集你 APP 在（启动之后）每一刻的性能数据。（在记录期间）你可以和平常一样使用你的 APP，当你完成 profile 之后，请点 “Stop” 按钮。

如果你的 APP 在 profile 期间重新渲染了几次，DevTools 将会提供好几种方法去查看性能数据。我们将会在接下来讨论它们。

查看性能数据

浏览 commits

从概念上讲，React 的运行分为两个阶段：

在 render 阶段会确定例如 DOM 之类的数据需要做那些变化。在这个阶段，React 将会执行（各个组件的）render 方法，之后会计算出和调用 render 方法之前有哪些变化。
commit 阶段是 React 提交任何更改所在的阶段（在 React DOM 下，就是指 React 添加、修改和移除 DOM 节点的时候）。同时在这个阶段，React 会执行像 componentDidMount 和 componentDidUpdate 这类周期函数。

（译者注：此处可参考 React.js 小书第 18-20 篇）

profiler DevTools 是在 commit 阶段收集性能数据的。各次 commit 会被展示在界面顶部的条形图中：

在条形图中，每一列都表示单次的 commit 数据，你当前选中的 commit 列会变成黑色。你可以点击各个列（或者是左/右切换按钮）来查看不同的 commit 数据。

这些列的颜色和高度对应着该次 commit 在渲染上所花的时间（较高、偏黄的列会比较矮、偏蓝的列花费的时间多）。

筛选 commits

你 profile 的记录时间越长，渲染次数就会越多。有时候你或许会被过多的（价值低的）commit 记录干扰。为了帮助你解决这个问题，profiler 提供了一个筛选功能。用它来制定一个时间阀值，之后 profiler 会隐藏所有比这个阀值更快的 commit。

火焰图

（译者注：阮一峰：如何读懂火焰图？）

火焰图会展示你所指定的那一次 commit 的信息。图中每一列都代表了一个 React component（例如下图中的 App、Nav）。各列的尺寸和颜色表示这列所代表的 component 及其 children 的渲染时间（列的宽度表示该 component 最近一次渲染所花费的时间，列的颜色代表在该次 commit 中渲染所花费的时间）。

Note：

列的宽度表示 component（和它的 children）最近一次渲染所花费的时间。如果这个 component 在本次 commit 中没有被重新渲染，那其所展示的时间表示上一次 render 的耗时。一个列越宽，其所代表的 component 渲染耗时就越长。

列的颜色表示在本次 commit 中该 component（和它的 children）所花费的时间。黄色代表耗时较长、蓝色代表耗时较短，灰色代表该 component 在这次 commit 中没有被（重新）渲染。

举个例子，上图中所展示的 commit 总共渲染耗时为 18.4 ms。Router component 是渲染成本“最昂贵”的 component（花费了 18.4 ms）。他所花费的时间大部分在两个 children 上：Nav（8.4 ms）和 Route (7.9 ms)。剩下的时间用于它的其他 children 和它自身的渲染。

你可以通过点击 component 列来放大或缩小火焰图：

点击一个 component 的同时也会选中它，它的具体信息将会展示在右边的数据列，列里会展示该 component 在这次 commit 时的 props 和 state。你可以去深入研究这些数据来找出这次 commit 具体做了哪些。

某些情况下，选中一个 component 后在不同的 commit 之间切换也可以发现触发这次渲染的原因：

上图表示在两次 commit 中 state.scrollOffset 被改变了。这或许就是触发 List component 重绘的原因。

排序图

同火焰图一样，排序图也会展示你所指定的那一次 commit 的信息，图中每一列都代表了一个 React component（例如下图中的 App、Nav）。不同的是排序图是有顺序的，耗时最长的 component 会展示在第一行。

Note：

一个 component 的渲染时间也包括了它的 children 们消耗的时间，所以渲染耗时最长的 component 通常距离树顶部最近。

和火焰图一样，你可以通过点击 component 列来放大或缩小排序图（译者注：排序图只会展示在本次 commit 中被触发重绘的 component）。

Component 图

在你 profile 的过程中，使用该图查看单一 component（在多次 commit 中）的渲染时间有时候是非常有用的。Component 图会以一个列的形式展示，其中每一列都表示你所选择的 component 的某一次 commit 下的渲染时间。每列高度和颜色都表示该 component 在某次 commit 中同其它组件的耗时对比。