第 10 部分回顾 · 地基如何塑造引擎
第 10 部分拆解了 rtc_base 的六样核心零件——线程/引用计数/单位/缓冲/同步/速率统计。这一章串起它们，点明一个贯穿始终的观念：地基的设计不是「底层细节」，而是直接决定了上层引擎能长成什么样。
第 10 部分回顾 · 地基如何塑造引擎
第 10 部分把 rtc_base 这层地基拆开，看了六样最核心的零件。这一章串起来，并点明一个贯穿本部分的观念——地基不是“底层细节”，而是塑造了整个引擎的形状。
六样零件回顾
| 零件 | 是什么 | 一句话本质 |
|---|---|---|
| 线程与任务队列 | Thread : public TaskQueueBase | 线程即任务队列，跨线程靠 PostTask |
| 引用计数 | scoped_refptr/RefCountedObject | 对象自管生死，异步安全的生命线 |
| 类型安全单位 | Timestamp/TimeDelta/DataRate | 让类型系统记住单位，单位错误编译期挡下 |
| 零拷贝缓冲 | CopyOnWriteBuffer | 引用计数 + 写时复制，只读传递零拷贝 |
| 同步与线程注解 | Mutex/RTC_GUARDED_BY | 用线程归属代替锁，编译期查竞争 |
| 速率统计 | RateStatistics | 滑动窗口测瞬时速率 |
一条暗线：地基决定上层
把这六样连起来看，有一条清晰的因果链——每个上层架构决策，都能追溯到一个地基能力：
“地基决定上层”不是一句空话，而是可以逐条对应的：
- 因为
Thread是任务队列 → 才有三线程模型用PostTask协作、代理模式自动派发线程。 - 因为有
scoped_refptr引用计数 → API 对象才能跨线程安全传递、异步回调不怕对象被提前销毁。 - 因为有类型安全单位 → 拥塞控制那些密集的时间 / 码率计算才不会被单位 bug 淹没。
- 因为有
CopyOnWriteBuffer→ 一个包能流经十几个环节而不必反复深拷贝。 - 因为有线程注解 → 那套“数据归属线程、免锁”的并发纪律才能被编译器强制、不靠自觉。
上层的优雅，建立在地基的能力之上。 反过来，如果你要读懂或改动 WebRTC 的任何子系统，先问一句“它用了哪些 rtc_base 零件”——RTC_GUARDED_BY 告诉你线程模型、scoped_refptr 告诉你生命周期、Timestamp 告诉你在算时间。地基是理解一切的钥匙。
我们走到了哪
至此，本教程覆盖了 WebRTC 的核心引擎（第 0~9 部分）和支撑引擎的地基（第 10 部分）：
剩下的部分，转向工程实践：一套引擎跑起来了，怎么知道它跑得好不好？出问题怎么排查？这是观测与调试（第 11 部分）。再往后，这套 C++ 引擎怎么落到 Android / iOS / 桌面？这是平台集成（第 12 部分）。地基和引擎都立起来了，接下来是让它在真实产品里可观测、可调试、可移植的最后一段路。
小结与下一部分
第 10 部分拆解了 rtc_base 六样核心零件（线程/引用计数/单位/缓冲/同步/速率统计），并揭示一条暗线：地基的每个能力，都直接塑造了上层引擎的一个架构决策——线程即队列 → 三线程协作、引用计数 → 异步对象安全、线程注解 → 免锁纪律。读懂地基，就拿到了理解任何子系统的钥匙。
引擎与地基俱全，下一部分看怎么观测和调试一套跑起来的 WebRTC。👉 第 11 部分 · 观测与调试。