2023 年已经到来，充满了激动人心的挑战，大量的开发，修复的错误，但总是像往常一样有很多东西要学习。
但在再次深入研究 WebRTC API 之前，我想首先说声“谢谢”。越来越多的人阅读我的文章，我为此感到非常自豪。
为了开始这个新赛季，我想回到基础：API。因此，更新我的 WebRTC 海报。
为什么？因为我已经有一段时间没有刷新它了，所以也许是时候做它了，因为每次我做它，我都会发现新的 API。
通过浏览 WebRTC API 来刷新我的记忆来开始新的一年，有点像在圣诞节做拼图：一个放松的好时刻:-)
这张海报试图收集 WebRTC 开发人员在开发其应用程序时应牢记的所有 API。因此它包括可以在 WebRTC 范围之外的 API，例如 Web Audio API 或 Permissions API。
但对我来说，今天这些 API 是强制性的，以涵盖将 WebRTC 完整集成到您的应用程序中，或者只是为了了解它是如何工作的，以及如何很好地混合所有内容。
我是如何收集信息的？
为实用起见，我决定只显示至少已存在于一种浏览器中的 API。目标是拥有一份文档，帮助任何开发人员找到他现在可以使用的方法、属性或事件。最终不会在未来。一般来说，Chrome 是最好的选择。
因此，一方面，我可以访问W3C或Whatwg的规范，另一方面，我可以使用 Chrome 控制台，在这里我可以通过查看“原型”定义来检查任何接口。
// 给出RTCPeerConnection接口的原型
RTCP 对等连接.原型
RTCP 对等连接 {
添加冰候选:F添加冰候选() // 一个方法
添加流:F添加流()
...
canTrickleIceCandidate: (...) // 一个属性
冰连接状态: (...)
...
连接状态改变: (...) // 一个事件
曾经的候选人: (...)
}所以每次我阅读规范或文章时，我都会使用浏览器控制台来检查提到的 API 的可用性。
该方法易于使用，并允许我发现 API。有时可以直接从控制台使用它们。
但是有一个问题：从长远来看，这种方法是不可复制的。如果每次，我都必须查看每个界面以检查结果以及所有浏览器……
这就是为什么，我开发了一个小工具来帮助我自动发现每个界面的原型。
WebRTC 接口检查器
我开发了一个小型 JavaScript 应用程序来自动收集接口。
该工具的代码可以在GitHub 中找到：WebRTC API Graph
对于这个工具，背后并没有那么神奇。每次我发现一个尚未见过的新界面时，我都会将其添加到我的参考文件中。
然后该工具遍历所有界面，并为每个界面收集所用浏览器中可用的属性、事件和方法。
为了更深入地帮助我，我添加了几件事：
- 美人鱼图：我添加了所有使用美人鱼的类的图形表示，并在主要界面之间建立了链接：这是我制作海报的第一个想法，但由于我没有花太多时间改进美人鱼，结果很好但不足以打印
- 文件提取器：所有原型都保存到一个文件中，以便逐个版本或浏览器与浏览器进行比较
海报设计
所以，最后，为了拥有一张好的海报，我决定根据我的工具的结果手动创建它。
我花了几天时间聚合所有界面并按主题对它们进行分组。
然后，为了增强海报效果，我添加了以下似乎相关的信息。
参考规范文件
为每个主题添加描述 API 的规范文档的名称。
标准化程度
我为每个主题添加了一个徽章，以链接到所描述 API 的标准化水平。为了简单起见，我只使用了 3 个级别：实验、实施、稳定：
- 稳定：主要浏览器的实现遵循大多数接口的标准。您可以在生产中使用这些 API。
- 实施：规范很合适，但浏览器会受到实施的影响（但至少有一个浏览器已经实施了这些接口）。通过首先检查它们是否存在或依赖现有的 shime 来小心使用它们。
- 实验性：API 实现处于早期阶段，或者是浏览器的选择或兴趣来实现。至少有一个规范提案（或规范的早期阶段）。不建议在生产中使用这些 API……
注意：我停留在主题层面，对于一些API，即使是稳定的类别，最好检查是否存在并依赖shime以防万一。
浏览器
实现主题的浏览器：如果实现了至少50%的API（任意选择）和不稳定的主题，我添加了它。
接口之间的链接
我在接口之间添加了链接，意思是“从这个接口，你可以通过使用属性、方法或事件来访问这个接口”。
对我来说，这非常有帮助，因为理解如何从一个界面切换到另一个界面并不容易。
格式
最后，对于那些想要打印它的人，我尽量尊重 A3 格式（我希望它可以使用 A3 阅读）。
海报
结果就是这张巨幅海报……
我惊讶地发现 WebRTC 开发人员需要熟悉大量接口。
当然，这取决于您的需求和您拥有的 WebRTC 集成级别，但由于我们希望对生成的质量有更多控制，因此添加了越来越多的接口以便能够在低级别操作流。
我真的很喜欢能够一次性涵盖所有这些API。因为我不是每天都在使用它们，它可以帮助我快速确定正确的方法来做我要做的事情。
下一步
第一步是让你在我犯错误时进行更改，或者提出缺少的 API 或一种收集它们的新方法。
为此，我将海报参考文件放在 GitHub 存储库中：WebRTC-API Landscape。
正如使用出色的Excalidraw工具所做的那样，很容易适应您的需求或提出更改建议。
第二步是保持更新。我不知道今天我应该遵循哪个节奏：每个季度、每年两次或每年一次。诸如此类的 APIWebTransport或许应该成为下一次迭代的一部分。
作者：Olivier Anguenot
原文链接：https://www.webrtc-developers.com/webrtc-api-landscape-in-2023/
本文来自作者投稿，版权归原作者所有。如需转载，请注明出处：https://www.nxrte.com/jishu/webrtc/9429.html
