空间锚点与跨会话持久化

1. 锚点有生命周期
   创建 → 被追踪 → 可能失效 → 可重新定位 → 销毁

2. 锚点的位姿会变
   追踪系统优化后可能微调锚点位置（尤其刚创建时）

3. 锚点的价值在于「稳定」
   用户看到的是内容不动，而实现上锚点一直在被修正

会话 A：原点在用户启动时的位置，Y 轴靠重力，Yaw 随机
会话 B：原点位置不同，Yaw 也不同

结论：
  世界坐标 (1, 0, 2) 在会话 A 和会话 B 指向完全不同的地方
  想跨会话复用位置，必须依赖「可识别的空间特征」

// 1. 会话内锚点
val anchor = hitResult.createAnchor()
val pose = anchor.pose          // 每帧更新

// 2. 本地持久锚点（Cloud Anchor 的本地版）
// 通过 Anchor 的 persist 能力保存到本地数据集

// 3. 云锚点（Cloud Anchors）
val cloudAnchor = session.hostCloudAnchor(anchor)   // 上传
// 或
val resolved = session.resolveCloudAnchor(cloudAnchorId)  // 解析

云锚点的工作流：
  设备 A：射线放置 → 创建锚点 → hostCloudAnchor → 得到 cloudAnchorId
  云端：保存特征描述子
  设备 B：拿到 cloudAnchorId → resolveCloudAnchor → 得到本地锚点位姿

1. 上传前多角度观察
   hostCloudAnchor 前让设备围绕目标区域缓慢移动 3~5 秒，
   采集更多视角特征，解析时匹配更稳。

2. 多锚点投票
   在同一空间布置 3~5 个云锚点，解析后取位姿平均，
   单点误差可下降约一半。

3. 选择特征丰富的锚点位置
   纯色墙面、玻璃、反光地面的特征少，应选择有纹理的位置。

4. 解析后本地微调
   用当前会话的平面检测结果做一次对齐校正，
   把云锚点的位姿吸附到本地平面。

// 保存世界地图
session.getCurrentWorldMap { worldMap, error in
    guard let map = worldMap else { return }
    let data = try! NSKeyedArchiver.archivedData(
        withRootObject: map, requiringSecureCoding: true)
    try! data.write(to: mapURL)
}

// 加载并重定位
let map = try! NSKeyedUnarchiver.unarchivedObject(
    ofClass: ARWorldMap.self, from: data)!
let config = ARWorldTrackingConfiguration()
config.initialWorldMap = map
session.run(config)   // 进入 .relocalizing 状态

ARKit 重定位状态机：
  .initializing  → 初始化，提示用户移动设备
  .relocalizing → 正在匹配地图，提示回到原位置
  .normal       → 正常，锚点已恢复
  .limited(...)  → 降级，原因细分（特征不足/运动过快等）

单设备、单平台       → 本地持久锚点，最省事
单平台、跨设备       → 云锚点（ARCore）或世界地图（ARKit）
跨平台、跨设备       → ASA 或图像标记
需要高精度对齐       → 图像标记或二维码

// 保存
data class AnchorRecord(
    val anchorId: String,
    val contentType: String,
    val payloadJson: String,
    val createdAt: Long
)
// 存入本地数据库（Room / SQLite）

// 恢复：从数据集解析锚点
val ids = loadAnchorIds()
val anchors = ids.mapNotNull { id ->
    session.resolveAnchor(id)?.let { anchor -> anchor to id }
}

1. 特征提取：从当前帧提取特征点与描述子
2. 候选检索：从地图中检索可能匹配的关键帧（词袋 / 全局描述子）
3. 匹配与几何验证：2D-3D 匹配 + RANSAC 求位姿
4. 位姿图优化：把新位姿接入地图，修正漂移

成功条件：
  视角与建图时有重叠（至少 30% 可见区域重叠）
  光照条件相近（特征描述子对光照敏感）
  场景未发生大变化（家具没搬动）

1. 场景是否变化？     家具搬动、装修、季节变化（窗帘开合）
2. 光照是否差异大？   白天/夜晚、开灯/关灯，特征描述子会失配
3. 视角是否重叠？     用户是否在原来的位置与朝向上
4. 地图质量如何？     建图时是否走过足够的区域与角度
5. 设备是否更换？     不同相机标定导致特征尺度差异
6. 版本是否一致？     地图格式在系统升级后可能不兼容

锚点状态机：
  TRACKING  → 正常，位姿可用
  PAUSED    → 暂时不可用，保留位姿
  STOPPED   → 永久失效，应清理

处理原则：
  PAUSED 时内容保持在最后已知位姿（不要让内容消失）
  STOPPED 时给用户明确提示，并提供重新放置入口

方案对比：
  共享云锚点     → 所有人解析同一云锚点，得到同一坐标系
  共享世界地图   → 传地图文件，精度高但需分发
  图像标记对齐   → 所有人扫同一张图，最可靠
  手动对齐       → 用户手动调整，体验差

漂移估算示例：
  用户走过 20 米，按 1% 漂移计 → 位置误差 20 cm
  这个误差在「把海报贴在墙上」场景可接受
  在「把零件对齐到螺丝孔」场景完全不可接受

本地存储：
  锚点记录        ~200 B / 条
  世界地图        ~5~50 MB / 张（取决于空间大小）
  建议上限        : 单设备 20 张地图，超出提示清理

云锚点配额（ARCore）：
  每日上传次数    有上限（按项目配额）
  每日解析次数    有上限
  超出后          API 直接报错，必须处理

假设：1000 个用户，每人每天放置 2 个锚点，平均每天打开 1 次

云锚点上传：1000 × 2 = 2000 次/天
云锚点解析：1000 × 2 × 1 = 2000 次/天（若每次启动都解析）

若配额为每日 3000 次解析：
  剩余余量只有 1000 次
  用户多次打开应用就会耗尽配额

对策：
  首次解析成功后本地缓存位姿，后续启动直接使用缓存
  仅在缓存过期（如超过 7 天）或用户主动刷新时才重新解析

数据模型：
  anchor_id      : 平台返回的锚点标识
  content_type   : 内容类型（模型/视频/文本）
  payload        : 内容参数（JSON）
  created_at     : 创建时间
  last_seen_at   : 最近成功解析时间
  schema_version : 数据格式版本

流程：
  1. 启动 → 加载锚点列表 → 逐个解析
  2. 解析成功 → 恢复内容，更新 last_seen_at
  3. 解析失败 → 标记失败次数，超过 N 次则归档
  4. 用户放置 → 创建锚点 → 持久化 → 上传云（如需要）
  5. 退出 → 释放会话，但不清除持久化数据

兜底：
  全部解析失败 → 提示「空间已变化，请重新放置」
  部分失败     → 静默跳过，只恢复成功的