企业官网建设流程全解析

最近在折腾实时音视频相关的东西，免不了要和 WebRTC 这套框架打交道。项目初期我翻了不少文档，真正上手后发现官方的 API 文档写得很规整，但一旦遇到需要改源码、调性能、查线上问题，文档根本不够用，最后还是得一头扎进源码里。这篇东西是我自己断断续续啃源码过程中的笔记和体会，不按章节顺序堆 API，而是按“你想在源码里找到什么”来组织，聊聊 WebRTC 源码的目录设计、线程模型、音视频数据流转链路，以及我实际调试中踩过的坑。

先给不熟悉的读者一句话介绍：WebRTC 其实不是单一功能库，而是一整套实时通信基础设施，涵盖音视频采集、编码、传输、接收、渲染、网络抗丢包、回声消除等全链路，目前项目源码体量大概在两三百万行上下。有人觉得它是个“黑盒浏览器插件”，有人把它当成一个嵌入式实时音视频 SDK，还有人把它当作网络传输实验平台，这几种视角在源码里都能找到对应模块。如果你是想做实时音视频产品的开发者、想搞懂音视频引擎内部机制的初学者、或者在排查线上音画不同步、卡顿、回声问题的工程师，看这篇应该能少走不少弯路。

1. 先看源码地图：目录结构的核心意图

1.1 顶层目录的划分逻辑

WebRTC 源码仓库的顶层目录看起来挺多，但抓主线的话，真正核心的就几块：api/、pc/、call/、media/、modules/、rtc_base/、common_audio/、common_video/和system_wrappers/。

如果你从使用者的角度切入，入口一定是api/，这里定义了大部分对外暴露的接口，比如PeerConnectionInterface、AudioSourceInterface、VideoTrackInterface。你平时写业务代码调用的那层 C++ 接口基本都是在这里声明。pc/目录则是对这些接口的完整实现，像PeerConnection、PeerConnectionFactory、SdpHandler这类核心类都在这里，信令协商、媒体协商状态机也主要落在这个目录。

往下走一层，call/和media/是媒体会话的管理中枢。call/里主要是Call、RtpTransportControllerSend这类会话级对象，负责把网络传输和媒体通道串起来。media/则偏“引擎”概念，比如AudioReceiveStream、VideoSendStream，这些 Stream 对象会上连应用层接口，下接编解码器和网络收发模块。

丢到modules/这个目录里的，就是真正的“实现细节大户”了。音频处理、视频编码相关的东西，其实都在modules/audio_processing、modules/video_coding下。另外 RTP/RTCP 协议的实现在modules/rtp_rtcp，拥塞控制在modules/congestion_controller，网络端口和 P2P 连接管理在modules/p2p。这些模块相对独立，有点像积木块，能被上层任意组合。

rtc_base/可以理解成项目自己的基础库，线程、消息队列、网络地址封装、随机数、时间戳、字符串工具这类通用组件全都放在这里。common_audio/和common_video/则是面向音频信号处理和视频帧结构的公共代码。system_wrappers/是跨平台封装层，同一套代码编译到不同操作系统时，差异部分基本靠它吸收掉。

1.2 一个容易混淆的分层：API 层和实现层

有个细节很容易让新手困惑：api/目录下不仅是接口定义，还包含了大量可复用的数据结构和枚举定义，比如RtpParameters、SdpParseError、MediaStreamTrackInterface。很多人在源码里想找“PeerConnection 是怎么创建音视频轨道的”，结果在api/里找到一堆声明，在pc/里才看到真正的逻辑实现。

我个人的经验是，读 WebRTC 源码时可以把这两个目录当成一对来读：先在api/里确认接口长什么样，再去pc/里找对应的实现类。举个例子，PeerConnectionInterface::CreateOffer的声明在api/peer_connection_interface.h，实现则在pc/peer_connection.cc的CreateOffer方法里。这个方法的内部流程会调用SdpOfferAnswerHandler来生成 SDP，而这个 handler 是后面几个版本才从 PeerConnection 里拆出去的，目的就是把信令逻辑从 PeerConnection 这个巨型类里剥离开来。如果你拿到的是新版本源码，看到PeerConnection里很多方法都被转发到了SdpOfferAnswerHandler，不要觉得奇怪，这是项目长期演进的结果。

1.3 目录结构里藏着的架构原则

WebRTC 源码看多了，你会发现一个核心原则：模块间尽量不要互相依赖，依赖只朝下一个方向走。怎么理解？比如pc/可以使用call/、modules/的接口，但modules/不应该反过来依赖pc/。这种单向依赖保证了每个模块可以被单独测试和复用。

另一个有意思的点是modules/内部又分了一堆子模块，每个子模块都有自己独立的接口和实现，比如modules/rtp_rtcp里实现的RtpPacket、RtpPacketToSend、RtpPacketReceived这些类，外界通常只通过RtpPacketReceived这类“已接收包”的接口访问。想深入协议细节的话，直接在modules/rtp_rtcp/source下能翻到所有包处理代码，连无线网场景下的 RTP 扩展头处理都有。

碰到这种巨型代码库，我建议你先别急着读每一行，而是先画一张自己的模块依赖图：入口 API 在最上层，往下是信令和会话控制，再往下是媒体传输和编解码，最底层是系统封装和基础工具。带着这张图去读源码，很多代码出现的位置就有了解释。

2. 绕不开的线程模型：理解 WebRTC 源码的钥匙

2.1 线程划分与消息驱动的运转方式

WebRTC 源码里最劝退新手的地方，大概率是线程模型。它的代码不是简单地在几个线程里跑几个函数，而是建立了一套基于消息队列的异步驱动机制。

在高层看，WebRTC 最关键的三个线程是：信令线程（signaling thread）、工作线程（worker thread）和网络线程（network thread）。信令线程负责创建修改 PeerConnection 状态、处理 Offer/Answer、操作 SDP；工作线程负责编码器、解码器、音频处理模块的调度；网络线程负责 RTP/RTCP 包的收发、ICE 连接状态变化检测。

这三条线程的分工不是随便分的。信令操作天然是低频的，丢到独立线程不会干扰媒体流；编码解码是很重的计算任务，需要专门的工作线程做 CPU 密集操作；网络收发要足够实时，稍有延迟就影响音画质量，所以单独占一条线程处理 socket 事件是最稳妥的。除了这三条，每条线程内部还往往挂着多个任务队列，任务队列按优先级调度，这也解释了为什么源码里到处能看到PostTask、Invoke、AsyncInvoke之类的调用。

2.2 从源码里找线程迁移的痕迹

读代码时，我经常要确认“这个方法到底在哪条线程上执行”。方法一：看类注释。很多核心类在头文件顶部就写了类似 “All methods must be called on the network thread” 这样的约束说明。方法二：看类内部是否持有Thread*成员，并在构造函数的初始化列表里记录线程指针，后续函数开头会调用RTC_DCHECK_RUN_ON(network_thread_)来做线程校验。

这个方法格式是你在源码里会反复见到的：

• RTC_DCHECK_RUN_ON(worker_thread_)：断言当前运行在指定线程上，debug 模式下不满足直接崩溃。
• RTC_DCHECK(!network_thread_->IsCurrent())：断言当前不能是某条线程。

这种断言在正式发布版本里会被编译掉，不产生额外开销，但 debug 版本却非常有用，很多线程相关的 bug 一跑单元测试就暴露了。我自己排查过一个一会正常一会崩溃的问题，最后靠RTC_DCHECK_RUN_ON定位到是某个回调被发错线程触发，根源是没有遵循对象生命周期所在线程的约束。

2.3 对象销毁的线程陷阱

再看深一层，WebRTC 的对象销毁也有一套专属套路。它经常用rtc::RefCountedObject和scoped_refptr管理与线程相关的资源，一个对象的最后一个引用在哪条线程上释放，就决定了析构函数在哪条线程上执行。这个情况今天我特别强调，因为很多线上崩溃其实不是逻辑写错，而是析构发生在错误线程上。

举个例子，你在应用层持有一个VideoTrackInterface，但内部实际的VideoTrack可能间接引用和编码器、渲染器相关的资源。如果这条 VideoTrack 的最后一个scoped_refptr在非工作线程上被释放，它的析构逻辑却要访问工作线程独占的数据，那就会出现未定义行为。WebRTC 的常规解法是把析构函数里比较重的逻辑通过rtc::Thread::Invoke再投递回资源所在线程执行。你要是自己扩展了一个类，建议同样遵循这个模式：不要在随便一条线程里直接释放对象，优先考虑延迟释放。

2.4 为什么新版代码里 TaskQueue 越来越多

老版本 WebRTC 里，线程操作往往走rtc::Thread::PostTask。新版本代码中，你更常看到webrtc::TaskQueueBase::GetCurrent()->PostTask这样的写法。这套TaskQueue抽像在时间戳精确度、任务取消、资源复用等方面做了更好的封装。本身就是rtc::Thread下层进一步抽象出来的产物。

碰到这种演进，最稳妥的读源码方式是“跟着注释走”。TaskQueue相关的头文件里通常有很详细的说明，例如“任务执行顺序不保证严格 FIFO，但同一队列里的任务不会并发执行”。理解这一点能解释很多看似奇怪的 bug：比如你在回调里往队列投递了一个任务，然后立刻触发另一个线程的同步调用，如果同步调用内部也依赖同一个队列，就可能和刚投递的任务竞争，出现逻辑乱序。

3. 建立一次呼叫：从 Offer 到媒体流动的源码之旅

3.1 Offer/Answer 协商与状态机

虽然日常开发中我们不常用 C++ 层去处理 SDP，但阅读源码能帮你理解信令协商的本质。在pc/目录下，SdpOfferAnswerHandler维护着一个典型的状态机，状态包括稳定态（stable）、本地已提供（local-offer）、远程已提供（remote-offer）等。每次CreateOffer、SetLocalDescription、SetRemoteDescription都会触发状态迁移。

有个非常容易出问题的细节是“set 完之后 SDP 的匹配”。WebRTC 的 Offer/Answer 模型要求，当你调用SetRemoteDescription接收到远端发来的 SDP，再调用SetLocalDescription本地生成了匹配的 answer，此时媒体协商才算完成。源码里SetRemoteDescription会解析远端 SDP 并生成一个内部的SessionDescription对象，接着判断里面有几个MediaDescription、每个描述里有哪些编解码器、传输地址、指纹等。如果不匹配，会直接返回错误kInvalidRemoteDescription或在后续 ICE 阶段失败。

这一类错误，线上排查时最常遇到的情况是“两边 SDP 的 ice-ufrag 或 fingerprint 不一致”，其实只要看源码就会意识到，指纹是 DTLS 证书计算出来的，只要任何一边换了证书或者协商顺序错了，指纹就对不上。

3.2 ICE 和传输层初始化

SDP 协商完成后，接下来就是 ICE。在源码中这个动作会在PeerConnection::SetLocalDescription成功之后触发，内部会调用JsepTransportController来创建传输通道。

JsepTransportController内部的代码量很大，但核心职责可以总结为：把 SDP 里描述的transport和实际网络组件做绑定。它会为每个媒体通道创建RtpTransport，并初始化 ICE 代理、DTLS 传输、RTP 包发送器。这里能看到P2PTransportChannel和DtlsTransport绑定的逻辑，这两个类一个管端口连通性，一个管加密通道握手。

我排查询过不少“连通了却传不了数据”的问题，翻代码后发现 ICE 代理返回的 candidate 优先级和地址类型会影响实际选择哪条路径。WebRTC 会根据local_preference、network_preference等参数排序候选。如果在自定义网络环境里发现走的路径不是预期路径，可以去modules/p2p/port_allocator看一下候选端口生成逻辑，常常是AllocationSequence那部分没覆盖到你的网卡类型。

3.3 媒体包上行的第一跳

当 ICE/DTLS 全部建立完成后，媒体包就开始从媒体线程往网络线程跑了。以视频发送为例，视频帧经过编码器生成编码帧后，进入VideoSendStream，再交给RtpVideoSender。RtpVideoSender在源码里其实是一个组合体，它内部持有多个RtpPacketSender策略类，比如PacedSender（平滑发送）、RtcpSender（控制信息发送）。

关键点在于：编码后的帧并不是立刻变成 UDP 包发出去，而是先通过一个pacing（平滑发送）模块，由它来决定每个包什么时候真正到达网络线程。这样设计是为了避免一个瞬时大帧把网络塞爆，导致延迟抖动。你看modules/pacing/paced_sender.cc里的代码，会发现它内部维护了一个发送队列，并按时间窗批量放出包。

理解了这一幕，就能解释实际使用中的一个常见现象：为什么网络丢包不严重时，画面依然可能发生轻微评注意，在背板带宽不足或 CPU 吃紧时，pacer 的排队时间会增加，视频帧的到达时间间隔就会很不均匀，表现就是“每秒流畅，但偶尔小卡一下”。

3.4 远端收包：从网络线程到解码线程

对端收包也是多线程协作。网络线程从 socket 读到 UDP 数据后，先是经过RtpTransport做 SRTP 解密，然后包被投递到PacketDemuxer，根据 SSRC 找到属于哪个RtpStreamReceiver，再转发给对应的AudioReceiveStream或VideoReceiveStream。

在VideoReceiveStream里，包会先进入一个重排序缓冲区。因为 UDP 不保证顺序，视频帧可能乱序到达，重排序缓冲会根据 RTP 序号把包排好，等一个完整帧的所有分片都到齐后，才交给解码器解码。

这里有个视觉化的源码阅读入口：modules/video_coding/packet_buffer.cc里的PacketBuffer::InsertPacket方法，它逐包处理并维护started、completed等状态。如果你想调试“某帧一直没到齐”的问题，打断点看这个函数的返回状态是最直接的。

4. 音视频处理链路里的核心源码

4.1 音频管线：回声消除和自动增益怎么跑起来的

modules/audio_processing/是音频处理模块的大本营，平时我们嘴上说的 AEC（回声消除）、ANS（降噪）、AGC（自动增益），实现代码都在这里。

音频管线的数据流大致是：

• 采集线程从麦克风拿到 PCM 数据。
• 数据先经过high pass filter，把直流分量和超低频干掉。
• 再进入 AEC，用参考信号（远端播放的音频）去抵消回声路径。
• 然后是降噪模块，识别并压掉稳态噪声。
• 最后是增益控制，把语音音量调到合适范围。
• 处理完的数据进入发送队列，交给编码器编码成 Opus。

读这块代码时，我最常犯的错是把参考信号和输入信号搞混。AEC 的输入有两个：近端麦克风信号和远端参考信号。如果你在自己做回声消除测试时把两个信号接反了，怎么调参数都没用。源码里的AudioProcessingImpl::ProcessStream会要求传入包含主数据和参考数据的AudioFrame，两者的sample_rate_hz、num_channels必须匹配，否则直接返回错误码。

4.2 从系统音频设备到编码器：AudioSendStream 的连接

再往上层看，AudioSendStream在media/base/audio_source和modules/audio_coding之间扮演了翻译官的角色。它从音频源拿到AudioTrackInterface传递下来的音频数据，交给AudioProcessing处理，再通过AudioCodingModule编码为 RTP 负载。

这里有一个容易让看到音频代码却不太懂传输的人困惑的点：音频和视频的发送节奏完全不同。音频按 20ms 一个包固定节奏发送；视频则按帧发送，帧间隔不固定。为了处理这个差异，AudioSendStream里会把编码后的音频包直接交给RtpPacketSender发送，而不是像视频那样先经过一个独立的视频 pacing 队列。源码里你看到音频发送路径比视频短不少，这是真实情况，不是偷懒。

4.3 视频编码链路的选路逻辑

视频链路比音频复杂一个维度，因为视频需要根据网络情况在编码器参数、分辨率、帧率上做实时调整。VideoStreamEncoder是这一链路的核心调度者，它持有编码器实例，也接收来自拥塞控制器和 CPU 过载检测器的反馈。

VideoStreamEncoder::OnBitrateUpdated会在码率变化时被调用，然后内部计算出新的目标码率和分辨率，决定是否触发重新配置编码器或缩小帧率。如果网络变差，它可能会把 1080p 降到 720p 甚至更低。你如果只看文档，很难理解为什么网络抖动时画面清晰度会像“阶梯式”下降，因为这里的调整不是连续变化，而是配置切换式的。

这里我特别提醒一个经常被忽略的源码细节：编码器如果设置了scaling_mode，会在 CPU 检测模块判断“每帧编码耗时过大”时自动降分辨率。你视频莫名变模糊，不一定是带宽限制，可能是 CPU 处理不过来触发降级。

4.4 RTP 打包与扩展头

RTP 打包代码在modules/rtp_rtcp/source/rtp_packetizer_*.cc里。视频帧通常是几千到几万字节，但 UDP 包有效负载一般限制在 1200 字节左右，所以必须把一个视频帧切分成多个 RTP 包。对 H264 来说是RtpPacketizerH264，对 VP8 是RtpPacketizerVp8，对 AV1 是RtpPacketizerAv1。

切分的规则不单是“按字节切”，还要考虑编码层对 slice 的边界要求，对 H264 来说 STAP-A 和 FU-A 两种打包模式分别对应“多个 NAL unit 组合在一起”和“单个大 NAL unit 分片传输”。阅读打包代码时你还能看到 RTP 扩展头的写入，比如abs-send-time、transport-wide-cc序号、audio-level等，这些扩展头有些是协商时确定的，有些是高版本 WebRTC 自动启用的，统一在RtpPacketToSend::SetExtension里处理。

5. 排查实战经验：源码级调试的几个高价值工具

5.1 用好日志开关，别靠猜

WebRTC 的日志系统是带等级控制的，很多环境里默认不打印底层传输日志。排查问题时，你可以在启动时把日志级别开到 verbose：

rtc::LogMessage::LogToDebug(rtc::LS_VERBOSE);

或者通过命令行设置：

--log-level=VERBOSE

开完 verbose 之后再跑呼叫，日志里会多出大量RTP、ICE、DTLS相关记录，尤其能看到：

• ICE 候选连接的状态变化。
• 每个 RTP 包的发送时间、序号和延迟。
• 远端反馈报文（RTCP Receiver Report）的摘要。

我自己的经验是，遇到网络问题先看 log，很多问题一眼就能定位是“没收到包”还是“收到但被丢弃”还是“收到但排序失败”。这三个方向的处理思路完全不同，如果你不打开源码日志，很容易陷入瞎调参数的泥潭。

5.2 用 RTC_DCHECK 做线程断言

刚才提过的RTC_DCHECK_RUN_ON是调试线程错乱的利器。在 debug 版本里，我经常会在自己新增的回调函数开头加上这条断言，看看它到底跑在哪条线程。如果某个回调的下层实现改了线程投递逻辑，断言会立刻爆出来。

需要注意的是，RTC_DCHECK是“仅在 debug 构建生效”的检查，release 版本里没有保护。所以如果你的发布版本往日志里加了较多自定义回调，最好在自定义代码中主动承接线程切换的检查，不要假设底层一定会按你预期投递。

5.3 两种最常见的 BUILD 文件错误

WebRTC 项目用 GN 构建，业务代码需要和它的 BUILD.gn 体系对齐。我在扩展自定义模块时，至少踩过两次类似的问题：

• 源文件放了但没在sources里声明，编译报“unknown file type”。
• 头文件放错了目录层级，依赖方 include 时找不到，实际是没把新增目录加到include_dirs。

避免这类问题有个笨办法：编译报错后先看.ninja_log和args.gn，确认当前目标是否真的被构建，再回过去看BUILD.gn里的target依赖关系。很多时候报错是因为目标依赖写错了，底层库根本没用上你新加的源文件。

5.4 用可视化方式辅助定位延迟

源码里的时间戳特别多，初次读的时候容易晕头转向。注意几个关键时间戳：

• capture_time_ms：帧采集时刻。
• encode_start_time_ms/encode_finish_time_ms：编码起止。
• packet_send_time_ms：发包时刻。
• receive_time_ms：收包时刻。
• decode_start_time_ms/decode_finish_time_ms：解码起止。

想分析端到端延迟，建议先用这些时间戳画一条流水线，自己把每个环节的耗时写出来，再去找痛点。源码里好多优化，本质就是把这条流水线上的某个环节从串行变成并行，或者把某个缓冲区的等待时间降到更低。

5.5 实测常用的排查问题速查表

6. 自定义扩展时的源码阅读路线与经验

6.1 想扩展编解码器，该从哪里下手

如果你想把项目里已有的 H264 换成自己团队的编解码器，源码里需要看的关键接口集中在：

• api/video_codecs/video_encoder_factory.h
• api/video_codecs/video_decoder_factory.h
• modules/video_coding/codecs/下已有的各种实现。

WebRTC 并不直接在PeerConnection里写死编码器，而是通过可注入的VideoEncoderFactory创建编码器实例。所以你的自定义编码器只要继承VideoEncoder接口，并实现InitEncode、Encode、RegisterEncodeCompleteCallback这些方法，再传给工厂即可。

一个不熟悉的推导：很多自定义编码器在早期只实现了Encode，没实现丢包关键帧请求（RequestKeyFrame），导致收端遇到丢包后永远等不到关键帧，画面长时间卡住。你扩展时务必确认RequestKeyFrame有实际行为，否则遇到丢包场景直接翻车。

6.2 想改音频处理效果，重点看哪几个类

音频效果最差通常不出在“算法不够好”，而在于参数配置与场景不匹配。如果你只想改默认效果，不用碰算法本身，在AudioProcessing::Config里调参数即可，比如：

• echo_canceller.enabled是否开 AEC。
• noise_suppression.level设置等级。
• high_pass_filter.enabled是否启用高通。

如果需要对某个场景定制降噪强度，可以考虑在AudioProcessingImpl::ProcessStream里面根据AudioFrame的vad_activity状态改变处理路径。这里不改算法核心，只做条件分支，对效果的提升往往比重新训练模型更直接。

6.3 调网络参数：别把锅全甩给带宽

源码里与网络质量最相关的位置是modules/congestion_controller/，尤其是goog_cc下的带宽估计器。它的主要逻辑是根据 RTCP 反馈和延迟梯度来估算可用带宽，再实时更新TargetBitrate。

有人觉得“带宽不够就调大码率”，这个想法在实时音视频里基本不成立。带宽估计器如果判断网络拥塞，会主动降低目标码率以避免排队延迟和丢包。你如果想在弱网场景下更激进一些，通常要修改的是BandwidthEstimation的LossBasedBwe和DelayBasedBwe之间的权衡权重，而不是简单固定一个码率上限。

我提醒一句：在源码上调整拥塞控制参数很容易，但很难在所有场景下都中正准确。公司内部做过几轮弱网调优，最后得到的经验是“先加日志、灰度验证、再改参数”，而不是凭感觉把某个阈值翻倍。

6.4 阅读源码的推荐路径

如果你刚开始看 WebRTC 源码，我给出一个相对顺滑的路径：

• 第一步：花一天时间把api/里peer_connection_interface.h、video_frame.h、audio_frame.h几个核心头文件扫一遍。
• 第二步：跟着一个最简单的呼叫流程，从CreatePeerConnection走到SetRemoteDescription，中途把pc/peer_connection.cc里涉及的类挨个按名字搜索一下。
• 第三步：把注意力转到一条具体的媒体链路，比如视频发送链路。从VideoTrack到VideoBroadcaster到VideoStreamEncoder再到RtpVideoSender，这条线能帮你把所有网络传输和编解码衔接起来。
• 第四步：再深入到某个模块的源码，比如modules/congestion_controller或modules/audio_processing，这时的目的已经不是“看懂全貌”，而是“搞懂一个点”。

我在带新人时经常说一句话：WebRTC 源码像一座大城市，你不需要一次性把所有街道都走遍，但你必须手里有张地图，知道每条主干道通向哪里。地图画好之后，每次穿过几条街，日积月累，你能理解的深度就会远超看十篇教程。

7. 源码阅读以外的几点体会

这篇内容讲了不少模块细节，最后聊点源码之外、但实际工作中很关键的东西。

第一，WebRTC 的版本差异非常大。不同分支、不同年份的代码，目录结构甚至命名习惯都会变。你如果在网上搜到一段源码分析，但自己手里的分支版本完全不同，不要怀疑自己理解错了，先看看对方文章的版本号和目录截图，再决定是否参考。我自己遇到过好多次，按照老版本源码写好的扩展点，在新版本里根本找不到对应类名，实际是模块重构后改了目录和命名。

第二，源码里藏了大量实验性代码和废弃路径。有些模块在多版本里保留着两套实现，比如 AEC 的 legacy 版和 AEC3 版，如果只看了某一套实现就下了结论，可能忽略另一套才是默认启用的路径。判断默认路径的方法，是在初始化带参时找field_trial、Config或者absl::GetFlag读取的默认值，这些地方写清楚了哪个是默认启用项。

第三，一定要配合测试代码看。WebRTC 仓库里每个大模块都带着大量单测和集成测试，比如pc/peer_connection_integration_test.cc里把一个完整呼叫流程直接跑起来。遇到看不懂的函数，搜一下同名测试，往往能很快看到这个函数的预期输入输出，比单纯盯着实现容易理解得多。

第四，别忽略 BUILD.gn 里的依赖信息。模块之间到底谁依赖谁，最权威的答案其实不在架构图里，而在BUILD.gn的deps字段里。你看到某模块deps里没有包含另一个模块，基本可以断定这个模块在代码层面不直接依赖对方。这种“编译期的依赖证据”，比很多二手资料更可靠。

第五，性能问题的终极手段是回源头看数据流。我之前排查过一段时间的丢帧问题，外部表象是 CPU 占用过高，压测人员怀疑是编码器性能差。最后翻VideoStreamEncoder的调用链，发现每一帧在送入编码器前都会被复制三次，一次是格式转换、一次是分辨率缩放、一次是传给编码器缓冲。后来通过直接复用 buffer 的方式优化，CPU 占用立竿见影地下降了。如果你遇到棘手的性能问题，先画出关键数据流的拷贝次数，往往比直接猜“是不是代码复杂”有效得多。

这套东西说它是一座城市，真的一点不夸张。地图已经递给你了，下一步就是找自己最需要那条主干道，穿进去走一遍。希望你少走我踩过的那些弯路。