所以React 16.4.0已经发布了！ （注意翻译器-此功能已在版本16.4.0中添加，然后撰写了此帖子）。 在这样的时刻，您将了解自己的JavaScript风格-如果您关注自己喜欢的框架的次要更新，便是一个极客。 太好了！
如果您阅读
了 React团队发布的版本16.4
的发行说明，则应该认为此更新很无聊。
指针事件看上去很吸引人，但说实话，我之前对它们的了解很少。
此外，还有一种错误修复程序，用于一种新的
getDerivedStateFromProps方法（现在将在每个渲染器上调用）。 我还没有足够地使用它，所以对我而言，此更新不是很重要。
然后，我看到埋在标题下的公告，他们已经添加了新的实验性组件
unstable_Profiler 。 看到我的生活现在很不稳定（
unstable_ _），我决定阅读
RFC并尝试一下。
TLDR
来自React团队的
人们正在尝试使渲染异步化 。 这可能使得难以确定在安装/更新时何时渲染组件。 因此，他们正在使用这个闪亮的新
Profiler组件。
那么，您今天可以使用什么呢？因此，如果您是跟踪React应用程序性能的专家，那么这肯定是您军械库中的另一个好工具。 如果这与您无关，那么您将无法再阅读并返回创建出色的应用程序。
使用<Profiler />
警告 ：也许您不应该在生产中使用它（实际上，这是unstable_ ）。 稍后，他们将完成分析和生产代码的功能。基本上，
Profiler是可以从默认React包中提取的组件。 由于它有许多棉绒队都起誓的谨慎的，强调的名称，因此您可以按照以下方法解决此问题：
import React, { unstable_Profiler as Profiler } from 'react'; ... const Profiler = React.unstable_Profiler;
现在有了
Profiler ，让我们对组件进行概要分析！ 您可以在
Profiler包装JSX树的任何部分以查看发生了什么。
Profiler接受
onRender函数，该函数捕获有关渲染时间的信息。
这是一个简单的反例 ：
import React, { unstable_Profiler as Profiler } from 'react'; class ComponentWithProfiling extends React.Component { state = { count: 0 }; logProfile = (id, phase, actualTime, baseTime, startTime, commitTime) => { console.log(`${id}'s ${phase} phase:`); console.log(`Actual time: ${actualTime}`); console.log(`Base time: ${baseTime}`); console.log(`Start time: ${startTime}`); console.log(`Commit time: ${commitTime}`); }; go = direction => () => this.setState(({ count }) => ({ count: direction === "up" ? count + 1 : count - 1 })); render() { return ( <Profiler id="app" onRender={this.logProfile}> <button onClick={this.go("up")}>️</button> <div>The count is {this.state.count}</div> <button onClick={this.go("down")}></button> </Profiler> ); } }
请注意，必须为配置文件中的每个片段指定一个
id如下所示，
onRender接受许多有趣的指标：
7jroojkv30.codesandbox.io首先，您可以看到什么是渲染阶段（
mount或
update ），它可以用来识别意外更新的代码部分（就像我多次使用的出色的
Why-Did-You-Update软件包一样，强烈推荐）。
接下来，我们获得
actualTime和
baseTime 。 它们与React在渲染计算上花费的实际时间有关； 即 找出发生了什么变化。 请注意，初始连接（安装）的实际时间（初始时间）长于更新时间（更新）。 这是因为在初始连接时，从技术上讲，一切都是“新的”。 更新时，计算
应该更简单，因为我希望树中的组件仅在它们确实发生更改时（即，prop /状态的值发生更改时）才进行更新。
在大型/现实应用程序中，此数据将帮助您了解应在哪里正确或根本不使用
shouldComponentUpdate ，在哪些地方经常更改具有引用类型的道具或发送新的道具，或者只是在您不希望更新花费这么长时间的地方。
我们在
onRender中获得的最后一个值是
startTime和
commitTime 。 实际上，这些是自首次启动以来的时间戳记。
startTime是选定组件开始执行渲染计算的时间，而
commitTime是React在渲染过程中实际
提交这些更改的时间。
如果您使用时间戳跟踪其他事件（例如单击或击键），则这些指标可以帮助识别用户事件发生时间与实际呈现时间之间的增量。 如果差距很大，那么用户可能会发现这种延迟，应该仔细检查。
结论
就我个人而言，该工具还不是很有用。 但这是最好的事情之一，因为如果我遇到这些性能瓶颈，这将是衡量它们的好方法。
首先衡量您的性能问题很重要，因此，当您进行“改进”时，您可以判断出这是否确实在改善情况或只会使情况恶化。 我发现优化性能是您可以花费大量时间的事情之一。 因此，在优化某些内容之前，请确保它确实是必要的。
我期待React团队将来将对
Profiler进行处理。 感谢
@bvaughn添加此
漂亮功能！
来自翻译者：目前（当前版本16.6.0）Profiler不适用于服务器端渲染。
功能请求已存在。