第 12 部分导论 · 一套核心，服务所有平台
前十一部分讲的 C++ 引擎，怎么落到浏览器、Android、iOS、桌面？这一章讲清 WebRTC 的跨平台策略：api/ 目录是所有平台共享的原生基座，各平台在其上加一层语言绑定和平台相关的采集/渲染，核心引擎一份代码到处复用。
第 12 部分导论 · 一套核心，服务所有平台
前十一部分讲的是一套 C++ 引擎。但用户用的是 Chrome、是 Android App、是 iPhone、是桌面程序。这套 C++ 核心怎么落到这些千差万别的平台？这是最后一部分的主题——也是把 WebRTC 从“一个库”变成“无处不在的能力”的关键一步。
api/ 是所有平台的共同基座
WebRTC 官方文档（g3doc/index.md）开宗明义：
WebRTC 库的公共 API 就是
api/目录及其子目录，用户不应依赖其他文件。
WebRTC 的跨平台策略是“一个原生 C++ 核心 + 每平台一层薄绑定”：api/ 目录（PeerConnectionFactoryInterface、PeerConnectionInterface 等）是所有平台共享的原生基座**，前十一部分讲的引擎全在它之下；各平台只需在其上加一层语言绑定（把 C++ 接口翻译成 Java / Objective-C / JS）和平台相关的采集 / 渲染。** 于是绝大部分代码（协商、ICE、加密、RTP、拥塞控制、音视频、数据通道、地基）一份、跨平台复用，平台差异被压缩到很薄的两层：
- 语言绑定层 —— Android 的 JNI（Java ↔ C++）、iOS/macOS 的 Objective-C 封装、浏览器里 Chromium 的 Blink 绑定（JS ↔ C++）。它们都对着同一个
api/。 - 平台采集 / 渲染层 —— 摄像头采集、屏幕采集、音频设备、视频渲染——这些必然依赖具体 OS，是平台相关的“输入输出端”。
核心引擎不关心自己跑在哪，它只处理“进来的媒体帧”和“出去的网络包”；采集从哪来、画面渲染到哪去、API 被什么语言调用，交给平台层。这个“窄腰”设计（一个核心、多个绑定）是 WebRTC 能同时占领浏览器和移动端的根本原因。
分层图景
把整个 WebRTC 按“平台无关 / 平台相关”分层，是这样：
上面薄薄两层随平台变，下面厚厚的核心一份代码。你读懂了核心，就读懂了 WebRTC 的 95%；平台层只是“把核心接到具体 OS 上”的适配。
这一部分怎么安排
- Android 的 JNI 桥 —— Java 怎么调到 C++ 核心。
- iOS/macOS 的 Objective-C 封装 —— Apple 平台的绑定。
- 桌面采集 —— 屏幕 / 窗口捕获（
DesktopCapturer）。 - 摄像头采集 —— 视频输入端（
VideoCaptureModule）。 - 构建 libwebrtc —— 怎么真正把这套庞然大物编译出来（depot_tools/GN/Ninja）。
- 全专栏收尾 —— 回顾 12 部分、WebRTC 全景、继续之路。
小结与下一章
WebRTC 的跨平台策略是“一个原生 C++ 核心 + 每平台一层薄绑定”：api/ 目录是所有平台共享的原生基座（前十一部分的引擎全在其下），各平台只加语言绑定（JNI/ObjC/Blink）和平台采集 / 渲染（摄像头/屏幕/音频设备）两薄层。核心引擎不关心跑在哪，只处理进来的帧和出去的包——这个“窄腰”设计让一份核心服务所有平台。
先看最典型的一层绑定——Android 的 JNI 桥。👉 Android SDK 与 JNI。