scrcpy：显示并控制你的 Android 设备

153.8k

Apache License 2.0

技术解读

以下内容由 GitRead 中文社区编辑团队基于项目 README 与官方资料整理，结合中文开发者的常见使用场景补充技术选型建议。具体以项目官方文档为准。

项目背景与痛点

Android 生态里，"把手机屏幕搬到电脑上"这件事已经被反复做过无数遍，但真正好用的方案屈指可数。Vysor 早年靠 adb 拉取截图再用 JPEG 压缩推流，帧率勉强上到个位数，输入延迟动辄两三百毫秒；AirDroid 那类方案走网络长连接，画质和时延都被 WiFi 环境和厂商 ROM 拖累；至于各类手机厂商自带的投屏助手，往往绑定自家生态，跨平台无从谈起。

真正的痛点在于三个层次。第一是免侵入：绝大多数方案要么要求 root，要么要求设备端安装一个常驻 APK，前者在商用设备上基本不可行，后者在企业 MDM 环境里会触发合规审查。第二是低延迟：屏幕镜像如果延迟超过 100ms，操作体验就会立刻崩塌——点击的反馈滞后于视觉，人脑会强烈地感到"不对劲"。第三是跨平台：开发者手边可能是 macOS、Windows、Linux 任意一种，工具不应该强迫人换工作流。

scrcpy 的解题思路极其克制：它不装 APK，而是把服务端编译成一个 jar 直接推到 /data/local/tmp，用 app_process 以 shell 用户身份起一个 Java 进程；它不搞网络协议栈，直接复用 adb 已有的 forward 通道建立本地套接字；它不做软件编码，把屏幕直接喂给设备的硬件编码器。三刀砍下去，延迟被压到 35~70ms 区间，而整个工具不需要 root，不需要在设备上留下痕迹，退出即干净。

核心技术揭秘

scrcpy 的架构是经典的"瘦客户端 + 设备侧代理"，但每一处连接都做了针对性取舍。

graph TD A[桌面端 scrcpy 客户端] -->|"adb push 并 app_process 启动"| B[设备端 scrcpy-server] B --> C[SurfaceFlinger 屏幕合成] C --> D[MediaCodec 硬件编码 H.264/H.265] D --> E[LocalSocket 视频流] E -->|"adb forward 转发"| F[客户端 Demuxer 拆帧] F --> G[FFmpeg 解码] G --> H[SDL2 纹理渲染] A -->|"鼠标键盘事件"| I[独立控制 Socket] I --> J[InputManager 注入事件] J --> C

采集与编码是设计的核心。 服务端没有用 MediaProjection（那会弹系统授权框），而是直接用 Surface 作为 MediaCodec 的输入，把屏幕合成分辨率作为编码器尺寸。关键在于编码器输出走的是 Surface 直通模式，像素数据全程不落 CPU 内存，省掉了两次大块内存拷贝——这是它能跑满 60fps 4K 的根本原因。编码器吐出的 ES 流不封装成 MP4 或 RTP，而是由 scrcpy 自定义了一层极薄的帧协议：12 字节包头区分 codec config（SPS/PPS）和数据帧，后面直接挂裸 NAL。省掉容器解析，客户端拿到字节就能往解码器里塞。

双通道分离是一个容易被忽略的精妙点。 视频 socket 和控制 socket 是两条独立的 adb forward 通道。如果把输入事件塞进视频流里复用一条连接，一个大关键帧的传输就会把点击事件堵在后面，体感上表现为"点了没反应"。分离之后，控制指令走的是小包快路，天然避开了队头阻塞。

输入注入靠的是 shell 权限。 服务端进程以 uid 2000 运行，调用 InputManager.injectInputEvent 注入 MotionEvent 和 KeyEvent，这条路径既不需要无障碍服务，也不需要 root。更进一步的 --otg 模式则彻底绕过 adb：把手机当作 USB HID 设备，由主机端直接枚举成键盘鼠标，设备上连一行软件都不跑，代价是必须用 USB 线且无法同时传输画面。

客户端侧刻意保持"零缓冲"。 FFmpeg 解码出帧后立刻上传 SDL 纹理并渲染，不做任何帧队列平滑。这会牺牲一点播放的均匀性，但换来的是最短的端到端延迟——对交互式工具来说，这个取舍方向是对的。

功能亮点与差异

第一杀手锏是真正的熄屏操作。--turn-screen-off 通过注入电源键事件让物理屏幕熄灭，但编码器仍在工作。这意味着你可以在手机屏幕完全黑掉的状态下继续操作它，既省电又避免旁人窥屏，这是几乎所有竞品都没做到的细节。

第二是双向剪贴板同步。文本剪贴板在设备与主机间自动对齐，配合键盘直接输入中文，把"手机上打字难"这个老问题彻底消解。

第三是参数化的质量旋钮。--max-size（限制长边分辨率）、--max-fps、--video-bit-rate 三个参数组合，可以精确地把带宽和延迟调到任意工作点，这在弱网无线调试或者老旧设备上极其重要。

第四是虚拟显示。Android 14 起可以开一个独立于物理屏幕的虚拟 display，主屏照常使用，投出来的是另一块屏幕，多任务场景的价值很高。

最后是协议完全开放。服务端 jar 可以脱离官方客户端独立部署，任何人都能基于这套二进制协议写自己的前端——QtScrcpy、guiscrcpy 这类 GUI 封装正是这么长出来的。

应用场景与落地建议

最适合的场景是自动化测试与远程真机调试。CI 里只要有 adb，就能拉起 scrcpy 做录屏、做视觉回归、做点击脚本的验证，延迟低到可以当作实时操作台用。其次是技术支持与远程协助，客服人员可以接管用户设备而无需安装任何 App。

生产环境落地有几条必须注意的红线。依赖 USB 调试通道本身就是合规风险：企业设备通常禁用开发者选项，这一条卡死了大量场景。DRM 保护内容无法投屏，Secure Surface 在编码器层面就是黑的，别指望绕过。厂商 ROM 差异显著，MIUI、EMUI 对 shell 权限和 app_process 的限制并不一致，需要逐机型验证；音频捕获要求 Android 11+ 且依赖 REMOTE_SUBMIX，不少定制系统直接阉割了它。无线调试建议 5GHz 频段，2.4G 下码率稍高就会明显抖动。如果要嵌入自有产品，更好的做法是复用它的服务端 jar 自建控制协议，而不是 fork 整个客户端。