Anura 移动端调试与产品状态报告

Anura 移动端调试与产品状态报告

背景

核心目标：让 Anura 在手机浏览器上完成从打开摄像头、识别人脸、开始采集、上传分析到展示结果的完整体验。

• 产品定位不变：参考 demo 的顺畅流程。
• 架构目标不变：保留当前项目前后端拆分、密钥不暴露、数据更私密的优势。

当前进展

• 基础链路推进明显。手机端现在可以通过 HTTPS 本地地址打开页面，前置摄像头可以启动。
• 人脸框已恢复动态跟随。从早期的固定不动、无法识别人脸，推进到可以动态跟随人脸。
• 摄像头选择更自然。设备列表从一堆无意义编号，调整为前置摄像头、后置摄像头和真实外接摄像头。
• 流程分段更清楚。准备阶段和正式采集阶段已重新区分。

• 之前准备阶段的进度条会自己跑到 30 秒，容易让用户误以为已经完成采集。
• 现在已修正为：准备阶段只做人脸检测和画面质量判断，只有用户点击开始测量后才进入正式采集计时。

实际定位

结论不是单一 bug，而是多条链路一起错位：

• 移动端视频流、画布尺寸、叠加层坐标、MediaPipe 输入时间戳、前后摄像头约束、页面刷新缓存，共同造成问题。
• PC Web 能跑，不代表手机端同一路径也正确。
• 手机端更容易遇到：
• 视频尺寸初始为 2x2
• track 已结束
• 画布尺寸未同步
• 检测输入帧不稳定

调试方式变化

后面不再让每次刷新试一次，而是保留手机页面，通过前端诊断日志连续看：

• video 宽高、readyState、currentTime
• track 状态、facingMode
• canvas / overlay 尺寸
• MediaPipe detectorRaw / landmarkRaw
• accepted / rejected face
• faceRect 是否变化
• start availability 是否 enabled

这一步把问题从“主观看不到框”变成“能证明检测链路哪一段断”。

最终移动端进展

移动端人脸检测后来打通：

• 前置摄像头可用
• 绿框能动态跟随人脸
• 准备阶段可以进入可开始状态

后续问题转移到采集和结果链路：

• 画面质量
• SNR
• chunk
• measurement
• 结果轮询是否对应

产品价值变化

• 状态变化：从桌面端可用、手机端不稳定，推进到手机端核心交互基本成立。
• 场景匹配：生命体征检测天然更适合手机前置摄像头场景。
• 架构保持：项目没有回退到 demo 那种把能力都压在前端里的方式，而是保留了服务端承接真实配置和结果处理的方式。

一句话：移动端体验是否成立，直接决定产品能不能被普通用户自然使用。

主要问题演进

当前产品状态

• 已具备真实测试基础条件：
• 摄像头能开
• 人脸能跟踪
• 画面质量和信噪比判断可用
• 真实 DeepAffex 配置已接入
• 已有一次完整 6 段采集完成记录
• 仍未完全闭环：
• 用户完成 30 秒采集后，结果是否及时、明确、稳定地展示出来，仍是关键点。
• 这一步决定用户是否相信检测已经完成，也决定产品体验是否像 demo 一样顺滑。

结论

• 结论：本轮工作把 Anura 移动端从摄像头和人脸检测不可用，推进到核心检测链路基本可跑。
• 下一阶段重点：结果展示和完整体验闭环。