作者：Tsahi Levent-Levi，Philipp Hancke（原文链接）
翻译：刘通
原标题：What is WebRTC adapter.js and Why do we Need it?
adapter.js是结合你代码和不同浏览器的WebRTC实现的粘合剂。
本篇文章是和Philipp Hancke一同撰写的。在过去两年中，他一直在助理adapter.js的发展，所以邀请他来完成本文章的一大部分内容是非常合适的。你可以在这里看到他的其他文章作品。
这是在我最开始研究WebRTC的时候做的一个图：
这里的主要概念是展示WebRTC与传统VoIP的不同之处。
在传统VoIP中，你有多个供应商实施该规范，希望实现能够相互协作。如果你知道一个VoIP的实现，它也不代表你也能了解另一个VoIP的能力。
WebRTC有所不同，它有很多概念都没有规定，但也规定了HTML5；我的意思是让每个开发人员都可以使用一个API将交互式语音和视频添加到他的应用程序中。
getUserMedia，PeerConnection和数据通道都是WebRTC中指定的API。而这也创造了一个生态系统。传统的VoIP不可能有这样的力量。
但问题是，你可以只将WebRTC API视为一种建议。这是因为直到今天，规范的1.0版本也没有成为现实。WebRTC的浏览器实现更像是同一种语言的方言。你自己说一种方言，你可以听懂另外一种方言，但又不能完全理解。如果说着两种不同方言的人试图在没有耐心或彼此理解的情况下进行交谈，就会发生不好的事情。
这也许就是adapter.js发挥作用的地方。
在我们问自己adapter.js在今天是否需要之前（是的我们需要），我们首先应该花点时间理解它发展过程。
adapter.js的起源
adapter.js自2012年底或者2013年初WebRTC早期的时候就已经出现了。它最初是Google的apprtc demo的一部分。原始版本仍可在Chrome tree中找到。它是一个非常小的项目，还没有150行。主要功能是隐藏像webkitRTCPeerConnection和mozRTCPeerConnection这样的前缀差异，并提供函数将MediaStream附加到HTML的<audio>或<video>元素。
在WebRTC自由发展的日子里，每个人都在编写自己的库，使WebRTC更加简单。这在2015年中期开始发生变化，当时微软的Edge浏览器也出现了。虽然Edge浏览器不需要getUserMedia的前缀，但将MediaStream附加到视频元素仍然可以在三种不同的实现中使用。这表明有必要出现一种标准化的行为。另外，正如微软的Bernard Aboba指出的那样，书籍中出现的API的前缀版本—这是错误的引导。
相比于WebRTC 1.0 API，微软更倾向于ORTC，并且非常乐意支持在ORTC之上添加RTCPeerConnection API。这启用了早期的互操作性测试，并允许在第一个可以使用ORTC的Edge公开版本之前消除一些错误。
之后，Promise支持被添加到adapter.js中。转向Promise是WebRTC规范中的重大变革之一，尽管Firefox已经迅速地加入它们，但是Chrome还是落后了。此时adapter的“使命声明”发生了变化。而不是仅仅试图填补空白，它成为了一个推动者，允许开发者编写现代的WebRTC JavaScript。Mozilla的Jan-Ivar Bruaroey意识到这一点，并开始为getUserMedia约束提供更多精细的内容。
当Safari开始发布WebRTC时，他们为他们不想发布的WebRTC API的“传统”部分做了一个夹片。这是一个让开发人员编写基于Promise的现代WebRTC代码的有趣的尝试。但是遗憾的是，默认情况下已启用传统API附带的发行版本似乎并未奏效。
随着复杂性的增加（目前超过2200行代码），对adapter.js代码本身进行更改的测试面临着更多的问题。最初由Selenium提供支持的测试已经分解为单元测试和端到端测试，这些测试使用标准测试工具，如karma，mocha，和chai，在Travis-CI上的各种浏览器中运行时做出决定，并将结果与以前的运行结果做比较。这体现了测试WebRTC库的最新技术水平，并一杯其他项目采用。
在2017年的大部分时间里，主要关注点都在Chrome中填充track-based API。这是向WebRTC 1.0 API迈出的一大步，在Mozilla的这篇博文中有所描述，同样也在adapter.js中。这些测试测试证明确保API的一致性是非常棘手的，因为现有代码可能依赖于与旧API的某些交互，并且该API未被指定。正如往常一样，在大量变化中也有一些回归—但是，在JavaScript库中发现可以固定版本的那些回归比使用本机生成的回归更好。在2018年初，Chrome 64版将会变得更稳定，原生的addTrack版本将会替代产生。注意：由于与getStats相关的错误，addTrack还没有完全准备好作为产品。直到Chrome M65的出现之前，shim还将是首选—确保你的adapter版本在更改后进行了更新。
