了解如何使用 about://tracing 和 Audion（Chrome 开发者工具中的 WebAudio 扩展程序）在 Chrome 中分析网络音频应用的性能。
您之所以看到本文，可能是因为您正在开发的应用使用 Web Audio API，并遇到了意外故障，例如输出的爆破音或听到的内容。您可能已经参与了 crbug.com 讨论，Chrome 工程师要求您上传“跟踪数据”或查看图表可视化内容。本文介绍了如何获取相关信息，以便我们了解问题并最终解决根本问题。
网络音频分析工具
about://tracing 和 Chrome 开发者工具中的 WebAudio 扩展程序有两个工具可以帮您分析网络音频。
您何时使用 about://tracing？
当神秘的“故障”发生时。使用跟踪工具对应用进行性能分析可深入了解以下方面：
- 特定函数调用在不同线程上花费的时间片
- 时间轴视图中的音频回调时间
它通常会显示错过音频回调截止日期或可能导致意外音频干扰的大量垃圾回收。此信息对于了解基本问题非常有用，因此 Chromium 工程师经常会询问此信息，尤其是在本地再现不可行时。有关跟踪的一般说明，请点击此处。
何时使用 Web Audio 开发者工具扩展程序？
当您想要直观呈现音频图表并监控音频渲染程序的实时表现时。音频图表（用于生成和合成音频流的 AudioNode 对象网络）通常会变得很复杂，但图表拓扑在设计上是不透明的。（Web Audio API 没有节点/图自检功能。）图表中发生了一些变化，现在您听到的是静音。然后，就可以通过监听进行调试了。这从来都不是一件容易的事，当音频图变大时，这就会变得更加困难。Web Audio DevTools 扩展程序可以通过可视化图表为您提供帮助。
借助此扩展程序，您可以监控渲染容量的运行估算值，了解网络音频渲染程序在给定渲染预算（例如约 2.67 毫秒 @ 48KHz）下的性能。如果容量接近 100%，则意味着您的应用很可能会出现故障，因为渲染程序无法在给定的预算内完成相应工作。
使用 about://tracing
如何捕获跟踪数据
以下说明适用于 Chrome 80 及更高版本。
为了获得最佳效果，请关闭所有其他标签页和窗口，并停用扩展程序。 或者，您也可以启动新的 Chrome 实例，或使用不同发布渠道（例如 Beta 版或 Canary 版）的其他 build。准备好浏览器后，请按以下步骤操作：
- 在标签页上打开应用（网页）。
- 打开另一个标签页，前往
about://tracing。 - 按 Record（录制）按钮，然后选择 Manually select settings（手动选择设置）。
- 按 Record Categories（记录类别）和 Disabled by Default Categories（默认类别）部分中的 None 按钮。
- 在 Record Categories（记录类别）部分，选择以下选项：
audioblink_gcmediav8.execute（如果您希望了解AudioWorkletJS 代码性能）webaudio
- 在默认类别为停用的类别部分中，选择以下选项：
audio-worklet（如果您想了解AudioWorklet线程的起始位置）webaudio.audionode（如果您需要每个AudioNode的详细跟踪记录）
- 按底部的录制按钮。
- 返回您的应用标签页，重新执行触发问题的步骤。
- 获得足够的跟踪数据后，返回“跟踪”标签页，然后按 Stop。
“跟踪”标签页会显示相应结果。
按 Save 以保存跟踪数据。
如何分析跟踪数据
跟踪数据直观呈现了 Chrome 的网页音频引擎如何渲染音频。渲染程序有两种不同的渲染模式：操作系统模式和 Worklet 模式。每种模式使用不同的线程模型，因此跟踪结果也不同。
操作系统模式
在操作系统模式下，AudioOutputDevice 线程会运行所有 Web 音频代码。AudioOutputDevice 是一个实时优先级线程，源自浏览器的音频服务，由音频硬件时钟驱动。如果您发现此通道中的轨迹数据出现不规则，则表示来自设备的回调时间可能会抖动。已知 Linux 和 Pulse Audio 组合会存在此问题。如需了解详情，请参阅以下 Chromium 问题：#825823、#864463。
Worklet 模式
在 Worklet 模式下，一个线程从 AudioOutputDevice 跳到 AudioWorklet 线程，您应该会看到两个线程通道中对齐的轨迹，如下所示。激活 Worklet 后，所有网络音频操作都由 AudioWorklet 线程呈现。此线程目前不是实时优先级线程。
这种情况常见的不规律是由于垃圾回收或错过渲染截止日期而导致的一个大块。这两种情况都会导致音频流出现故障。
在这两种情况下，理想的跟踪数据的特征是：音频设备回调调用保持一致，并且渲染任务能在指定的渲染预算内顺利完成。上面的两个屏幕截图就是理想的跟踪数据示例。
从真实示例中学习
示例 1：超出渲染预算的渲染任务
下面的屏幕截图（Chromium 问题 796330）是一个典型示例，显示了 AudioWorkletProcessor 中的代码何时花费了太长时间并超出了给定的渲染预算。回调时间表现良好，但 Web Audio API 的音频处理函数调用未能在下一次设备回调之前完成工作。
您的选项：
- 减���使用
AudioNode实例，减少音频图表的工作负载。 - 减少
AudioWorkletProcessor中的代码工作负载。 - 增加
AudioContext的基本延迟时间。
示例 2：在 Worklet 线程上执行大量垃圾回收
与操作系统音频渲染线程不同，垃圾回收在 Worklet 线程上管理。这意味着，如果您的代码执行内存分配/取消分配（例如新建数组），则最终会触发垃圾回收，而垃圾回收会同步阻塞线程。如果 Web 音频操作和垃圾回收的工作负载超出给定的渲染预算，则会导致音频流中出现故障。以下屏幕截图是这种情况的一个极端示例。
您的选项：
- 预先分配内存，并尽可能重复使用。
- 根据
SharedArrayBuffer使用不同的设计模式。虽然这并不是一个完美的解决方案，但一些 Web 音频应用会将类似的模式与SharedArrayBuffer结合使用来运行密集型音频代码。示例：
示例 3：来自 AudioOutputDevice 的抖动音频设备回调
音频回调的精确时间对网络音频来说是最重要的。这应该是您系统中最精确的时钟。如果操作系统或其音频子系统无法保证可靠的回调时间，则所有后续操作都会受到影响。下图是抖动音频回调的示例。与前两张图片相比，每个回调之间的时间间隔差异很大。
您的选项：
- 通过调整
latencyHint选项来增加系统音频回调缓冲区空间。 - 如果您发现问题，请在 crbug.com 上提交问题并附上跟踪数据。
使用 Web Audio 开发者工具扩展程序
您也可以使用专为 Web Audio API 设计的开发者工具扩展程序。与跟踪工具不同，这可以实时检查图表和性能指标。
此扩展程序需要从 Chrome 应用商店安装。
安装后，您可以通过打开 Chrome 开发者工具并点击顶部菜单中的“Web Audio”来访问该面板。
网络音频面板包含四个组件：上下文选择器、属性检查器、图表可视化工具和性能监控器。
上下文选择器
由于一个页面可以有多个 BaseAudioContext 对象，因此您可以通过此下拉菜单选择要检查的上下文。您也可以点击左侧的垃圾桶图标，手动触发垃圾回收。
属性检查器
侧边栏显示了用户选择的上下文或 AudioNode 的各种属性。不支持检查“AudioParam”中的动态值。
图形可视化工具
此视图会呈现用户所选上下文的当前图表拓扑。该可视化效果会实时动态变化。通过点击可视化图表中的元素，您可以在属性检查器中检查详细信息。
性能监控
仅当选定的 BaseAudioContext 是实时运行的 AudioContext 时，底部的状态栏才处于活动状态。此竖条显示所选 AudioContext 的瞬时音频流质量，并且每秒更新一次。它提供了以下信息：
回调间隔（毫秒）：显示回调间隔的加权平均值/方差。理想情况下，平均值应保持稳定，且方差应接近零。如果您发现差异较大，则表示系统级音频回调函数的计时不稳定，可能会导致音频流质量不佳。（参见上面的示例 3。）
渲染容量（百分比）：当容量接近 100% 时，表示渲染程序针对给定的渲染预算执行了过多的处理，因此您应该考虑减少所用的资源（例如，在图中使用更少的
AudioNodes对象）。
您可以点击垃圾桶图标，手动触发垃圾回收器。
旧版 WebAudio 开发者工具面板
此扩展程序现在是 Chrome Web Audio 团队的推荐方法，不过您也可以使用旧版 WebAudio 开发者工具面板。如需访问此面板，请点击开发者工具右上角的“三个点”菜单，然后前往更��工具，再点击 WebAudio。
总结
调试音频很困难。在浏览器中调试音频的难度更大。不过，这些工具可以为您提供有关 Web 音频代码性能的实用数据分析，从而减轻麻烦。但在某些情况下，您可能会在 Chrome 或扩展程序中发现问题。然后，不要害怕在 crbug.com 上或扩展程序问题跟踪器上提交 bug。
照片由 Jonathan Velasquez 在 Unsplash 上推出