Foot Tracking是ARCore在Body Tracking体系下延伸出的能力，核心目标是让手机在俯视视角下实时识别画面中的脚部区域，输出脚部的位置、朝向等姿态数据。与常见的平面检测、面部追踪相比，足部追踪对环境的要求更为苛刻，很多开发者在自己的测试机上跑官方Sample效果很好，一换到真实使用场景就出现识别丢失、位置漂移的问题。这篇文章围绕如何在Android端系统地测试足部追踪功能展开，从环境准备到代码验证，再到指标评估，给出一套可以直接落地的测试方案。
一、测试前的环境与设备准备
足部追踪的效果高度依赖环境条件，因此测试的第一步不是写代码，而是把环境变量固定下来，否则每次测试结果都没有可比性。建议准备至少三种典型的测试环境：第一种是光照均匀的室内环境，比如铺木地板的客厅，光照强度在300到500勒克斯之间；第二种是低光照环境，可以用窗帘遮挡模拟，光照低于100勒克斯；第三种是复杂地面环境，比如带花纹的地毯或反光的大理石地面，用来验证算法在弱纹理或强反光条件下的鲁棒性。
设备方面需要注意几点。首先确认设备在ARCore的官方支持列表中，并且ARCore APK版本足够新，足部追踪依赖较新的运行时版本，旧版本Runtime根本不会下发相关能力。其次，手机摄像头建议保持与地面约1米到1.5米的距离，俯视角度控制在30度到60度之间，太陡或太平的拍摄角度都会显著降低识别率。测试人员最好准备两双不同颜色的鞋子，一双深色一双浅色，因为深色鞋在深色地板上经常出现识别失败的情况，这是实际项目里反馈非常集中的问题。
可以在应用启动时主动检查当前会话是否支持足部追踪能力，避免在不支持的设备上直接崩溃：
// 检查当前ARCore会话是否支持足部追踪
ArCoreApk.Availability availability = ArCoreApk.getInstance().checkAvailability(this);
if (availability.isSupported()) {
Session session = new Session(this);
Config config = session.getConfig();
// 查询Foot Tracking相关能力是否可用
// 具体API以当前ARCore SDK版本为准
Log.d("FootTracking", "设备支持，ARCore版本: " + session.getSupportedFeatures());
} else {
Log.w("FootTracking", "当前设备不支持ARCore");
}
二、API接入与数据获取验证
环境准备好之后，第二步是验证数据链路是否通畅。足部追踪的输出通常包含脚部的空间坐标、朝向角度以及一个置信度字段。测试时要重点观察置信度数据，它直接反映了当前帧的识别质量。建议在调试阶段把置信度实时打印到屏幕上，同时把脚部识别框叠加在相机预览画面上，这样可以直观地看到识别框与实际脚部位置是否吻合。
数据获取的典型流程是：每一帧更新时从追踪结果列表中取出左右脚的状态对象，读取其位姿并转换为世界坐标。下面这段代码演示了如何在每一帧中获取并记录足部追踪数据，用于后续分析：
private void updateFootTracking(Frame frame) {
// 获取当前帧的足部追踪结果（API名称以所用SDK版本为准）
List<FootTrackingResult> results = frame.getFootTrackingResults();
for (FootTrackingResult result : results) {
if (result.getTrackingState() == TrackingState.TRACKING) {
Pose footPose = result.getFootPose();
float[] translation = footPose.getTranslation();
float[] rotation = footPose.getRotationQuaternion();
// 将数据写入日志文件，供离线分析使用
logWriter.write(String.format(Locale.US,
"t=%.3f,x=%.4f,y=%.4f,z=%.4f,conf=%.2f",
frame.getTimestamp() / 1e9,
translation[0], translation[1], translation[2],
result.getConfidence()));
}
}
}
这里有一个容易被忽视的细节：帧回调里不要做任何耗时操作。有些开发者习惯在回调里直接写文件或者做坐标换算，结果主线程掉帧严重，反而导致追踪丢失。正确做法是把数据先塞进内存队列，由独立线程异步落盘。另外，坐标系的换算一定要确认清楚，足部输出的坐标是在世界坐标系还是相机坐标系下，搞混了会导致后续所有指标计算全部失真。
三、测试用例设计与量化指标
有了数据记录能力，接下来要设计一套可量化对比的测试用例。单靠肉眼观察识别框是否贴合脚部，只能给出很粗略的结论，无法支撑发布决策。推荐以下几个核心指标：识别成功率，即在N次测试中成功建立追踪的比例；位置误差，即输出坐标与人工测量真实坐标的偏差，单位为厘米；追踪连续性，用连续追踪时长和丢失后恢复时间来衡量；帧率稳定性，即开启足部追踪后渲染帧率是否保持在目标值以上。
设计用例时建议覆盖以下场景：静止站立、原地踏步、缓慢行走、快速走动、转身以及穿脱鞋子。每个场景至少重复执行10次，每次持续30秒，把数据汇总后计算均值和标准差。下面是一个简单的用例执行记录表结构，可以直接用表格形式整理：
| 测试场景 | 执行次数 | 识别成功率 | 平均位置误差 | 丢失恢复时间 |
|---|---|---|---|---|
| 静止站立 | 10 | 100% | 2.1cm | 无丢失 |
| 缓慢行走 | 10 | 95% | 3.4cm | 1.2s |
| 快速走动 | 10 | 82% | 5.8cm | 2.8s |
| 深色鞋深色地面 | 10 | 71% | 4.2cm | 3.5s |
从上表这类数据中很容易发现规律：运动速度和颜色对比度是影响识别的两个最主要因素。如果快速走动场景的成功率明显偏低，通常说明算法对运动模糊敏感，产品层面就需要考虑降低对快速移动的依赖，或者在丢失时提供友好的提示引导用户放慢动作。位置误差方面，一般AR应用能接受的平均误差在5厘米以内，试鞋类应用因为要贴合鞋模，建议控制在3厘米以内。
四、常见问题排查与调优建议
测试过程中最常见的问题有三类。第一类是完全无法识别，多数情况是设备或ARCore版本不支持，或者是俯视角度太极端，解决方案是先做能力检查，再引导用户调整持机姿势，可以在界面上画一个角度指示器帮助用户对准。第二类是识别后频繁丢失，这通常和光照变化、地面弱纹理有关，可以让用户先缓慢移动手机让ARCore充分建立环境特征，再开始正式追踪。
第三类是位置漂移，即追踪不丢失但输出坐标逐渐偏离真实位置。排查这类问题需要结合IMU数据和视觉特征点数量来分析，如果特征点数量持续偏低，说明环境纹理不足；如果特征点正常但漂移仍在，则可能与快速转身导致的视觉里程计误差累积有关。可以在日志中额外记录每帧的地图点数量，方便定位原因。
调优层面还有两个实用技巧。一是做时序平滑，对输出的脚部位姿做低通滤波，能有效抑制抖动，但滤波强度不能太大，否则会引入明显延迟，试鞋场景下延迟超过100毫秒用户就能明显感知。二是做丢失预测，当置信度连续多帧下降时提前提示用户放慢动作，比丢失后再重新识别的用户体验好得多。最后建议在CI流程中加入自动化的回归测试，用录制的相机流反复回放验证识别成功率，这样每次SDK升级后都能快速确认功能没有劣化。
Foot TrackingAndroid足部追踪ARCore修改时间：2026-09-06 04:02:44