在现有 Android 自动化平台上做工程化改造与验证：设备资源互斥、实时投屏遥控、步骤回放与失败证据链，以及断开 / 崩溃 / USB 断连后的故障恢复。
概要
项目关系
TestHub 是在现有 Android 自动化平台基础上的工程化改造与验证工作，原项目 README 保留其他作者署名。我的工作集中在设备资源管理、实时控制反馈、步骤回放与故障恢复这条核心链路上。
关键实现
- 技术栈：Django / DRF、MySQL、Celery、Channels、Vue；自动化链路涉及 Airtest / Playwright、scrcpy、WebSocket 与浏览器视频解码。
- 设备资源管理：以设备槽位为单位做 CAS 与事务互斥，保证并发场景下每台设备同一时刻只有一个占用者。
- 实时控制与反馈：真机画面投屏到浏览器并可遥控，支持旋转；反馈以真实视频帧上识别到的公开测试图案为准。
- 步骤回放与失败证据链：执行事件与步骤截图持久化，刷新后可恢复回放，支持鉴权下载与 Allure 报告生成，Allure 原始步骤附件与对应持久化截图经解码后做像素一致性核对。
- 故障恢复：覆盖连接断开、占用到期、进程崩溃、USB 断连四类故障的检测与恢复。
分析与验证案例：1800 秒连续真机控制的验收
2026-10-16 完成一次单机阶段验收：一台 Redmi Note 10 Pro、本地公开测试图案、同一会话连续 1800 秒。结果为 600/600 次真实像素反馈成功，控制反馈 P95 = 220.6ms，平均绘制 13.32 FPS。
测量口径是“从浏览器实际发出控制指令，到真实视频帧绘制出来并识别出对应图案”的完整链路，包含识别开销；它不是纯视频端到端延迟，也不是物理出光延迟。这些数字属于这次验收的设备与页面条件，不能推广到所有设备 / 页面，也不代表生产部署水平。完整整理见实践记录《怎样验证 Android 真机控制的可靠性？》。
步骤回放与失败证据链
2026-10-17 在隔离环境完成回放链路的阶段验收：覆盖真实 worker 到 pytest 再到 Airtest 的成功与运行异常两轮执行，事件与步骤截图持久化，刷新后可恢复回放，证据文件经鉴权下载，Allure 原始步骤附件与对应持久化截图经解码后做了像素一致性核对。这条链路让失败现场可复查，而不是只留下一个失败结论。生产环境的回放开关默认关闭，该功能尚未在生产启用。
logcat 采集进展
logcat 数据与身份基础、采集协议、本机进程与隔离数据库的集成，以及历史数据读取资格修复，已分别完成阶段验证。可信的退出证明、Android 真机采集运行时与正式接线仍在推进：该日志链路的内部入口默认关闭，会话 pending、退出证明为空、日志为零时，不因合成验证通过而释放设备占用——证据不足时保留不确定状态，避免误释放资源。
当前状态
- 核心链路与步骤回放已完成阶段验收；步骤回放的生产开关默认关闭，未上线启用。
- logcat 真机采集运行时与正式接线仍在实施中。
- 验收测量为单设备单会话条件下的记录，数字对应当时的设备与页面条件。
相关实践记录
- 怎样验证 Android 真机控制的可靠性？ · 2026-10-16