阅读路线：怎样读完一个双端实时系统

scrcpy 不是“一个播放器”，而是桌面客户端、Android 服务端、ADB 和三类协议共同组成的实时系统。正确的阅读单位不是文件，而是一条端到端的数据流。

一、源码基线与边界

本文档以本地快照中的 meson.build 与 server/build.gradle 为准，两处都声明版本 4.1：桌面端构建入口见 meson.build，Android 服务端版本见 server/build.gradle。

统计口径只包含生产源码：

区域	文件数	行数	主要语言
app/src	168	29,608	C / Header
server/src/main/**/*.java	91	12,012	Java
合计	259	41,620	C + Java

测试、构建脚本、官方使用文档和 Gradle 生成物不计入上表。它们会在第 15 章作为工程证据单独讨论。

二、先建立四个心智模型

1. 两个进程，不是一个应用

桌面端 scrcpy 是原生 C 进程，依赖 SDL 3 和 FFmpeg；设备端 scrcpy-server 是通过 app_process 启动的 Java 进程，运行在 Android shell 身份下。两端没有共享内存，只通过 socket 与 ADB 操作协作。

2. 三条通道，不是一条复用连接

视频、音频、控制分别占用独立 socket。这样视频大包不会阻塞按键，音频失败也可以只关闭音频而继续镜像。通道是否存在由 video/audio/control 三个布尔值决定，建立顺序本身就是协议的一部分。

3. 两级分流，不是固定流水线

客户端先在“压缩包”层分流，再在“解码帧”层分流：

┌→ Recorder（压缩包，免重编码） socket → Demuxer ─┤ └→ Decoder → FrameSource ─┬→ Screen ├→ AudioPlayer └→ V4L2 sink

这套 source → sink 结构解释了为什么 --no-playback --record 不需要解码，也解释了新增输出后端应插在哪一层。

4. 输入是策略，不是窗口的附属物

SDL 只负责收集宿主事件；input_manager 将它们翻译成内部事件，再交给 key_processor / mouse_processor / gamepad_processor 接口。具体实现可选择 SDK、UHID 或 AOA，因此 UI 与注入方式被刻意解耦。

三、推荐阅读顺序

地图阶段：第 1–3 章
先认清进程、组件、启动顺序和资源所有权，不要急着钻进编解码细节。

边界阶段：第 4–5 章
读懂 ADB 隧道与线协议。此后所有媒体和控制代码都会变得具体。

数据阶段：第 6–8 章
沿视频与音频数据从 Android 到桌面走一遍，重点观察时间戳、重配置和低延迟取舍。

交互阶段：第 9–11 章
从 SDL 事件反向走回 Android，比较三种输入后端，并理解坐标变换。

工程阶段：第 12–15 章
研究录制分流、线程退出、隐藏 API 兼容和构建测试，形成可迁移的设计经验。

如果只想修改某一处，可以走捷径：

目标	必读章节	关键入口
新增视频输出	7、12	packet_sink.h / frame_sink.h
修改控制消息	5、9	两端消息枚举、序列化和解析必须同步
新增输入后端	10、11	processor 接口 + scrcpy.c 装配
处理旋转/分辨率变化	6、7、11	session meta + capture reset
排查退出卡死	3、13	stop / interrupt / join / destroy
适配新 Android 版本	9、14	wrappers + Workarounds + FakeContext

四、每章的阅读模板

本系列刻意重复以下结构：

1. 问题：这块代码真正要解决什么约束；
2. 参与者：哪些线程、对象和通道参与；
3. 主路径：按调用顺序追踪一条正常数据；
4. 异常路径：失败、重试、降级和清理如何发生；
5. 设计取舍：为什么不用看似更简单的方案；
6. 源码锚点：给出稳定的 v4.1 文件与行号。

这与按目录逐文件讲解不同。比如 scrcpy.c 同时装配视频、音频、控制、录制和输入；只孤立解释这个文件会得到一张组件清单，却看不到数据为何分流、退出为何逆序。

五、源码链接如何使用

文中的源码链接固定到 v4.1 tag，不指向会漂移的 master。例如客户端总装配入口是 scrcpy()，设备端总装配入口是 Server.scrcpy()。

阅读时建议保持三个窗口：本文、客户端源码、服务端源码。看到协议字段时必须双端对照；看到线程回调时要回到总装配入口确认谁持有对象、谁负责销毁。

六、三条自检问题

读完每章后，不妨问自己：

1. 这段数据现在归谁所有？是借用、复制还是转移所有权？
2. 当前代码运行在哪个线程？它如何把工作交回主线程？
3. 如果对端此刻断开，哪个阻塞调用会醒来，谁发出退出事件，谁最终 join？

能持续回答这三问，就已经抓住了 scrcpy 工程设计的主脉络。

下一章先站到最高处，看完整系统的分层和双向数据流。