持续创作，加速成长！这是我参与「掘金日新计划 · 6 月更文挑战」的第2天，点击查看活动详情
前言
随着近几年直播平台，短视频APP的崛起，加上疫情对这部分产业的正向影响，导致WebRTC的成了一个很火的词。甚至在我的团队里，偶尔也会听到有人说想要用或者正在用WebRTC。但我一看代码发现其实就是用了下mediaStream，也算不上是严格的WebRTC。那么怎样才应该算是WebRTC呢？
究竟什么是WebRTC？
WebRTC的全称是 (Web Real-Time Communication)，翻译过来就是网络即使通信。它诞生的目的是为WEB开发者提供一套实时通信功能并形成开放标准。也就是说，使用WebRTC可以实现在对等设备之间发送视频、语音和通用数据，满足诸如语音和视频通信解决方案。因此涉及如视频聊天，语音通话，客户端之间文件分享等业务都可以考虑使用WebRTC。
实际上WebRTC API由三个部分组成：
- getUserMedia() ： 获取摄像头或麦克风等设备数据
- RTCPeerConnection： 提供点对点的数据连接方法，实际屏幕监控管理。
- RTCDataChannel： 提供一个网络通道，用于数据的双向对等传输
综上，WebRTC本质上不是一个单一工具，而是由一系列工具库组成的客户端套件，或者准确的说是一个完整的解决方案。
我应不应该用WebRTC？
好的，现在我们疑惑应该是，我们究竟应不应该用WebRTC？其实前文也提到了，如果你现在业务类型是涉及到音像传输的，WebRTC会是你很好的选择。
无论是大型的音像项目如：
- 视频会议
- 远程控制
- 网络直播
或者是仅涉及音频传输的：
- 智能音箱
- 智能客服
WebRTC究竟强在哪里？
当我们在讨论一个是否应该采用某个技术的时候，实际上我们考虑的是这个技术是否会为团队降低成本，或者带来更大的收益？
换个角度思考，假如不用WebRTC在面对同样的业务场景时，我们还有哪些选择？遗憾的告诉大家，在这方面几乎没有与WebRTC有同等竞争力的方案。它的优势表达如下：
强大的整合能力
WebRTC在针对音像传输这方面表现出了极大的优势，它从硬件数据获取，数据编码/解析，再到数据传输等环节都作了完整的整合。为用户提供了便捷的API。
上图是一个涉及音像数据传输的程序数据转换流程。如果开发者选择自研方案，他面临的将会是：
- 需要自己开发数据获取模块
- 需要自己开发数据解析模块
- 需要自己开发数据传输模块
- 需要做大量的跨平台兼容工作
尽管这其中的部分功能可以在开源市场上找到相关的工具库，但往往整体的业务模块还是需要开发者自行调试开发的。这其中的工作量和开发难度可想而知。但如果团队采用了WebRTC的方案，这一切问题都将不存在，因为Google和WebRTC的团队已经为我们实现了底层的操作了，开发者只要使用他们提供的API即可。
简单易用的硬件调起能力
想要让一个WEB开发者调用用户的硬件设备，这并不是一件简单的事。目前大部分的WEB开发者对这部分的知识是不够的。这也意味着在面临这种业务的情况下，团队不得不新招一名复杂这部分工作的人，或者花时间培养WEB成员的成长（学习硬件知识，或者相关的工具库）。
强大的平台兼容能力
一般情况下开发一款涉及硬件的应用，需要考虑用户使用的操作系统，硬件的驱动版本等问题。但WebRTC有着出色的团队专门处理这方面的问题。由于WebRTC运行在浏览器上，用户无论使用什么操作系统或硬件，只要能运行浏览器，就可以正常运行WebRTC。因此开发者可以无需担心兼容问题，只要关注业务逻辑部分的代码开发即可。
不断优化的升级能力
随着硬件的发展(CPU，内存等)，程序可以通过进一步利用用户硬件的性能来提高用户体验。一般的软件开发需要由开发者定时指定迭代方案，以及调研最新技术。而使用WebRTC的功能挂靠在浏览器上，只要用户升级浏览器就可以得到由WebRTC团队提供的最新优化代码。业务开发者无需为此操心。
总结
WebRTC本质上是一套由谷歌和专门的团队共同打造的音视频实时通信解决方案，他们在背后为开发者解决了很多诸如系统兼容，硬件调用等问题。使得开发者无需过多地关心复杂的硬件技术，只要专注业务本身。可以说WebRTC大大减低了音视频通信程序的开发门槛，涉及到这方面业务或者有意涉猎这方面业务的团队都应该了解一下的WebRTC的技术。
