WebRTC线程模型进阶：Network、Worker、Signaling线程如何协作

WebRTC 在 C++ Native 层强制使用三线程模型：Network负责所有 socket I/O 与 ICE，Worker跑编解码、设备采样、音频 3A、Signaling承接 PeerConnection 公共 API 与 Observer 回调。理解三者职责与"跨线程任务投递"是写好 SDK、避免死锁和回调错乱的前提。

1. 三个线程分别负责什么

WebRTC Native 的三线程模型不是为了“看起来高级”，而是为了把三类完全不同的工作隔离开：网络 I/O 要及时响应，媒体处理吃 CPU，PeerConnection API 和 SDP 协商需要稳定的串行上下文。如果这些工作都塞进一个线程，视频编码稍微卡一下，ICE 心跳就可能收不到；业务回调里做一次数据库写入，Signaling 状态就可能停住；Network 线程上做个复杂 JSON 解析，STUN Binding 响应就可能晚到。

三线程职责可以这样划分：

• Network 线程：socket、ICE、STUN/TURN、候选对检查、网络包收发。
• Worker 线程：音视频采集、编码、解码、音频处理、媒体引擎重活。
• Signaling 线程：PeerConnection API、Offer/Answer、Transceiver、Sender/Receiver、Observer 回调。