一台云端 Android 通常不止一条连接：
- 视频流持续推画面；
- 音频流单独走；
- 客户端不断发触控、按键和输入事件；
- 控制通道还要承载设备状态、通知和扩展命令；
- 截图、Shell 、文件读取这类任务还需要请求和响应匹配。
如果 Relay 只把这些当成几条独立 WebSocket ，问题会很快暴露：页面刷新后旧连接怎么释放，设备重连时新流绑定到哪个会话，慢客户端会不会拖住转发路径，截图和 Shell 的返回结果会不会串线。
我现在更关注几件比较朴素的控制点：
1. 会话、设备、客户端、流之间的绑定关系要清楚；
2. 写入客户端要有 deadline ，缓冲区要有上限；
3. 控制消息需要 request id ，响应不能只按返回顺序处理；
4. 半开连接、失效路由、旧会话映射要及时清理；
5. 重连前先让状态收敛，否则重试也可能落回脏状态。
这些点不如“低延迟”听起来醒目，但实际会影响云手机是不是会卡住、串线、重连异常或者长期占资源。
这篇是从蜂壳云的一篇技术日志改写的，原文在这里：
https://www.phones-cloud.cn/blog/relay-stability-for-cloud-android
如果你们做过长连接、远程桌面、设备控制或类似的实时会话系统，Relay 层最容易踩坑的地方一般是写入背压、会话绑定，还是异常清理？
