WebRTC TaskQueue机制详解：异步任务调度背后的设计

WebRTC 在rtc::Thread之上又抽象了一层TaskQueue：一个保证“任务按 FIFO 顺序串行执行”的轻量级执行单元。它由TaskQueueFactory统一创建，被编码器、音频 3A、视频渲染、JitterBuffer、统计聚合、拥塞控制等模块广泛使用。TaskQueue的出现让“模块级串行化”和“线程物理隔离”解耦，是阅读 WebRTC 源码绕不开的关键设计，也是写出稳定实时音视频系统的基础工具。1. 设计动机、内部结构与调度模型WebRTC 在主干上有三大线程：Network、Worker、Signaling。但真实的媒体系统里会有大量“只希望串行执行、但不想再造新线程”的子模块：编码器状态更新、抖动缓冲决策、统计聚合、定时重试、回调去抖、带宽估计、转发控制。直接全塞进 Worker 会让一个慢任务拖累所有模块；每个模块都单独开线程又会让上下文切换成本爆炸，且需要大量锁来保护状态。TaskQueue就是为这类问题设计的：它提供模块级串行执行语义，把“串行化”从“线程数量”里解耦出来。可以把Thread看成一条高速公路，把TaskQueue看成高速公路上的专用车道。专用车道里的车按顺序过闸，互不插队；但它不一定独占一条高速，也可能与其他车道共享底层执行资源。这种设计让 WebRTC 可以在不无限增线程的前提下，给模块提供清晰的顺序保证。