移动端
手机是现存部署最广泛的SLAM平台:每一部现代iPhone和大多数Android设备都把视觉惯性跟踪作为一项系统服务在运行(ARKit和ARCore)。因此,做”移动端SLAM”实际上意味着两种不同的技能:使用原生应用语言调用平台自带的跟踪栈,以及——对于真正的SLAM工程师而言——让自定义的C++感知代码在手机硬件上高效运行。
Android(Java/Kotlin)。 应用程序用Kotlin(或Java)编写,但SLAM级别的代码通过NDK以C++运行,并通过JNI桥接。真正重要的平台组件包括:用于获取帧的Camera2/CameraX(带时间戳和曝光元数据)、用于IMU数据的传感器API,以及——如果你更愿意使用谷歌内置的运动跟踪而不是自己跑一套——ARCore。Android SLAM工作的实际情况包括:相机-IMU时间同步质量在不同设备之间差异巨大,以及热节流(thermal throttling)会重新定义”实时”的含义。
iOS(Objective-C/Swift)。 应用程序用Swift编写(遗留代码为Objective-C),C++可直接集成(通过Objective-C++或Swift的C++互操作)。AVFoundation提供相机帧,CoreMotion提供IMU数据,而ARKit则暴露出苹果高度集成的VIO——得益于出厂校准、同步良好的相机-IMU硬件,它被普遍视为消费级跟踪质量的标杆。Metal和CoreML/ANE负责GPU计算和学习型组件的神经网络推理。
传感器管线:移动端VIO成败的关键所在
- 时钟域。 相机和IMU的时间戳必须处于同一时钟基准上。在Android上,
SENSOR_INFO_TIMESTAMP_SOURCE会告诉你相机时间戳是否与IMU共享同一时钟基准(REALTIME),还是各自独立(UNKNOWN)——在后一种情况下,你必须自己估计偏移量,而且要针对每台设备分别估计。 - 卷帘快门(Rolling shutter)。 几乎所有手机相机都是逐行读出的,因此图像的每一行都是在稍有不同的时刻采集的;在快速运动时这会使几何结构发生畸变,必须建模(或者接受它作为一种误差来源)。平台自带的跟踪器会在内部处理这一问题——自定义流水线也必须做到。
- OIS/EIS。 光学防抖(OIS)会物理移动镜头,悄悄改变每帧的有效内参;电子防抖(EIS)则会对图像本身进行畸变。两者对拍视频都很好,但对几何计算都很不友好——做SLAM时应关闭它们,或对其影响进行建模。
- 曝光元数据。 自动曝光会使图像逐帧改变亮度;直接法/光度法需要Camera2/AVFoundation提供的曝光时间和ISO值。
工程清单
对SLAM工程师而言,移动端专属的检查清单在两个平台上大同小异:
- 传感器访问与同步——相机和IMU的硬件时间戳、卷帘快门的感知处理、曝光/ISO元数据(如上所述)。
- 计算预算——少数几个CPU核心(与应用共享)、NEON SIMD、移动端GPU,以及NPU;功耗和散热限制会把持续负载压到远低于峰值的水平,所以要在”发热状态”下做基准测试,而不是”冷启动”状态。
- 语言桥接——Kotlin/Swift界面层之下运行共享的C++核心,这是跨平台SLAM产品的标准架构。
- 使用还是自建——ARKit/ARCore既优秀又免费;当你需要它们未暴露的能力时(自定义传感器、自己拥有的地图、跨设备重定位),自建定制SLAM才有意义。
持久化与共享体验
这些平台栈还暴露出一些地图层面的功能,其底层本质就是SLAM:ARKit可以序列化它的地图(ARWorldMap),让应用保存一次会话并在之后重定位进去;而ARCore的Cloud Anchors则让多台设备解析同一个锚点——把跨设备重定位当作一项服务提供出来。了解这些功能在内部做了什么(地点识别、地图合并、重定位),能让你确切知道何时可以依赖它们、何时需要自己的地图层。
对SLAM的意义
移动端AR是视觉惯性SLAM实现大规模部署的地方,手机的各种限制(紧张的功耗预算、卷帘快门相机、消费级IMU)塑造了这一领域的工程优先级。无论你是在ARKit/ARCore之上构建应用,还是想与它们竞争,理解移动端技术栈——传感器管线、原生/托管语言桥接,以及受热量限制的实时性——对于把SLAM交付到这个最大的平台上都是必不可少的。