# 第 10 部分导论 · 引擎底下的地基 rtc_base

> 前九部分讲的是 WebRTC 的引擎，但引擎底下有一层到处都在用、却很少被单独讲的地基——rtc_base。这一章讲清它是什么、为什么 WebRTC 要自造一套基础库，以及第 10 部分要拆开看的那些「零件」。

- 作者：David（道雾轩）
- 专栏：音视频与 WebRTC 详解（https://daiw.org/manual/webrtc.md）
- 最后更新：2026-07-14
- 原文：https://daiw.org/manual/webrtc/rtc-base-overview
- 转载与引用：请注明出处并附原文链接（https://daiw.org/about/copyright）

# 第 10 部分导论 · 引擎底下的地基 rtc_base

[前九部分](https://daiw.org/manual/webrtc/call-recap)讲完了 WebRTC 的**核心引擎**。但你一定注意到：一路读下来，总有些“零件”反复出现——[`scoped_refptr`](https://daiw.org/manual/webrtc/scoped-refptr)、[`Thread`](https://daiw.org/manual/webrtc/thread-and-taskqueue)、[`Timestamp`](https://daiw.org/manual/webrtc/units)、[`RTC_GUARDED_BY`](https://daiw.org/manual/webrtc/synchronization)……它们不属于任何一个子系统，却被**所有子系统**依赖。这层地基，就是 **`rtc_base`**（源码里的 `rtc_base/` 目录）。第 10 部分，我们把它拆开看。

## WebRTC 为什么自造一套基础库

一个自然的疑问：C++ 有标准库，为什么 WebRTC 还要自己造 `Thread`、`Buffer`、`Mutex`？

<Callout type="info">
  **`rtc_base` 是 WebRTC 的“标准库”——一套**跨平台、贴合实时通信需求**的基础设施。它存在的原因是历史与现实的叠加：**

  - **历史比 std 早** —— WebRTC 起于 2011 年，那时 C++11 刚出、`std::thread`/`std::mutex` 还不成熟，跨平台支持参差。WebRTC 需要在 Windows / Linux / macOS / Android / iOS 上**行为一致**的线程、锁、socket，只能自己造。
  - **要跑在千奇百怪的平台上** —— WebRTC 要嵌进浏览器、手机 App、嵌入式设备。`rtc_base` 把[平台差异](https://daiw.org/manual/webrtc/reading-the-source)（[Win 的 `CRITICAL_SECTION`、POSIX 的 `pthread_mutex`](https://daiw.org/manual/webrtc/synchronization)）封在底下，上层代码写一套。
  - **实时通信的特殊需求** —— 通用库没有的东西：[类型安全的时间 / 码率单位](https://daiw.org/manual/webrtc/units)、[零拷贝缓冲](https://daiw.org/manual/webrtc/buffers)、[滑动窗口测速率](https://daiw.org/manual/webrtc/rate-statistics)、[编译期线程安全检查](https://daiw.org/manual/webrtc/synchronization)——这些是[音视频引擎](https://daiw.org/manual/webrtc/call-object)天天要用的，`rtc_base` 为它们量身打造。

  所以 `rtc_base` 不是“重复造轮子”，而是“造 std 没有、或当年 std 造不好的轮子”。理解它，你才真正看懂[上面九部分](https://daiw.org/manual/webrtc/call-recap)那些代码为什么长那样。
</Callout>

## 地基决定上层的形状

一个重要观念：**地基的设计，反过来塑造了整个引擎的样子**。

比如 [`Thread` 其实是一个任务队列](https://daiw.org/manual/webrtc/thread-and-taskqueue)（[`Thread : public TaskQueueBase`](https://daiw.org/manual/webrtc/thread-and-taskqueue)）——正因如此，WebRTC 的[三线程模型](https://daiw.org/manual/webrtc/threading-model)才能用“[往线程 `PostTask`](https://daiw.org/manual/webrtc/thread-and-taskqueue)”这种统一方式跨线程协作。又如 [`scoped_refptr` + 引用计数](https://daiw.org/manual/webrtc/scoped-refptr)是 WebRTC 对象生命周期的基石——正因如此，[`PeerConnection` 等对象](https://daiw.org/manual/webrtc/peer-connection-object)才用 `scoped_refptr` 传递、[异步回调时不怕对象被提前销毁](https://daiw.org/manual/webrtc/proxy-pattern)。**上层的架构选择，往往是地基能力的直接后果。** 所以第 10 部分不是“附录”，而是补上“为什么上层能那样写”的答案。

## 这一部分拆开看的零件

第 10 部分挑 `rtc_base` 里**最核心、最常出现**的几样，逐一拆解：

```mermaid
flowchart TD
    RB["rtc_base 地基"] --> T["线程 / 任务队列<br/>Thread, TaskQueue"]
    RB --> R["引用计数<br/>scoped_refptr, RefCountedObject"]
    RB --> U["类型安全单位<br/>Timestamp, TimeDelta, DataRate"]
    RB --> B["零拷贝缓冲<br/>Buffer, CopyOnWriteBuffer"]
    RB --> S["同步与线程注解<br/>Mutex, SequenceChecker, RTC_GUARDED_BY"]
    RB --> RS["速率统计<br/>RateStatistics"]
    T -.被用于.-> ALL["整个引擎"]
    R -.-> ALL
    U -.-> ALL
    B -.-> ALL
    S -.-> ALL
    RS -.-> ALL
```

| 章 | 零件 | 上面哪里用到 |
| --- | --- | --- |
| [线程与任务队列](https://daiw.org/manual/webrtc/thread-and-taskqueue) | `Thread`/`TaskQueueBase` | [三线程模型](https://daiw.org/manual/webrtc/threading-model)、[代理模式](https://daiw.org/manual/webrtc/proxy-pattern) |
| [引用计数](https://daiw.org/manual/webrtc/scoped-refptr) | `scoped_refptr` | [几乎所有对象](https://daiw.org/manual/webrtc/peer-connection-object) |
| [类型安全单位](https://daiw.org/manual/webrtc/units) | `Timestamp`/`DataRate` | [拥塞控制](https://daiw.org/manual/webrtc/congestion-control-overview)、[时间戳](https://daiw.org/manual/webrtc/video-timing) |
| [零拷贝缓冲](https://daiw.org/manual/webrtc/buffers) | `CopyOnWriteBuffer` | [RTP 包](https://daiw.org/manual/webrtc/rtp-packet)在系统里流动 |
| [同步与线程注解](https://daiw.org/manual/webrtc/synchronization) | `Mutex`/`RTC_GUARDED_BY` | [满眼的线程断言](https://daiw.org/manual/webrtc/threading-model) |
| [速率统计](https://daiw.org/manual/webrtc/rate-statistics) | `RateStatistics` | [pacer](https://daiw.org/manual/webrtc/pacing)、[BWE](https://daiw.org/manual/webrtc/delay-based-bwe)、[stats](https://daiw.org/manual/webrtc/stats-collector) |

## 小结与下一章

**`rtc_base`** 是 WebRTC 的“[标准库](https://daiw.org/manual/webrtc/reading-the-source)”——一套**跨平台、贴合实时通信**的地基，因[历史早于成熟的 std](https://daiw.org/manual/webrtc/reading-the-source)、[要跑在千奇百怪的平台](https://daiw.org/manual/webrtc/what-is-webrtc)、且有[通用库没有的实时需求](https://daiw.org/manual/webrtc/units)而存在。它被[所有子系统](https://daiw.org/manual/webrtc/call-recap)依赖，且**地基的设计反过来塑造了上层架构**（[`Thread` 是任务队列](https://daiw.org/manual/webrtc/thread-and-taskqueue) → [三线程协作方式](https://daiw.org/manual/webrtc/threading-model)；[引用计数](https://daiw.org/manual/webrtc/scoped-refptr) → [对象生命周期管理](https://daiw.org/manual/webrtc/proxy-pattern)）。本部分拆解它最核心的零件。

先从最“底”的一样开始——**线程与任务队列**，它撑起了[整个 WebRTC 的并发模型](https://daiw.org/manual/webrtc/threading-model)。👉 [线程与任务队列](https://daiw.org/manual/webrtc/thread-and-taskqueue)。

## 参考资料

- [1] libwebrtc 源码.`rtc_base/` 目录总览、`api/` 下的公共抽象。
- [2] 关联[第 0 部分线程模型](https://daiw.org/manual/webrtc/threading-model)、[代理模式](https://daiw.org/manual/webrtc/proxy-pattern)、[读源码指南](https://daiw.org/manual/webrtc/reading-the-source)。
- [3] WebRTC 官方 `g3doc/`（架构与基础库说明）。