如果你正在使用WebRTC进行开发，那你需要特别注意浏览器版本的更新。因为这些版本可能会破坏你的应用程序。下面我会谈谈我是如何处理这个问题的。

过去一周内，我不止一次被问到WebRTC的向后兼容性如何。这是一个内涵丰富的话题，我们用一个比喻来说明WebRTC的开发过程，请看下面这个视频。

Saudi’s Again Changing Wheels Tyres while driving!

当你使用WebRTC进行开发时（特别是Google WebRTC团队的开发人员），你会感觉就像在高速公路上边开车边更换轮胎。

浏览器更新周期

浏览器的更新周期很短，也很复杂。

• Chrome和Firefox大约每6周更新一次
• Safari每年两次
• Edge刚开始使用Chromium。微软会选择哪种更新频率呢？是以Google Chrome的速度来、比它更快还是更慢呢？我们拭目以待。
• 这就是大致思路的梳理。下图是2017年的数据，右栏是我们上述情况的总结：

浏览器自动更新发生在大型版本更新期间，短于2个月（Safari是例外）。并且在必要时，自动更新会主要版本更迭期间发布并推送安全性或稳定性版本。

2020年，浏览器更新频率将保持不变，甚至更快。

WebRTC的改革步伐

说到我过去几年中使用WebRTC的经验，下图很好地做了总结：

对于终端用户而言，这是真正的乐趣。大多数人甚至不知道他们正在使用WebRTC，但他们确实在用。

另一方面，开发人员则惴惴不安。因为不断的变化意味着他们面临的挑战更多。

不得不说，这比我们以前的替代方案好得多。

WebRTC保持不断变化的方式有3种：

1. WebRTC浏览器实现与WebRTC规范。我们正在处理尚未完成的协议规范和更改浏览器，以缩小实现与规范内容之间的差距。这些更改有时不能向后兼容；
2. 引入新功能。mDNS是一个很好的例子。不建议使用DTLS 1.0也是一个好的范例。接下来是Google Stadia（及其他）的播放延迟增加。不知道为什么，有些必须添加的内容是为提高安全性或连接性而引入，但他们可能会破坏互操作性；
3. 优化。在实现中不断变化可以提高性能。在这里你可以重写回声消除器、修改音频的整个线程模型，并从接收器侧带宽估算切换到发送器侧。

这些不仅是新功能的介绍。更重要的是这些新功能包含大量WebRTC本身的行为更改。

WebRTC的改革步伐不会在2020年放缓。

WebRTC服务器端挑战

如果你的应用程序在云中并且在浏览器之前运行，那么你要做的就相对简单了。只要你会用adapter.js之类的工具、熟练使用各种浏览器的beta和开发通道，那么大多数情况你都可以应对。

但一旦你使用媒体服务器，事情就会变得复杂了。

现在大多数媒体服务器都是开源的。维护它们的团队规模很小并且有很多工作要做。二商用服务器情况也不很乐观。

我们知道，Google WebRTC小组会开发功能、错误修复和优化。他们的主要关注自家的需求、规范内容以及与其他浏览器的互相操作性。即使他们愿意，他们也无法放下手头的工作去向周围人解释一切。

文章地址：https://bloggeek.me/webrtc-application-keep-pace-browser-releases/?nsukey=va07z5qKbK9WmVX7MDmfZYxdfABkM4BmN%2B5NigPiS8NdPOVB10X3vs98gjnexFU0rm%2Fs4FD2Yq2xK6h3jKFYYm6wii49%2FEuydz6IKbx9588UuYFqLRAfC%2BzSq9hPmHXHwu1PrCQK1ia518TTSvB%2Fvm6kr9CGTRNO8OvkHqJMfBka2tP2qe7gvhJ5FnWVkKxOsD2qJZe9O17mpuHBRvM7KQ%3D%3D

原文作者：Tsahi Levent-Levi