AR 开发为什么这么痛苦?

每次改完代码,只能推到真机才能跑。那些真正有趣的状态——追踪突然丢失、一个平面合并到另一个里、参考图刚进入视场——全是你无法按需复现的。每轮调试都得站起来,举着手机对准自家地板。如果还要同时搞定两套完全不同的平台 SDK,简单点的想法都能拖成一周的焦油坑。

打开网易新闻 查看精彩图片

Codename One 团队显然也受不了这种折磨。最新的 PR #5335 引入了两个核心包:com.codename1.arcom.codename1.vr,用一套便携式 API 把 ARKit、ARCore、立体渲染和 360 媒体全包了——而且内置一个模拟 AR 后端,让你坐着就能把整个交互流程调通

具体怎么把 AR 开发的死循环打碎,可以拆成这几个要害:

  1. 真·跨平台 API
    同一段 Java 代码,在 iOS 上驱动 ARKit,在 Android 上驱动 ARCore。你只管 AR.isSupported() 检查能力,开一个 ARSession,拿到 ARView,然后世界追踪、水平/垂直平面检测、命中测试、锚点、光照估计、图像追踪、脸部追踪全有了。用户点击屏幕放置一个 glTF 模型,只要十几行逻辑,两侧行为完全相同。底下 iOS 是通过 SceneKit 复合 ARKit 会话,Android 跑的是类型化的 ARCore 代码,但你的代码里看不见任何平台原生类型。
  2. 坐着就能复现的调试环境
    框架的模拟后端可以重现任意的追踪状态:平面突然合并、参考图进入视野、光照剧烈变化……再也不用被真机绑在现实世界。你只需要坐下来,用模拟环境走完整个循环。
  3. 模型解析与后端彻底解耦
    glTF 模型在框架层用设备无关的加载器解析,交付给后端的是原始几何体缓冲区。这意味着你在 iOS 端永远不用直接操作 SceneKit 的那些类,未来 iOS 后端迁移到 RealityKit,你的业务代码一行都不用改。
  4. 事件模型没坑
    所有监听器都在 EDT 触发,锚点更新、平面扩展、相机姿态、光照估计这些高频数据被合并发送,所以 EDT 看到的始终是最新状态,不会被积压回调拖死。你写的仍然是普通的 Codename One 事件驱动代码。

同一个周内,VR 包补上了立体渲染和 360 媒体的 GPU 管线。两个功能叠加在一起,意味着用单一 Java 代码库,你不仅能做个跨平台的 AR 应用,还能顺带把 VR 场景给通了。对在移动端被 AR 内循环折磨太久的开发者来说,这大概不只是一次发布,而是一种解脱。