在与同行交流过程中，发现很多同行对 WebRTC 改动太多，导致无法升级 WebRTC 版本。而 WebRTC 开源社区的快速迭代，让他们感到欣喜又焦虑：开源社区的迭代效果，是不是超过了他们对 WebRTC 的优化效果？我们针对特定场景优化 WebRTC 时，怎么紧跟 WebRTC 开源社区通用的优化？
作者：阿里云智能技术专家 熊金水
理念简言之，把 WebRTC 作为 Framework 使用，而不是 Library，即：WebRTC 仓库轻量化，核心模块插件化。
详细的，WebRTC 作为 Framework 串联核心模块；核心模块既可以以插件形式使用我们的实现，也可以 Fallback 到 WebRTC 的默认实现。目的是减少 WebRTC 冲突的可能性，提高升级 WebRTC 的敏捷性。
目标：一年升级一次 WebRTC，一次花费一个人月。
架构 模块拆解WebRTC 的核心模块，包括： 音频
ADM 采集、APM、ACM 编码；
NetEQ 与解码、AM、ADM 渲染；
视频采集、编码；
JB、解码、渲染；
通用RTP 打包与解包、FEC 生成与恢复、CC 与 Pacer、ICE、SDP 信令等。
WebRTC 在长期的演进中，API 已经具备了作为 Framework 的大部分能力。红色的核心模块，已经基本可以插件化，如下面的 API：
light-rtc 作为 WebRTC 仓库，我们需要保留两个 Remote，一个是 Alibaba，一个是 Google。升级 WebRTC 时，我们从 Google 上 Pull 最新代码， 解决冲突，然后 Push 到 Alibaba。
对插件化的模块，我们需要放到单独的仓库 lrtc-plugin 里，这样有两个好处：
对 light-rtc 仓库改动少，减少与 Google 冲突的可能性；
更重要的，让每个开发同学，在每次改动前，更主动、更有意识的思考，放到哪个仓库更合适，否则容易惯性思维，直接改动 light-rtc。
对 lrtc-plugin 依赖的第三方库，也应该以单独的仓库存在，并保留两个 Remote，比如 Opus，这样，即使修改了 Opus 源码，仍然可以像升级 light-rtc 一样，方便的单独升级 Opus 版本。
模块 Codec音频编解码器、视频编解码器，是我们最常优化的部分之一：
新的编码工（AV1/SCC/ROI 等）优化视频质量和带宽；
分辨率自适应，使不同能力（编码能力、发送带宽等）的发送端，发送不同分辨率的码流；
Simulcast，为不同能力（解码能力、显示能力、接收带宽等）的接收端，提供不同分辨率码流；
SVC，提供时域/空域分层；
新的视频解码实现，规避 Mac 硬解卡死等问题；
新的音频编码器，适配商用接收端；
……
这部分插件化是相对简单的，只需要实现自己的 [Video|Audio][Encoder|Decoder]Factory 即可。以 Simulcast为例，在自己实现的 VideoEncoderFactory 里，先用 WebRTC 原始的 VideoEncoderFactory，创建多个 Encoder 对象，然后封装到一个 Simulcast Encoder 里。
ADM很可惜，ADM(Audio Device Module)没有提供检测设备插拔的功能，需要增加 Callback 接口。
另外，虽然 WebRTC 支持样本数量的监控，但是当前只用于打印日志，如果想在此基础上做更多事情（如：发现采集样本为 0 时，重启采集），则单独做一个 AudioSampleMoniter 的类，比较有利于扩展。
ADM 是一个适配难点，相信是困扰 RTC 同行的共同难题。不同操作系统、不同机型，都可能有不一样的问题。例如：
Mac 3.5mm 耳机插拔时，偶尔崩溃；
Mac 获取的设备 ID 在插拔后发生变化，不能做持久化；
联想 X1 电脑，多次插拔后，整个 Audio 后台服务失效；
某些 Windows 机型采集不到声音；
某些手机采音权限问题；
……
这些修改大部分属于 Bugfix，参考“Bugfix”章节。
APMAPM(Audio Processing Module)可能是 light-rtc 相对难处理的部分。
APM 与 NetEQ 一起，可能是 WebRTC 核心模块中，开源价值最大的部分。在我对 APM 有限的认知里，对 APM 常见的优化可能有：
混音后的远端信号，做滤波/均衡处理。这是业界不少音频算法的必要条件；
利用 Android 手机特性，优化 AECM，尤其是 Double Talk 时的效果；
啸叫检测与抑制；
利用机型特性，优化 AGC，提高语音音量;
……