安卓眼动交互验证：需求分析报告与演示 APK 方案

版本：v1.0，待评审
日期：2026-10-26
阶段：需求访谈完成，方案待评审；APK 尚未实现，真机效果尚未验证。

1. 结论与项目目标

本项目验证一个具体问题：在手机固定、用户不戴眼镜、距离约 30～50 厘米的条件下，安卓前置摄像头能否识别“低头、眼睛上抬，同时注视人物图片下方指定区域”的动作组合，并在持续约 1 秒后触发提示。

成功提示必须逐字显示：

捕获特定眼睛成功

建议采用 Android 原生应用、CameraX 摄像头采集和 MediaPipe Face Landmarker，并增加个人校准、头眼动作判断、屏幕区域估计和时间过滤。

可行性结论分为两层：实时提取脸部与眼部特征有成熟工具；在低头姿态下准确判断目标区域需要额外算法和真机实验，当前不能承诺已达到可用精度。本项目的结果可以是“在规定条件下通过”，也可以是“已量化识别瓶颈，需继续优化”，不能以数次成功画面代替验证。

2. 用户已确认的需求

以下是开发方提出的实现参数，不视为用户已逐项确认：最低兼容 Android 11、竖屏、五点注视校准、动作校准、初始姿态阈值、退出延迟及量化验收门槛。

3. 范围与能力边界

3.1 本版包含

• 前置摄像头权限、采集、实时人脸与眼部追踪。
• 中立姿态、注视点及目标动作校准。
• 低头与眼睛上抬的独立状态显示。
• 注视目标区域的估计和联合触发判定。
• 人物占位图、目标矩形调整、调试信息和指定提示文字。
• 测试任务、日志导出、进入／离开目标状态事件。

3.2 本版不包含

• 可旋转的 3D 数字人、裙子物理模拟、捂裙子动画或其他动作资源。
• 手机移动、行走、多人、戴眼镜或任意光照条件下的可靠性保证。
• 无校准使用、医学级眼动测量或精确点击小按钮。
• 对观看意图、心理状态的推断。
• 应用商店上架、账号系统和云端服务。

人物图是平面素材，不会因用户低头而产生真实的观察视角变化。本项目验证动作和目标注视条件，不验证图片未呈现的内容。

4. 触发行为的可测量定义

头部俯仰与眼球转动必须使用不同参照系：

业务触发条件：V、H、E、G 同时成立，连续持续至少 1000 毫秒。

持续时间采用摄像头帧的单调时间戳计算，不用累计固定帧数代替，避免不同帧率改变触发时长。

如果部分头姿下 G 无法可靠估计，应显示“注视估计无效”，不能悄悄取消 G 条件、仅凭 H 和 E 触发成功。动作识别和区域识别需要分别报告结果。

5. 技术路线比较与推荐

不选择 ARKit，原因是本次目标平台为 Android。第一版也不引入 Unity，避免追踪验证依赖 3D 引擎；后续使用结构化事件接入数字人模块。

5.1 软件组成

拟采用 Kotlin、CameraX、MediaPipe Tasks Vision。模型随 APK 打包，安装后无需联网下载模型；具体依赖版本在实现时固定，避免动态版本。

处理顺序：

摄像头帧 → 旋转及坐标处理 → 脸眼特征 → 校准映射与头姿补偿 → 有效性检查 → 条件过滤与计时 → UI 和事件输出。

前置摄像头预览的镜像必须与推理输入坐标明确区分。目标矩形使用应用内容区域的归一化坐标，不包含状态栏和系统导航栏；图片缩放留白也要纳入坐标变换，避免矩形看起来正确但判断区域偏移。

5.2 屏幕区域估计

候选输入包括归一化虹膜位置、眼睑和眼角几何关系、头部俯仰与偏航、脸部在图像中的位置和尺度，以及眼部动作系数。具体特征组合由试验选择。

通过用户注视已知位置的校准样本建立映射。首轮使用低复杂度、带正则化的映射，避免少量校准数据拟合过度；验证样本与拟合样本分开采集。归一化估计坐标不代表物理测量精度。

先验证目标姿态下的粗区域区分能力，再尝试完整坐标显示。若只验证到区域级别，应在 UI 和报告中如实标明，不展示虚假的精确注视点。

6. 校准设计

初始流程建议如下，实际耗时由试验确定：

1. 用户在 30～50 厘米范围内选定位置，固定手机，脸部均匀受光。
2. 采集中立头姿和自然睁眼状态，作为本次会话基线。
3. 依次注视中心、左上、右上、左下、右下五个点，采集稳定样本。
4. 提示用户做低头、眼睛上抬动作，采集目标头姿和眼部上抬样本。
5. 在目标低头姿态下补充目标区及周围非目标区的注视样本，验证中立姿态校准是否失效。
6. 使用额外采集的验证点检查区域区分能力；质量不足时引导重试，不能直接进入“校准成功”。

如果同时满足低头、眼睛上抬和目标区域注视对某位用户不自然，应先调整支架高度、人物位置或目标矩形，再重新校准。不得把用户无法自然完成的动作当作正常漏检。

30～50 厘米是允许选择起始位置的范围，不是同一次校准后的自由移动范围。明显改变位置、屏幕方向或支架姿态后应重新校准。阈值和校准参数仅服务于本次测试，首版默认不跨会话复用。

7. 界面与操作

首版建议竖屏，主要区域为：

• 顶部：摄像头、校准与追踪状态。
• 中部：人物占位图和目标矩形；用户可在编辑模式拖动和缩放矩形。
• 提示区：默认显示“检测中”；触发后显示“捕获特定眼睛成功”。
• 调试区：低头、眼睛上抬、目标注视三个条件各自状态，以及持续时间；可展开摄像头预览和关键点。
• 底部操作：开始校准、重新校准、编辑目标区、测试记录、导出日志。

目标矩形在编辑完成后锁定，测试中不误触移动。调试控件避免覆盖目标区或要求用户在正式试次中频繁看向按钮。

建议初始目标矩形放在图片裙摆附近的可见区域，具体位置随示意图确定，不将“屏幕下半部分”全部当成目标。进入条件使用内缩缓冲区，边缘不确定位置优先不触发。

8. 状态机与异常行为

首版采用保守策略：候选阶段出现无效帧或条件不成立即重置计时，后续根据漏检情况再评估短暂容忍。已触发时，普通条件离开可采用约 200 毫秒退出延迟减少闪烁；追踪失效则立即标记无效并撤销有效命中显示。退出后必须重新满足完整 1 秒才能再次触发。

帧处理采用保留最新帧的方式，不堆积旧画面。过期结果不参与判断；时效阈值需结合实测处理延迟确定。应用进入后台时停止采集，恢复后检查校准有效性。

9. 系统兼容和运行条件

• 计划 compileSdk 36、targetSdk 36，对应 Android 16。
• 建议 minSdk 30，对应 Android 11；依赖和目标设备支持情况在构建时核对。
• Android 16 是目标版本，不代表用户已提供 Android 16 真机。
• 测试手机品牌、型号、处理器、实际系统版本尚未取得。
• 首轮建议普通室内均匀光照，避免强逆光，保证双眼清晰可见。
• 单人、不戴框架眼镜、固定支架、30～50 厘米、完成当次校准，是首版有效测试前提。
• 优先支持常见 ARM64 真机；最终 APK 的架构支持由依赖和构建产物验证后写入安装说明。

手机型号未提供不阻止编写报告和构建，但无法提前保证帧率、发热和识别效果。模拟器可检查部分界面流程，不能代替实际前置摄像头眼动验收。

10. 验收方案与建议门槛

以下量化值为建议的首轮评估门槛，尚未得到真机证明；不能描述为现有能力或用户已经确认的指标。

10.1 功能验收

• APK 可在列入测试记录的设备上安装、启动和使用前置摄像头。
• 支持完成校准、调整矩形和导出日志。
• 成功文字严格为“捕获特定眼睛成功”。
• 不满足完整条件或持续不足 1 秒时不应触发。
• 闭眼、丢脸、权限拒绝等状态能得到正确处理。
• 不保存或上传原始画面，联网能力不作为推理前提。

10.2 试次与对照

建议首轮至少 3 名不戴眼镜的成年人，在同一测试手机上分别校准，每人完成至少 20 次正例和 40 次负例。每个试次间回到中立姿态，避免上一试次的持续状态影响下一次。

正例：完成低头、眼睛上抬，并持续看目标矩形约 2～3 秒。

负例应分组包含：

1. 头部中立，仅看目标区。
2. 只低头，没有完成指定抬眼动作。
3. 只抬眼，没有低头。
4. 低头、抬眼，但看目标矩形外部的邻近区域。
5. 完整动作但目标注视不足 1 秒。
6. 眨眼、闭眼或短暂离开画面。

不能自然完成的组合记录为无效试次并注明原因，不纳入成功率分母。算法信心不足、校准失败或追踪失败的数量应另行报告，不能用删除失败试次的方法掩盖问题。

10.3 记录指标

各用户的结果单独报告，同时给出汇总；小样本通过只支持本轮条件，不代表所有人和所有手机均可靠。

测试标签来自屏幕指令和用户配合，并非专业眼动仪测得的真实注视点。面部动作是否完成与注视指令是否执行需记录可信程度。日志的指令开始时间不能直接充当真实动作开始时间；没有独立动作起始标注时，只能报告指令至触发延迟及算法内部计时，不能声称测得端到端物理响应延迟。

11. 日志与未来接口

日志拟包含会话编号、试次编号、单调时间戳、指令目标、追踪状态、头姿估计、眼部动作特征、估计区域、H/E/G/V 状态、候选时长、事件和参数版本。无需保存姓名；不默认导出原始画面或完整面部关键点。

算法估计结果和测试指令标签必须分列，避免用算法自身结果充当正确答案。日志只能通过用户主动操作导出。

未来数字人接口建议提供：TrackingInvalid、CandidateStarted、TargetConfirmed、TargetExited，以及时间戳和失效原因。候选进入事件与满 1 秒后的业务确认事件分别表示。已触发期间不逐帧重复发送确认事件。

12. 主要风险与处理

13. 实施与交付顺序

1. 评审本报告，确定技术验证范围和建议参数。
2. 实现摄像头、关键点和独立头眼动作显示，验证 H/E 可观测性。
3. 加入校准和区域估计，单独验证 G；不足时记录原因并优化。
4. 实现联合判定、人物占位图、状态机和日志，构建测试 APK。
5. 真机执行正负例测试，汇总实际表现和限制，再给出后续开发建议。

最终交付包括：需求报告定稿、测试 APK、源码与固定依赖版本、构建及安装说明、测试操作说明、实际测试记录、已知限制与接口说明。

报告、构建、安装和算法验收分别标注状态。APK 编译通过不能写成真机通过；真机流程正常不能写成眼动准确率达标。

14. 参考与当前产物状态

• MediaPipe 官方安卓示例：https://github.com/google-ai-edge/mediapipe-samples/tree/main/examples/face_landmarker/android
• Face Landmarker 安卓文档：https://ai.google.dev/edge/mediapipe/solutions/vision/face_landmarker/android
• Face Landmarker 输出说明：https://ai.google.dev/edge/mediapipe/solutions/vision/face_landmarker

人物素材：eye_tracking_placeholder_v1.png，1024 × 1536 像素，使用用户指定的 packy-image 技能及其脚本，通过 gpt-image-2 以 high 质量生成。已目视确认人物为完整着装、正面站立的全身示意形象，无文字或预绘制目标框。图像生成并不等于交互功能已实现。

生成原件保存在工作区 output/imagegen/eye_tracking_placeholder_v1.png；交付副本位于本报告同目录，文件内容一致。

当前：需求报告待评审；人物示意图已生成；APK、构建验证和真机测试均尚未完成。