尝试找到任何容易实现的目

rmruhul

这是您在开始评估任何类型的应用程序性能时遵循的流程吗？是关于 Notion 的案例研究吗？它是否遵循您对任何事情都会遵循的相同流程？

伊万·阿库洛夫：是的。(?) 过程是您识别问题，然后在本地重现问题。就 Notion 而言，Notion 页面需要一段时间才能加载，然后您使用拥有的所有工具对其进行分析，并标或不那么容易实现的目标。试着弄清楚如何切掉这个水果。这就是高水平的审查。有很多具体细节。

德鲁·麦克莱伦：这是一本非常引人入胜的读物，我将在节目笔记中 电报号码数据 放置一个链接，以便人们如果没有看过它，可以去看它。我看到您提到 React 17 去年删除了您最喜欢的性能功能之一。那是关于什么的？

伊万·阿库洛夫：React 已经经历了几代的性能特性。与 React 15 一样，我认为 15.5 有一个内置的强大对象，它让您可以测量最昂贵的组件或不必要渲染的组件。您可以在控制台中编写类似 perf dot 的内容...我不记得具体的指南。这就像测量一些东西。

伊万·阿库洛夫：是的，我们的想法是，这对于检测哪些组件是不必要的非常方便。我看到了哪些组件被渲染，但生成的 DOM 树与之前的 DOM 树相同。但后来 React 删除了它。我不知道为什么。那时我并没有积极参加表演。

伊万·阿库洛夫：React 删除了它。我想他们当时也引入了 React profiler。而且，在某个时候，他们引入了一个不同的 API，即用户计时。这个想法是，每当您运行 React 的开发版本时，您都会使用 Chrome DevTools 性能选项卡记录性能跟踪。React 要做的就是测量、标记每个组件的开始和结束、每个组件渲染的时间以及每个组件效果运行的时间，例如 componentDidMount、componentDidUpdate。

伊万·阿库洛夫：因此，它将测量每个组件的开始和结束，以及它的生命周期挂钩。它会使用用户计时 API 将它们部分放入性能记录中。这对于调试来说非常方便，因为当您记录单个渲染或其他内容的性能记录时，然后打开主线程窗格，然后查看它，您会看到很多被破坏的内部代码，就像它的 Fiber 算法作用于组件，调用数组组件。



伊万阿库洛夫识别每个组件渲染从哪里开始、每个组件渲染在哪里结束将是非常困难的。但是，如果您滚动得更高一点并打开用户计时会话，您将能够直接看到它，并且您将能够将用户计时应用程序场景中发生的情况相匹配，哪个组件正在此处渲染到中发生的情况性能窗格。如果您看到性能窗格中一些昂贵的工资计算，您只需向上滚动一点即可看到，“嘿，这实际上与此特定组件或此特定 inode，componentDidMount 匹配。”

伊万·阿库洛夫：因此，这对于调试（例如特定的性能问题）非常方便。然而，这样做的问题是，对于 React 开发人员来说，它相当难以维护。GitHub 上对该描述进行了讨论，并给出了具体的推理。React 最终所做的是他们在 React 17 中删除了这个 API。在 React 17 中删除了这个 future。

伊万·阿库洛夫：因此，目前在 React 17 中，调试 React 性能的唯一方法是使用 React profiler。虽然这对很多事情都很有效，但有一些用例，比如查看生命周期钩子，React Profiler 无法测量它或我的链。弄清楚为什么特定组件需要一段时间才能渲染，React Profiler 再次向您显示该特定组件需要 30 或 300 毫秒来渲染，但它没有显示原因并弄清楚为什么您必须切换回性能窗格。