一次云手机会话在 Relay 里如何保持可控
Phones Cloud ·
用户看到的是一个 Android 屏幕，Relay 处理的是多条长期存在的媒体流、控制流和状态映射。
远程 Android 的体验很容易被理解成“把屏幕推到浏览器”。在实现里，它更像一组长期存在的流：设备侧推视频和音频，客户端侧发触控和按键，控制通道承载状态和扩展命令。
Relay 位于这些流的交叉点。它不拥有 Android 状态本身，却要维护哪条流属于哪台设备、哪个客户端、哪个会话，以及当其中一部分失效时该如何释放和重建。
会话由多条流组成
同一台云手机通常会同时存在视频流、音频流、控制流、通知流，以及用于截图、Shell 或文件读取的扩展控制消息。它们连接时间不同，流量形态不同，失败方式也不同。
Relay 的第一件事是把这些流绑定到同一个设备和会话上下文里。只有这样，视频断开、控制流仍在，或客户端重连时，系统才知道哪些资源应该保留、哪些资源应该释放。
写入必须有边界
Relay 面对的是浏览器、移动网络、弱网、后台切换和长时间在线。写入客户端如果没有超时，缓冲如果没有上限，一条慢连接就可能拖住整条转发路径。
因此，Relay 侧的可靠性来自一批很朴素的控制：有限缓冲、写入 deadline、连接关闭后的资源释放，以及不会随着历史会话无限增长的路由表和限流状态。
控制消息也要可匹配
当截图、Shell 或文件读取通过控制通道发送时，它们不再只是单向输入事件。服务端会发出请求，然后等待设备侧返回对应结果。
这类扩展消息需要请求编号和响应匹配，否则并发任务会互相干扰。Relay 的控制通道因此同时承担输入转发和任务结果回收两类职责。
自愈从清理开始
长连接系统里的自愈不只是重试连接。更重要的是在心跳超时、写入失败、半开连接和异常关闭后，让旧状态尽快收敛。
当失效连接不再占用缓冲区、设备路由和会话映射，下一次重连才会落到干净的状态上。Relay 的稳定性，最终来自这些持续发生的收敛动作。
工程要点
- 云手机会话是一组长期存在的流，不是一条连接。
- 有限缓冲、写入 deadline 和资源清理让 Relay 在弱网下保持可控。
- 请求响应匹配让控制通道可以承载截图、Shell 和文件类扩展任务。
查看开发者控制入口
继续了解 phones-cloud-cli 如何把云端 Android 接入脚本、测试和 Agent 工作流。