测量口径
TestHub 的核心链路是“浏览器遥控 Android 真机，并确认真机真的执行了”。验证口径定为：从浏览器实际发出控制指令开始，到真实视频帧绘制出来、并在画面中识别出对应的公开测试图案为止的完整耗时。这个口径包含图案识别的开销，因此它不是纯视频端到端延迟，更不是物理出光延迟——三者经常被混为一谈，但测的是不同的东西。
条件
2026-10-16 的一次单机阶段验收：
| 条件 | 取值 |
|---|---|
| 设备 | Redmi Note 10 Pro（一台） |
| 图案 | 本地公开测试图案 |
| 会话 | 同一会话连续 1800 秒 |
| 操作 | 每次发送控制后等待真实像素反馈 |
真实画面绑定
关键设计是反馈必须绑定真实画面：不是“指令发出去了”、“设备返回了成功码”，而是真机渲染出的视频帧里实际出现了目标图案。这把投屏解码、指令下发、设备执行、画面回传整个闭环都纳入了验证范围，避免用中间层的成功冒充最终结果。
失败分母
结论的分母是 600：连续 600 次控制，600 次在真实画面中得到反馈，失败 0 次。同时记录了控制反馈 P95 = 220.6ms，平均绘制 13.32 FPS。
结果与限制
600/600 说明这条链路在本次条件下是可靠的，但条件本身就是限制：
- 单设备、单会话、公开测试图案，不推广到所有设备与页面；
- P95 包含识别开销，不能当作纯视频链路延迟引用；
- 这是阶段验收的历史记录，不代表生产部署水平。
验证方法的要点：先定义可观测的最终效果（真实像素），再定义分母（完整尝试次数），最后把口径写进结论——数字脱离口径就没有意义。