ARWorldMap中ARAnchor数量是否存在上限及最佳实践

关于ARAnchor的数量限制说明 #

苹果官方从未公开ARAnchor的硬编码数量上限，15个手动添加的自定义锚点属于极低负载量级，哪怕叠加系统自动生成的平面锚点，总锚点数也远达不到会触发系统框架报错的阈值，你遇到的断言报错和锚点总数量没有直接关联。

你贴出的日志中Assert: in line 659是ARKit内部空间索引模块的线程/数据一致性断言，dyld4相关日志是Xcode调试时注入的调试库加载信息，不是崩溃根因。

该断言报错的常见触发原因 #

• 锚点操作线程违规：所有ARAnchor的增、删、改操作必须在主线程执行，如果在后台线程（包括ARSessionDelegate的异步回调线程、渲染子线程、世界地图序列化的工作线程）直接调用session.add(anchor:)、session.remove(anchor:)，或者直接修改已添加锚点的transform属性，会触发内部线程安全断言，这是该报错最高发的诱因。
• ARWorldMap操作时序错误：调用session.getCurrentWorldMap获取世界地图的过程中，ARKit会短暂锁定空间索引数据，如果此时重复添加新锚点、修改已有锚点数据，会破坏数据一致性触发断言。
• 非法锚点数据：如果给锚点设置的transform矩阵包含NaN、无穷大值，或者自定义锚点继承ARAnchor时复写属性逻辑不规范，会触发内部参数合法性校验断言。
• 调试库兼容问题：日志中显示注入了libBacktraceRecording、libMainThreadChecker、libMTLCapture等Xcode调试库，部分Xcode版本下这些调试库和ARKit世界追踪模块存在兼容问题，会打印无实际业务影响的假断言，切Release模式运行报错消失即可判定为该类问题。
• 冗余锚点溢出：如果没有处理系统ARPlaneAnchor的合并逻辑，大量重复、过期的平面锚点堆积，叠加手动锚点可能导致空间索引节点溢出，但该场景一般需要总锚点数超过200才会触发，15个手动锚点的量级基本不会出现这类问题。

ARWorldMap场景下的锚点开发最佳实践 #

• 严格遵守线程规则：所有锚点相关操作强制调度到主线程执行，可以在锚点操作逻辑前加assert(Thread.isMainThread)提前拦截线程违规问题。
• 不要持久化系统生成锚点：ARPlaneAnchor、ARFaceAnchor这类系统自动生成的锚点不要存入ARWorldMap的自定义序列化字段，每次加载世界地图后重新开启对应检测让系统重新生成即可，避免历史过期锚点和新检测锚点重复占用资源。
• 规范世界地图操作时序：调用getCurrentWorldMap获取世界地图的过程中，临时阻塞所有锚点增删改操作，等异步回调完成拿到世界地图实例后再恢复操作。
• 按需加载锚点：手动添加的业务锚点如果距离当前相机位置超过10米、且不在当前可视范围内，可以临时从session中移除，等用户靠近对应区域时再重新添加，正常负载下单session内同时存在的锚点控制在100以内不会有任何性能问题，超过200建议做空间分块加载。
• 及时清理冗余锚点：监听系统平面合并回调，在多个ARPlaneAnchor合并为新平面时，及时清理掉被合并的旧平面对应关联的冗余手动锚点，避免空间内重复锚点堆积。

快速排查步骤 #

1. 全局检索所有锚点增删改调用位置，确认所有逻辑均在主线程执行。
2. 关闭Xcode的主线程检查、Metal捕获、回溯记录等调试功能，切Release模式运行，确认是否为调试库兼容导致的假报错。
3. 临时关闭平面检测，仅保留手动添加的15个自定义锚点运行，若报错消失则是平面锚点更新逻辑和自定义锚点存在冲突，若仍复现则检查自定义锚点的transform参数合法性、锚点类的实现逻辑。
4. 排查getCurrentWorldMap相关逻辑，确认获取世界地图的过程中没有执行锚点操作。

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