WebRTC API 更新 2025

本文内容来自 WebRTC 专家 Olivier Anguenot 的分享。

对于 WebRTC API 而言，2024 年是无聊的一年吗？2024 年，没有全新的 WebRTC API 出现。

相反，浏览器利用这段时间完善了现有的 API，并使其与官方标准更加一致——这种方法通过提高稳定性和一致性，最终使开发人员和最终用户受益。

去年，我在这篇文章《2024 年 WebRTC API 格局》中指出，开发人员必须了解的新接口数量大幅增加。

以下是过去一年的最新统计数据。情况似乎有所不同。

差异主要是我添加的一些现有接口以及缺失的接口。对于 API，这种差异是浏览器中实现规范中定义的一些缺失的 API。
注意：我提供的数量不是官方数字。它基于我选择纳入此 WebRTC 生态系统的 API。

新的工作领域？

开发 WebRTC 应用程序并不意味着只能使用 WebRTC API。即使其 API 生态系统非常庞大。在大多数情况下，我们依赖于与 WebRTC 接近的 API：Web Audio API、Permissions API 等…

新设备、新技术带来了新的 API，这些 API 会开放给 Web 开发人员。

去年，我发现了一些看起来很有前景的 API。

WebGPU API

直到现在，我还没有专门花时间探索 WebGPU API。

正如 MDN 上所述：

“该 API 使 Web 开发人员能够使用底层系统的 GPU（图形处理单元）执行高性能计算并绘制可在浏览器中呈现的复杂图像。”

我犹豫的主要原因是编写着色器（由 GPU 处理的专用指令）需要使用 WGSL（WebGPU 着色语言），它与 Rust 相似，因此许多开发人员对它不太熟悉。

然而，WebGPU 的主要优势在于它能够将诸如背景替换之类的任务转移给 GPU，从而确保更高的性能和更流畅的帧速率。这使得它成为需要实时处理和响应能力的应用程序的有前途的工具。

WebXR API

这是相对较新的，其 API 目前主要在 Chrome 和 Safari 中可用。

WebXR API 旨在处理AR（增强现实）和VR（虚拟现实）体验，统称为XR（跨现实）。与难以管理日益壮大的设备和现实生态系统的旧版WebVR API 不同， WebXR是一种新标准，旨在支持任何类型的现实，从 VR 耳机到支持 AR 的设备。

但是，要有效使用 WebXR，您需要了解 WebGPU 和 WebGL Canvas 的工作原理。WebXR 严重依赖 WebGPU 来呈现沉浸式体验，因此开发人员必须掌握基于 GPU 的编程基础知识。

WebUSB 和 WebBluetooth API

虽然并不是新技术，但 WebUSB 和 WebBluetooth API 允许开发人员直接从浏览器配对和与 USB 和蓝牙设备交互。

结合现有的 WebHID API，这些工具大大扩展了与外部设备交互的能力。从垂直角度来看，这意味着开发人员可以连接摄像头或传感器等专用硬件来实时传输媒体和数据。

工作原理：

• WebUSB 和 WebBluetooth 的功能类似。它们需要通过本机浏览器弹出窗口明确获得用户许可，提示用户授予“已识别”设备的访问权限。这确保了安全且注重隐私的交互。

• 无法实现设备访问自动化。开发人员无法以编程方式检索 USB 或蓝牙设备列表。相反，用户必须手动授予对每个设备的访问权限。

对于那些希望利用这些 API 来更好地识别 WebRTC 应用程序中的设备的人来说，这并不能解决问题，因为您无法检索设备列表。您仍然需要依靠设备标签来区分它们……

Window Management API

在工作时，我们很多人都喜欢尽可能使用多个屏幕。此 API 的目标是通过允许网络应用程序实现无缝多屏体验：

• 检测连接了多少个屏幕。
• 检索有关可用屏幕的详细信息，以优化使用。
• 动态检测屏幕的添加或移除。
• 在特定屏幕上放置窗口（这对于确保 WebRTC 应用程序不会在错误屏幕上打开来电弹窗等情况尤其方便！）。

浏览器的显著变化

以下是我最近看到或即将看到的一些变化。

Chrome M131

关于 WebRTC 或新功能，没有什么有趣的变化。

Chrome M132

Chrome 132 通过一些重大更新弥补了这一不足：

• Captured Surface Control API：该 API 提供了一种转发滚轮事件和调整捕获标签缩放级别的方法。它对于在屏幕共享过程中保持无缝体验特别有用–允许用户在共享内容中滚动或缩放，而无需留在共享应用程序中。

• Window Management(窗口管理)： 如前所述，该 API 支持多屏设置，可让应用程序检测连接的屏幕、管理屏幕的添加/删除以及在特定屏幕上定位窗口。

Chrome M133

展望未来，预计即将发布的 Chrome 133 将提供以下功能：

• 节能模式下冻结：为了最大限度地延长电池使用时间，Chrome 浏览器将暂停已闲置一段时间并消耗大量电池的后台标签页。不过，提供音频或视频会议功能的标签页将例外。这取决于活动的音频/视频设备、带有实时轨迹的对等连接或打开的数据通道。

• 相机效果状态：VideoFrame 的元数据现在将包括是否已对视频帧应用效果（如背景模糊或替换）的信息，从而为开发人员提供更多处理管道控制。

• setDefaultSinkId：这个新方法（在标志后面）将允许开发人员为顶帧及其所有子帧（iFrames）定义默认音频输出设备（扬声器），从而提高多帧应用程序的灵活性。

Chrome M134

Chrome 134 预计将进行以下更新

• 删除非标准 goog- 约束：getUserMedia 的旧非标准 goog- 约束将被删除。虽然此更改不会触发错误，但浏览器将恢复为默认音频约束，从而确保依赖这些过时约束的应用程序能够更顺畅地过渡。
• WebSpeech API 与 MediaStreamTrack 集成：WebSpeech API 将获得对 MediaStreamTrack 的支持。这意味着您将能够提供任何入站 WebRTC 流（例如来自通话的远程音频）用于语音识别或字幕，而不受默认麦克风输入的限制。这扩展了语音识别的多功能性，特别是对于转录或辅助功能增强等应用程序而言。

Firefox 132

Firefox 132 主要关注 API 支持更新，包括对 WebRTC 组件的增强：

• RTCRtpReceiver：增加了对 getParameters() 的支持，可以检索传入 RTP 流的参数。
• RTCRtpSender：引入 canInsertDTMF，检查是否可以发送 DTMF（双音多频）信号。
• MediaStreamTrack：添加了 getCapabilities()，允许开发人员查询给定媒体轨道的功能。

Firefox 133

Firefox 133 围绕WebCodec进行了重大改进，包含三个新界面：

• ImageDecoder：有助于高效解码图像文件。
• ImageTrack：表示图像序列中的单个轨道。
• ImageTrackList：图像轨道的集合，用于处理图像序列（例如动画内容）。

Firefox 134

Firefox 134 在屏幕共享中引入了对 VP8 Simulcast 的支持，允许在屏幕共享会话期间使用 VP8 编码中的多个层。然而，这方面的实际用例仍不清楚，因为在大多数情况下，管理屏幕内容的低分辨率层可能并不简单或特别有益。

遗憾的是，即将推出的 Firefox 版本的发行说明（下一个版本将在几天后发布）仍然不可用，让我们只能猜测未来的更新。

Safari 18.0

Safari 18.0 推出了几项值得注意的更新，解决了 WebRTC 和其他领域的关键差距：

• getStats API 增强功能：getStats API 添加了大量以前缺失的统计数据，使得 Safari 在 WebRTC 调试和性能监控方面更接近其他浏览器。
• Web Workers 中的 MediaStreamTrack 处理：此版本引入了在 Web Workers 中处理 MediaStreamTrack 的支持，可以从主线程卸载复杂的媒体任务，提高实时应用程序的性能。
• Vision Pro 的WebXR 支持：Safari 18.0 还首次推出了 WebXR 支持，专为 Apple 的混合现实耳机 Vision Pro 量身定制，为沉浸式 AR/VR 体验铺平了道路。

Safari 18.1 和 18.2

年底前发布的后续小更新仅侧重于错误修复和稳定性改进，没有添加任何重大新功能。

而且，就像 Safari 经常出现的情况一样，没有任何关于下一步将发生什么的信息——让我们悬着心！

小结

总而言之，2024 年的重点是提高稳定性、修复错误和增强 WebRTC 的浏览器兼容性。

虽然这些更新看起来不那么引人注目，但它们对于为开发人员和用户构建更可靠、更无缝的体验至关重要。

展望未来，我们很高兴看到 2025 年 WebRTC 生态系统将迎来创新和进步。

作者：Olivier Anguenot
译自：https://www.webrtc-developers.com/webrtc-api-update-2025/