3. WebRTC 架构解析：整体架构分层、Native API 与 Web API、核心模块
WebRTC 的架构，说白了就是一套「浏览器里做实时通信」的完整解决方案。我最早接触它的时候，觉得这东西就是个黑盒子——打开摄像头、建立连接、传数据，好像几行 JavaScript 就搞定了。但真正深入进去才发现，它背后是一套非常严谨的分层设计。
今天我们就来拆开这个黑盒子，看看里面到底是怎么组织的。我会从整体架构分层讲起，然后聊聊 Native API 和 Web API 的区别，最后深入到 VoiceEngine、VideoEngine、Session Management 这几个核心模块。
3.1 整体架构分层
WebRTC 的架构，我习惯把它看成三层：Web API 层、Native API 层、核心引擎层。每一层各司其职，上层依赖下层，但下层对上层是透明的。
核心理解：Web API 是给前端工程师用的，Native API 是给客户端工程师用的，核心引擎是给 C++ 大佬们玩的。你不需要全部精通，但至少要清楚每一层负责什么。
先看一张整体架构图，我亲手画的，帮你建立直观印象：
这张图你看懂了吗？从上到下，每一层都在做「抽象」。Web API 把复杂的 C++ 逻辑包装成几个简单的 JavaScript 对象；Native API 则暴露了更多的控制权给客户端开发者；而核心引擎，才是真正干活的。
3.2 Web API 与 Native API
很多初学者会问：Web API 和 Native API 到底有什么区别？我能不能只用 Web API 做所有事？
我的回答是：Web API 够用，但不够灵活。举个例子，你在浏览器里调 getUserMedia() 拿到摄像头流，然后传给 RTCPeerConnection，这确实能跑通。但如果你想自定义视频编码器的参数，或者想直接操作原始 YUV 数据，Web API 就无能为力了。
这时候就需要 Native API 出场。我曾在项目中遇到过一个问题：在 Android 端做屏幕共享时，Web API 的帧率控制不够精细，导致 CPU 占用过高。后来我改用 Native API，直接通过 VideoTrackSource 接口注入自定义帧，才把性能压下来。
下面这张表可以帮你快速对比：
| 对比维度 | Web API | Native API (C++) |
|---|---|---|
| 使用场景 | 浏览器端 Web 应用 | Android/iOS/桌面端原生应用 |
| 语言 | JavaScript | C++ / Java / Objective-C 封装 |
| 控制粒度 | 粗粒度，封装好的接口 | 细粒度，可自定义编解码、传输参数 |
| 典型接口 | getUserMedia(), RTCPeerConnection |
PeerConnectionFactory, VideoTrackSource |
| 调试难度 | 较低，浏览器 DevTools 可查 | 较高，需要 native 日志和断点 |
我的建议：如果你做的是纯 Web 应用，Web API 完全够用。但如果你做的是音视频 SDK 或者需要深度定制的客户端，一定要熟悉 Native API。我见过太多人用 Web API 的思路去写 Native 代码，结果处处碰壁。
3.3 核心模块详解
核心引擎层是 WebRTC 的心脏。它由三个主要模块组成：VoiceEngine、VideoEngine、Session Management。下面我们一个一个来看。
3.3.1 VoiceEngine
VoiceEngine 负责音频的采集、处理、编解码和传输。你可能觉得音频比视频简单，其实恰恰相反——音频对延迟和丢包更敏感，而且人耳对音质的挑剔程度远超眼睛。
VoiceEngine 内部有几个关键组件：
- 音频采集/渲染模块：通过底层驱动获取麦克风数据，或者把解码后的音频送到扬声器。
- 音频编解码器：支持 Opus、G.711、G.722 等。Opus 是默认首选，码率范围 6 kbps 到 510 kbps，非常灵活。
- NetEQ（Network Equalizer）：这是 WebRTC 音频的杀手锏。它负责抖动缓冲、丢包隐藏、自适应播放。说白了，就是网络不好的时候，它能让声音听起来依然流畅。
- 回声消除（AEC）：全双工通话必备。我记得第一次调试 AEC 时，发现回声一直消不掉，后来才发现是扬声器和麦克风的物理距离太近，导致算法收敛困难。
- 降噪（NS）：抑制背景噪声，比如风扇声、键盘声。
避坑指南：我曾经在项目中遇到过一个诡异的问题——通话时对方听到我的声音有「金属感」。排查了两天才发现，是 AEC 和 NS 的配置冲突了。如果你同时开启 AEC 和 NS，一定要确认它们的处理顺序和参数是否匹配。否则，降噪会把回声消除后的残留信号也当成噪声处理，导致音质劣化。
3.3.2 VideoEngine
VideoEngine 负责视频的采集、编码、解码和渲染。它的复杂度比音频高一个数量级，因为视频数据量大，而且对实时性要求极高。
VideoEngine 的核心组件包括：
- 视频采集模块：从摄像头或屏幕抓取原始帧。支持 YUV、NV12 等格式。
- 视频编解码器：VP8、VP9、H.264、AV1。VP8 是 WebRTC 的默认编码器，兼容性最好。H.264 在硬件加速上有优势，但专利问题需要注意。
- JitterBuffer（抖动缓冲）：和音频的 NetEQ 类似，但处理的是视频帧。视频帧比音频帧大得多，所以 JitterBuffer 的策略更复杂——它需要平衡延迟和丢包率。
- 码率控制：根据网络带宽动态调整编码参数。WebRTC 使用 GCC（Google Congestion Control）算法，我后面会专门讲。
这里有一个常见的误解：很多人以为视频编码器是「越新越好」。其实不然。VP9 的压缩率确实比 VP8 高 30%-50%，但它的编码复杂度也高得多。在低端手机上，VP9 的编码延迟可能达到 100ms 以上，这对实时通话来说是致命的。
我的经验：在移动端做视频通话，我建议优先用 VP8 或 H.264。VP9 和 AV1 更适合点播场景，或者高端设备上的视频会议。别为了省带宽而牺牲实时性，得不偿失。
3.3.3 Session Management
Session Management 是 WebRTC 的「外交官」。它不直接处理音视频数据，而是负责建立、维护和关闭连接。没有它，VoiceEngine 和 VideoEngine 就是两个孤岛。
Session Management 的核心职责：
| 组件 | 职责 | 备注 |
|---|---|---|
| SDP（Session Description Protocol） | 描述媒体能力：编解码器、分辨率、IP 端口等 | Offer/Answer 模型，通过信令通道交换 |
| ICE（Interactive Connectivity Establishment） | 穿透 NAT 和防火墙，找到可达的传输路径 | STUN 打洞 + TURN 中继 |
| DTLS（Datagram Transport Layer Security） | 加密传输通道，保证数据安全 | 基于 UDP 的 TLS，用于 SRTP 密钥协商 |
| SRTP（Secure Real-time Transport Protocol） | 加密音视频数据包 | 使用 DTLS 协商的密钥 |
你想想看，为什么需要这么多组件？因为实时通信的难点不在于「传数据」，而在于「在复杂的网络环境下安全、可靠地传数据」。ICE 负责找路，DTLS 负责上锁，SRTP 负责把货物锁好，SDP 负责告诉对方「我带了什么货」。缺一个都不行。
我记得有一次调试一个跨国的视频通话，发现连接总是建立失败。抓包一看，ICE 候选地址全是错误的。后来发现是 STUN 服务器配置错了，导致客户端拿到的公网地址不对。嗯，这种问题排查起来真的很头疼。
3.4 模块之间的协作
这三个模块不是各自为战的。它们通过一个核心的 PeerConnection 对象来协调工作。PeerConnection 就像是一个总指挥，它告诉 VoiceEngine：「现在开始采集音频」，告诉 VideoEngine：「开始编码视频」，同时通过 Session Management 把 SDP 和 ICE 候选发给远端。
下面这张流程图展示了它们之间的协作关系：
你看，用户应用只需要跟 PeerConnection 打交道。PeerConnection 内部会协调三个引擎的工作。音频和视频数据分别走 VoiceEngine 和 VideoEngine，而 Session Management 负责把 SDP 和 ICE 信息通过信令通道发给远端。等连接建立后，音视频数据就通过 SRTP 加密传输了。
这里有一个细节：音频和视频是分开传输的。它们使用不同的 SSRC（同步源标识符），在同一个 UDP 端口上通过 RTP 协议复用。这样做的好处是，音频和视频的丢包、延迟可以独立处理。比如网络不好时，你可以选择优先保证音频的流畅性，适当降低视频质量。
一个小技巧：在调试 WebRTC 问题时，我经常用 chrome://webrtc-internals 来查看内部状态。它能显示 ICE 连接状态、RTT、丢包率、码率等关键指标。如果你做的是 Native 开发，可以开启 WebRTC 的内部日志，通过 RTC_LOG 输出调试信息。