RTCPeerConnection 的 addTransceiver、addTrack、addStream，到底该用哪个

一起养成写作习惯！这是我参与「掘金日新计划 · 4 月更文挑战」的第1天，点击查看活动详情。

太久没有和人沟通技术方案，把做项目中遇到的问题拿来水水文章锻炼一下表达能力。

开发 WebRTC 的时候，publish 是通过将 MediaStream 添加到 RTCPeerConnection 中，一查接口，竟然有addTransceiver、addTrack、addStream 三种方式可以实现，到底有啥区别，为啥要搞这么多让我选择。

最开始查资料的时候还不是很懂，看文档讲的都很官方，完全看不懂这三个接口的区别在哪，真的就是茴香豆的几种写法吗？

虽然一头雾水，开发的时候开始还是优先使用 addTransceiver 接口，不支持的浏览器使用 addTrack 做兼容。

在使用 WebRTC 很长一段时间之后才算是弄懂了这三个接口之间的区别。

最开始的时候本地的声音和视频使用同一个 MediaStream 管理，后续开发过程中碰到问题，更新视频源或者音频设备的时候音轨个视频轨都需要更新，印象最深的问题是切换视频设备的时候声音会有一小段的中断，不使用 addStream 是毫无疑问的。

addTransceiver 和 addTrack 都可以单独处理视频轨和音频轨，目前使用过程中碰到两个场景感受到addTransceiver 的优势：

使用 Janus 开发的视频会议，网络即使再好，使用 addTrack 在我的电脑上码流最大也只能到 2.6M 左右，对于有些需要 4K 大码流，addTransceiver 可以通过设置 sendEncodings 参数支持超大码率的码流。
在开发一个类似与 vmix 的导播台界面时，同时需要通过 WebRTC 推一个预览和一个输出的流给 SRS，预览的流分辨率很小，码率也不需要很大，输出的流需要码率稳定，不要变化太大。SRS 暂时还没有办法单独限制某一个 RTCPeerConnection 的码流，这种情况也可以通过设置 addTransceiver 的 sendEncodings 参数来控制不同流的码率，同时也能保证码率大小的稳定性。

打个广告，希望有 WebRTC 前端或者前端音视频相关岗位可以帮我内推一下，留言或邮件都可以，邮箱是 kunkkaco@gmail.com。