ARTICLE · 1270193
不装App、不用Root,自己动手做一个USB投屏神器
不装App、不用Root,自己动手做一个USB投屏神器拿一台安卓9老手机实测，720×1560分辨率： 投屏：设置页滚动时约39.5帧每秒，画面流畅无花屏； 旋转：横竖屏切换后自动调整，画面方向不歪； 操作：点击、拖拽、右键返回、中键回桌面、滚轮滑动、输入中文都能用； 断线自愈：手机端程序意外挂掉，电脑端会自动把它重新拉起来，画面自动恢复。 手机不用装任何软件，也不用Root，电脑上只要有ADB调试工具就行。 市面上其实已有类似工具（比如scrcpy），但有几处不满足需求： 手机端不装任何App——常规录屏必须在一个App里点"允许录制"才能用，这条路走不通； 要兼容老设备（安卓5到10），很多新工具只照顾新版本； 协议想能自己改、嵌到自己的工具里，现成的二进制协议没有文档，改起来成本高。 于是作者自己动手：电脑端用C++写客户端，手机端跑一段纯Java后台程序，两端用一套自己设计的数据格式通信。 这是整个项目最巧妙的地方。普通录屏需要MediaProjection这个API，但它要求必须有一个App在前台点击"允许"，而这里手机端是无界面的后台进程，没法走这条路。 好在安卓的shell用户（也就是ADB调试用的那个身份）自带两个"特权"： 可以调用系统显示管理接口，创建一块"虚拟屏幕"； 拥有"注入事件"权限，能模拟触屏和按键。 于是方案是：造一块虚拟屏，把手机主屏幕内容投进去，再让硬件编码器直接从这块虚拟屏取画面，压缩成H.264视频流，通过USB传给电脑。 延迟是投屏的核心体验。作者把整条链路拆开算了一笔账： 屏幕合成+编码：8~20毫秒 USB传输：5~15毫秒 电脑端解码：3~10毫秒 排队+显示：16~33毫秒 合计约40~70毫秒，实际用起来拖拽、滑动基本跟手。 为了抠出这几十毫秒，做了三处关键优化： 减少拷贝次数：一帧画面从手机到电脑，从原来5次数据搬运砍到基本直传，大幅降低CPU负担； 收帧缓冲复用：不再每帧临时申请内存，避免反复分配的开销； 解码零拷贝：解码后不再逐像素复制一遍，直接交给显示，省掉一帧约1.68MB的整帧搬运。 电脑端还做了"多线程分工"：一个线程负责收画面、一个负责发指令、一个负责显示。这样手机端一旦卡一下，发送线程也不至于把整个窗口卡死。 鼠标操作到手机上的映射很讲究： 左键点击/拖动 → 手机的触摸按下/移动/抬起 快速拖动 → 自动插入多个中间点，否则系统会认为你在"瞬移" 右键 → 返回键，中键 → 回桌面 滚轮 → 换算成滑动操作 输入中文 → 通过剪贴板+粘贴实现 坐标全部做归一化处理，电脑窗口随便缩放都不影响操作准确。 作者特别强调几个"看起来能连上"的陷阱： ADB隧道的假连接：手机端程序挂掉后，本地端口依然能连上，但发消息没回应。所以判断逻辑是"连上了但握手失败=手机端已经挂了"，要自动重新拉起程序，还要等它真正启动好再重连，避免陷入死循环。 非法数据直接断开：读到格式不对的数据，不尝试去"猜"，而是直接断线重连，因为流已经错位，继续读只会越错越多。 加安全token：每次连接带一个随机校验码，防止本机其他程序偷看你的屏幕。 这套方案目标很明确，也有一些"明确不做"的事：不支持安卓11以上、不传音频、不支持录屏、不支持多台手机同时投、编码参数固定。 它适合这些场景：老安卓设备远程操控/演示、测试机批量操作、想在自己工具里嵌一块投屏窗口、内网环境下不想装第三方App。 这个项目真正有价值的，并不是"把画面传过来"本身，而是三件工程上的小事： 权限边界：没有正规录屏API，就换一条路走，用好系统默认给的能力； 协议边界：长度上限、类型白名单、安全token，把不可信的数据挡在最外面； 延迟边界：线程各司其职、每帧少搬一次数据、队列满了就丢旧数据。 把这三件事做扎实，40~70毫秒的延迟和"断线自己能爬起来"的稳定性，就是自然而然的结果。 项目源码：https://github.com/suihanlansnow/control_android_usb
只需要一台Windows电脑和一根USB线，就能把安卓手机屏幕投到电脑上，还能用鼠标键盘直接操控手机。不用装App，不用Root，手机里跑一段小程序，电脑上跑一个客户端，靠一根USB线就把画面和操作连起来。这听起来很酷，实际上它背后藏着不少巧妙的设计。
先看看它有多好用
为什么还要自己做一个
手机没装App，怎么把屏幕传出来？
注意：这套玩法只对安卓5到10有效，安卓11之后系统接口有变动，是明确的兼容边界。
画面怎么又快又不卡
用鼠标键盘"玩"手机
稳定性是怎么保证的
做了哪些取舍
结语
用一根USB线，让旧手机焕发新生——这种"小而巧"的工程，往往最能体现功底。
