AR Core Persistent Cloud Anchors永久保留锚点实现方案咨询

两种方案的可行性结论 #

• 锚点到期后续期365天的方案：完全可行，是官方推荐的最优实现方案，不会引入位姿偏差，维护成本低
• 迭代复制旧锚点生成新锚点的方案：仅可作为应急兜底方案，长期使用会出现误差累积导致锚点漂移，不建议作为主方案

方案1：锚点到期自动续期 具体实现 #

• 锚点创建时的基础数据落库
  创建云锚点拿到服务端返回的锚点ID后，立刻把锚点ID、创建时间、到期时间（创建时间+365天）、绑定的AR内容信息、所属场景信息存入自有业务数据库，不要仅依赖AR SDK侧的锚点存储。
• 配置定时巡检续期逻辑
  写定时任务按天扫描全量生效中的锚点，筛选出距离到期时间不足7天的锚点，批量调用AR SDK提供的锚点TTL更新接口，将锚点的剩余有效期重置为365天（对应秒值31536000）。续期接口调用成功后，同步更新本地数据库存储的锚点到期时间字段。
• 异常兜底处理
  如果续期接口调用失败，按指数退避策略重试3次，重试间隔分别为1分钟、10分钟、1小时，三次重试全部失败则推送告警给运维人员，避免锚点静默过期。

注：目前主流云锚点服务（ARCore Cloud Anchor、ARKit 云锚点、主流第三方空间锚点SDK）的续期接口不需要重新采集空间特征，续期后锚点位姿和原锚点完全一致，不会出现位置偏移。

方案2：迭代复制锚点 具体实现（仅应急使用） #

该方案每次生成新锚点都依赖设备识别旧锚点的实时位姿计算结果，单次复制会存在1~5厘米的随机误差，迭代复制超过10次后误差会累积到米级，导致AR内容位置完全偏离，仅适合续期接口临时故障时的应急兜底，具体实现步骤：

• 定时巡检发现锚点续期失败时，将待复制的旧锚点ID标记为待迁移状态，推送给对应场景的现场运营人员
• 运营人员持设备到现场，识别到即将过期的旧锚点后，在和旧锚点位姿完全重合的位置创建新的云锚点，将新锚点TTL设置为365天（对应秒值31536000）
• 新锚点云端校验生效后，把业务侧绑定在旧锚点上的所有AR内容、交互逻辑全部关联到新锚点ID，旧锚点标记为待失效
• 旧锚点超过有效期自然失效后，从业务数据库中清理旧锚点的冗余记录

补充实践建议 #

针对固定线下场景（比如固定展馆、商圈AR导览点位），可以在首次创建锚点时，把锚点对应的空间特征点云数据备份到自有存储，就算云侧锚点意外过期，也可以直接基于本地备份的特征数据重新创建锚点，不需要运营人员到现场重新采集点位。

内容的提问来源于stack exchange，提问作者JIMIN