无论您要开发哪种类型的应用，优化其性能并确保其快速加载并提供流畅的互动体验对用户体验和应用的成功至关重要。实现此目的的方法之一是使用性能分析工具来检查应用的活动，以了解应用在一段时间内运行时在后台发生的情况。DevTools 中的性能面板是一款出色的性能分析工具，可用于分析和优化 Web 应用的性能。如果您的应用在 Chrome 中运行，您可以通过该工具直观地了解浏览器在应用执行期间所执行的操作。了解此活动有助于您发现可采取行动来提升性能的模式、瓶颈和性能热点。
以下示例将引导您使用效果面板。
设置和重新创建性能分析场景
最近，我们制定了一个目标，即提高效果面板的性能。具体而言，我们希望它能够更快地加载大量性能数据。例如，分析长时间运行的进程或复杂进程或捕获高粒度数据时，就属于这种情况。为此，首先需要了解应用的表现和表现如此的原因，这可以通过使用性能分析工具来实现。
正如您所知，DevTools 本身就是一款 Web 应用。因此，可以使用 Performance 面板对其进行分析。如需对此面板本身进行性能分析，您可以打开开发者工具，然后打开与其相连的另一个开发者工具实例。在 Google 内部，这种设置称为“DevTools-on-DevTools”。
设置就绪后，必须重新创建要分析的场景并进行记录。为避免混淆，我们将原始 DevTools 窗口称为“第一个 DevTools 实例”，将用于检查第一个实例的窗口称为“第二个 DevTools 实例”。
在第二个 DevTools 实例中，性能面板（以下简称“性能面板”）会观察第一个 DevTools 实例，以重现该场景，从而加载配置文件。
在第二个 DevTools 实例中，系统会开始实时录制，而在第一个实例中，系统会从磁盘上的文件加载配置文件。加载大型文件是为了准确分析处理大型输入的性能。当两个实例都完成加载后，性能分析数据（通常称为跟踪记录）会显示在加载配置文件的性能面板的第二个开发者工具实例中。
初始状态：发现改进机会
加载完成后，我们在下一个屏幕截图中观察到第二个性能面板实例出现了以下问题。重点关注主线程的活动，该活动显示在标记为主的轨道下方。可以看到，火焰图中有五大组活动。这些任务是指加载时间最长的任务。这些任务的总时间约为 10 秒。在以下屏幕截图中，效果面板用于重点关注这些活动组，以查看可以发现哪些问题。
第一个活动组：不必要的工作
很明显，第一组 activity 是仍在运行但实际上不需要的旧版代码。基本上，标记为 processThreadEvents 的绿色块下的所有内容都浪费了精力。这一路很快就赢了。移除该函数调用大约节省了 1.5 秒的时间。棒极了！
第二个活动组
在第二个 activity 组中，解决方案并不像第一个那样简单。buildProfileCalls 大约需要 0.5 秒，而且无法避免执行此任务。
出于好奇，我们在性能面板中启用了内存选项以进行进一步调查，发现 buildProfileCalls activity 也使用了大量内存。在这里，您可以看到蓝色线图在运行 buildProfileCalls 时刻附近突然跳跃，这表明可能存在内存泄漏。
为了跟进这一怀疑，我们使用 Memory 面板（开发者工具中的另一个面板，不同于 Perf 面板中的 Memory 抽屉式导航栏）进行了调查。在“内存”面板中，选择了“分配抽样”性能分析类型，该类型会为加载 CPU 性能文件的性能面板记录堆快照。
以下屏幕截图显示了收集的堆快照。
从此堆快照中，我们可以观察到 Set 类占用了大量内存。通过检查调用点，我们发现将 Set 类型的属性分配给大量创建的对象是不必要的。这些开销会累加起来，并会消耗大量内存，以至于应用在处理大量输入时经常会崩溃。
集非常适合存储不重复的项，并提供利用其内容唯一性的操作，例如删除重复的数据集和提供更高效的查找功能。但是，由于存储的数据必定与源数据不同，因此这些功能并不是必需的。因此，集合从一开始就没有必要。为了改进内存分配，属性类型已从 Set 更改为普通数组。应用此更改后，系统会再截取一个堆快照，并观察到内存分配有所减少。尽管此更改并未带来显著的速度提升，但带来的附带好处是应用崩溃的频率降低了。
第三个活动组：权衡数据结构的利弊
第三部分比较特殊：您可以在火焰图中看到，它由狭窄但较高的列组成，表示深层函数调用，在本例中表示深层递归。此部分总时长约为 1.4 秒。从该部分底部可以看出，这些列的宽度由一个函数的持续时间决定：appendEventAtLevel，这表明它可能是瓶颈
在 appendEventAtLevel 函数的实现中，有一个特别之处。对于输入中的每个数据条目（在代码中称为“事件”），系统会向地图添加一个项目，用于跟踪时间轴条目的垂直位置。这很有问题，因为存储的内容量非常大。映射适用于基于键的查找，速度快，但这项优势并非不劳而获。例如，随着映射变得越来越大，向其中添加数据可能会因重新哈希而变得昂贵。当大量项连续添加到地图中时，此开销会变得明显。
/**
* Adds an event to the flame chart data at a defined vertical level.
*/
function appendEventAtLevel (event, level) {
// ...
const index = data.length;
data.push(event);
this.indexForEventMap.set(event, index);
// ...
}
我们尝试了另一种方法，无需为火焰图中的每个条目在映射中添加项。改进非常显著，这证实了瓶颈确实与把所有数据添加到地图所产生的开销有关。活动组所需的时间从大约 1.4 秒缩短到了大约 200 毫秒。
之前：
之后：
第四个 activity 组：推迟非关键工作并缓存数据以防止重复工作
放大此窗口后，您可以看到有两个几乎完全相同的函数调用块。通过查看调用的函数的名称，您可以推断出这些块包含构建树的代码（例如，名称为 refreshTree 或 buildChildren 的代码）。事实上，相关代码就是用于在面板底部的抽屉中创建树视图的代码。有趣的是，这些树状视图不会在加载后立即显示。相反，用户需要选择树视图（抽屉中的“自下而上”“调用树”和“事件日志”标签页），才能看到树。此外，从屏幕截图可以看出，该树构建过程执行了两次。
我们发现此图片存在两个问题：
- 某个非关键任务妨碍了加载时间的性能。用户并不总是需要其输出。因此，该任务对配置文件的加载并不重要。
- 这些任务的结果未缓存。因此，尽管数据没有变化，系统还是计算了两次树。
我们首先将树计算推迟到用户手动打开树视图时。只有这样，才有必要为打造这些树木付出代价。两次运行此代码的总时间约为 3.4 秒，因此延迟执行对加载时间有很大影响。我们仍在研究如何缓存此类任务。
第五个 activity 组：尽可能避免复杂的调用层次结构
仔细研究这个组后，我们发现系统正在反复调用特定的调用链。相同的模式在火焰图的不同位置出现了 6 次，该窗口的总时长约为 2.4 秒！
多次调用的相关代码负责处理要在“迷你地图”上渲染的数据（面板顶部的时间轴活动概览）。我们尚不清楚为什么会多次发生，但肯定不会发生 6 次！事实上，如果未加载其他配置文件，代码的输出应保持最新状态。从理论上讲，该代码应该只运行一次。
经过调查，我们发现相关代码之所以被调用，是因为加载流水线中的多个部分直接或间接调用了用于计算迷你地图的函数。这是因为程序的调用图的复杂性会随时间推移而演变，并且不知不觉中会向此代码添加更多依赖项。此问题没有快速解决方法。解决方法取决于相关代码库的架构。在本例中，我们必须略微降低调用层次结构的复杂性，并添加一项检查，以防止在输入数据保持不变时执行代码。实现后，时间轴如下所示：
请注意，迷你地图渲染执行会发生两次，而不是一次。这是因为系统会为每个配置文件绘制两个迷你地图：一个用于面板顶部的概览，另一个用于从历史记录中选择当前可见的配置文件的下拉菜单（此菜单中的每个项都包含其所选配置文件的概览）。尽管如此，它们具有完全相同的内容，因此其中一个应该能够重复用于另一个。
由于这些迷你地图都是在画布上绘制的图片，因此只需使用 drawImage 画布实用程序并随后仅运行一次代码即可节省一些额外时间。经过这些努力，该组的时长从 2.4 秒缩短到了 140 毫秒。
总结
应用所有这些修复程序（以及其他一些小修复程序）后，配置文件加载时间轴的变化如下所示：
之前：
之后：
完成改进后的加载时间为 2 秒，这意味着您不费吹灰之力即可实现约 80%的改进，因为大部分改进都是由快速修复完成的。当然，正确确定最初要执行的操作至关重要，而性能面板是执行此操作的理想工具。
另外，请务必强调这些数字仅适用于作为研究对象的配置文件。该配置文件特别大，因此引起了我们的注意。不过，由于每个配置文件的处理流水线都是相同的，因此所实现的显著改进会应用于性能面板中加载的每个配置文件。
要点总结
关于应用性能优化，您可以从这些结果中汲取一些经验教训：
1. 利用性能分析工具找出运行时性能模式
性能分析工具非常有助于了解应用在运行期间发生的情况，尤其是发现有哪些机会可以提升性能。Chrome DevTools 中的“Performance”面板是 Web 应用的绝佳选择，因为它是浏览器中的原生 Web 性能分析工具，并且会积极维护，以便随时提供最新的 Web 平台功能。此外，它的速度现在也快了很多！😉
使用可用作代表性工作负载的示例，看看您能发现什么！
2. 避免使用复杂的调用层次结构
请尽可能避免使调用图过于复杂。复杂的调用层次结构很容易引入性能回归问题，并且很难理解代码以何种方式运行，这会导致很难实现改进。
3. 找出不必要的工作
老旧的代码库通常包含不再需要的代码。在我们的示例中，旧版和不必要的代码占据了总加载时间的很大一部分。移除它是最容易实现的目标。
4. 恰当使用数据结构
使用数据结构来优化性能，但在决定使用哪种数据结构时，也要了解每种数据结构带来的成本和权衡。这不仅包括数据结构本身的空间复杂性，还包括适用操作的时间复杂性。
5. 缓存结果以避免针对复杂或重复操作进行重复工作
如果操作的执行成本较高，则有必要存储其结果，以备下次需要时使用。如果操作要执行多次，这样做也很有意义，即使每次操作的开销并不特别大也是如此。
6. 推迟非关键工作
如果不需要立即获得任务的输出，并且任务执行会延长关键路径，请考虑在真正需要其输出时延迟执行该任务，方法是延迟调用该任务。
7. 对大型输入使用高效算法
对于大量输入，最佳时间复杂度算法至关重要。我们在本例中没有探讨此类别，但它们的重要性不言而喻。
8. 附加内容：对流水线进行基准测试
为了确保不断演变的代码保持快速运行，建议您监控代码行为并将其与标准进行比较。这样，您就可以主动发现回归问题并提高整体可靠性，为取得长期成功做好准备。