ARKit的追踪能力依赖视觉惯性里程计（VIO），也就是把摄像头画面中的视觉信息和IMU运动数据融合起来估算设备姿态。但在实际项目中，追踪丢失的情况并不少见：用户快速甩动手机、走进昏暗的走廊、对着一面白墙，虚拟物体突然飘走或者直接消失，会话状态从.normal变成.notAvailable或.limited。要彻底解决这类问题，必须回到特征点提取和运动模糊这两个核心环节上去分析。
一、追踪丢失的根源：特征点为什么提不出来
ARKit在每一帧图像上做的事情，本质是检测图像中具有明显灰度变化的像素块，也就是所谓的特征点（Feature Point），再通过比对相邻帧之间特征点的位置变化推算相机的运动。这个过程对图像内容有两个硬性要求：一是画面中要有足够丰富的纹理，二是特征点在帧与帧之间要能稳定匹配。一面纯白的墙、一张空白的桌面、一块没有花纹的地板，在算法眼里就是一片均匀的灰度区域，根本提取不出可靠的特征点，追踪自然会退化到.insufficientFeatures状态。
第二个硬性要求常被开发者忽视，那就是特征点的空间分布。即使画面中有大量纹理，如果所有特征点都集中在一小块区域（比如画面中央放着一本花纹复杂的书，周围全是白墙），ARKit能算出的位姿估计的约束就不充分，姿态解算会变得病态。这也是为什么苹果官方建议用户移动设备来扫描环境，而不是保持静止——移动可以引入视差，让不同深度的表面产生不同的位移模式，从而帮助算法建立更稳健的三维约束。
第三个因素是环境光的稳定性。ARKit的特征检测对曝光突变很敏感，当用户从明亮的室外走进室内，自动曝光需要几百毫秒才能重新平衡，这段时间内图像要么过曝要么欠曝，灰度直方图被压缩到极端区间，特征点的响应值大幅下降。理解了这三点，就能明白后续所有的优化手段，本质上都是在帮算法拿到更高质量的输入图像。
二、运动模糊：特征匹配的头号杀手
运动模糊的成因可以用简单的物理模型解释：相机曝光期间，快门保持开启状态，如果这段时间内设备发生了位移，场景中一个点在传感器上留下的就不是一个像素而是一段轨迹。模糊核的长度约等于设备运动速度乘以曝光时间。也就是说，快速移动加长曝光等于灾难性的模糊，特征检测算子的响应会被模糊核稀释，原本尖锐的角点变成了模糊的 streak，匹配的描述子距离急剧增大，误匹配率飙升，最终表现为追踪漂移或直接丢失。
实际测试中可以发现一个量化规律：当图像中模糊轨迹超过三到四个像素时，ARKit的位姿估计误差会显著放大，同时帧间特征点匹配数量可能下降一半以上。而iPhone默认的自动曝光在光线一般的环境下，快门时间经常达到六十分之一秒甚至更长，用户快速转头时的角速度很容易超过每秒一百二十度，算下来单帧模糊量轻松超过十个像素。这就是为什么有些应用明明场景纹理很丰富，用户一甩手机追踪就断。
还有一点需要区分：运动模糊和失焦模糊是两回事。失焦是光学问题，由对焦距离错误引起，表现为整幅图像均匀模糊；运动模糊则具有方向性，且往往伴随IMU读数异常。排查时可以先看ARCamera.TrackingState的.excessiveMotion原因，它明确指向运动过快的问题，而.insufficientFeatures更多指向场景纹理不足或模糊导致特征提取失败。
三、工程实践：如何抑制模糊并提升特征提取质量
最直接有效的手段是控制曝光时间。ARKit从iOS 11.3开始提供了ARSession级别的相机曝光控制能力，你可以通过ARPhotoResolution相关的配置或者直接在 ARWorldTrackingConfiguration中结合videoFormat选择高帧率格式。帧率越高，单帧曝光时间上限越低，运动模糊自然越少。示例代码如下：
let configuration = ARWorldTrackingConfiguration()
// 优先选择1080p 60帧的格式，缩短单帧曝光时间
if let format = ARWorldTrackingConfiguration.supportedVideoFormats
.first(where: { $0.framesPerSecond == 60 }) {
configuration.videoFormat = format
}
// 限制曝光时长，防止暗光下自动曝光拉长快门
if let maxExposure = ARWorldTrackingConfiguration.supportedVideoFormats
.first(where: { $0.framesPerSecond == 60 })?
.captureDurationRange {
// 注意：不同版本API略有差异，核心思路是钳制曝光上限
print("支持的最大曝光时长: \(maxExposure)")
}
session.run(configuration, options: [.resetTracking, .removeExistingAnchors])
除了会话配置，渲染层面也可以做文章。很多应用的追踪丢失报告其实来自UI层面：虚拟物体因为位姿抖动看起来在漂移，用户主观判定为追踪坏了。可以在渲染锚点时加入轻量的平滑滤波，但要注意平滑只能掩盖抖动，不能修复真实的位姿误差，滤波强度过大会引入明显的延迟感，得不偿失。
针对暗光场景，一个实用技巧是在需要高精度追踪的环节（比如平面检测、图像识别触发）主动提示用户补光，或者利用UIScreen的亮度做短暂的手电筒式辅助。另外别忘了检查environmentTexturing和wantsHDREnvironmentTextures的配置，某些情况下关闭重型的环境光估计任务可以给追踪管线腾出算力，间接提升特征处理的实时性。
四、追踪丢失后的恢复策略
再好的抑制手段也无法保证百分之百不丢失，所以必须设计优雅的恢复流程。第一步是监听状态回调，及时向用户传达可操作的信息，而不是让画面卡死：
func session(_ session: ARSession, cameraDidChangeTrackingState camera: ARCamera) {
switch camera.trackingState {
case .notAvailable:
showHint("追踪不可用，请缓慢移动设备")
case .limited(.excessiveMotion):
showHint("移动太快了，请放慢速度")
case .limited(.insufficientFeatures):
showHint("请对准有纹理的表面，或打开灯光")
case .limited(.initializing):
showHint("正在初始化，请环顾四周")
default:
hideHint()
}
}
第二步是善用重定位机制。ARKit自带的世界追踪在短暂丢失后会尝试基于之前建立的地图特征重定位（Relocalization），前提是你开启了configuration.initialWorldMap的持久化加载。也就是说，在关键时刻保存ARWorldMap，追踪丢失后重新运行会话并加载之前的地图，设备回到相似位置时就能快速找回之前的坐标系，虚拟物体的锚点不会错乱。
第三步是锚点层面的兜底设计。不要把所有虚拟内容都挂在世界坐标原点上，而是为每个独立物体创建ARAnchor。追踪重置时，世界原点会变化，但锚点携带的语义信息（比如通过ARPlaneAnchor关联的平面）能帮助内容在重定位后回到合理位置。此外，结合ARSkeletonDefinition之外的场景理解能力，如地理位置锚点ARGeoAnchor，在户外场景中可以提供视觉追踪之外的第二重定位保障。
总结来看，解决ARKit追踪丢失是一个系统工程：理解特征点提取对纹理、分布和曝光的要求是前提，压缩运动模糊靠帧率与曝光控制，最后的体验保障则依赖状态反馈、世界地图持久化和锚点级别的容错设计。把这几层都做到位，追踪丢失带来的体验断裂就能被控制在用户几乎无感知的范围内。