Google 的 Android XR 平台，VR 开发的新机会

Google 的 Android XR 平台，VR 开发的新机会

Google 在 2024 年 12 月正式发布 Android XR 的时候，我第一反应不是兴奋，而是去翻了翻抽屉底下那个积灰的 Daydream View 盒子。那玩意当年也是顶着"Android 官方 VR 平台"的名头出场的，结果不到三年就进了谷歌的产品坟场，连墓碑都懒得立。所以这回看到 Sundar Pichai 和三星移动部门总裁卢泰文同台宣布 Android XR，我心里只有一个念头：Google，你最好是认真的。

Daydream 的坟头草已经三米高了

要聊 Android XR，不提 Daydream 就是耍流氓。2016 年 Google 推出 Daydream 平台的时候，阵仗比如今还大。Pixel 手机、Daydream View 那个像是个大号眼罩的盒子、还有一票内容合作伙伴，甚至连 HBO、纽约时报都做了应用。那时候的开发文档写得天花乱坠，要求手机必须满足 Daydream Ready 标准——得有特定刷新率的屏幕、低于 3 毫秒的 motion-to-photon 延迟、还有专门的传感器。听起来很专业，对吧？

结果呢？用户体验是一场灾难。你把手机插进一个纸板加尼龙的盒子里，看二十分钟视频就头晕脑胀。更离谱的是交互，那个只有一个触摸板的遥控器，在 3D 空间里操作起来就像在黑暗中拿筷子夹玻璃球。开发者更惨，写了个 Daydream 应用发现用户基数还不如智能手表应用多。2019 年 Google 宣布停止支持 Daydream，Daydream View 从 Google Store 下架，Daydream VR SDK 也不再更新。 ashes to ashes，dust to dust。

这还不是全部。Google Glass 从 Explorer Edition 到 Enterprise Edition 的折腾、Tango 项目被 ARCore 取代、ARCore 本身也是不温不火——Google 在 XR 领域的信用记录，比某些 P2P 平台的兑付记录还要差。所以当一个有十年 Android 开发经验的老兵看到 Android XR 的新闻时，本能反应是怀疑：这次会不会又是另一个"试点项目"？三年之后会不会又是一封感谢信"我们决定停止服务"？

这一次，Google 终于不打算用手机凑数了

不过仔细看了技术细节之后，我得承认，Android XR 和 Daydream 至少在一个根本点上完全不同：它不再把手机当成计算核心。

Daydream 失败的核心原因之一，是它寄生在智能手机上。手机要散热、要省电、要接打电话，根本不可能持续输出高质量的 VR 体验。而 Android XR 从设计之初就是为独立头显（standalone headset）准备的。三星那个代号 Project Moohan 的头显，用的是高通骁龙 XR2+ Gen 2 平台，有独立的电池、独立的散热、独立的眼动追踪和手势追踪传感器。这才是正经做 XR 的硬件基底，而不是拿手机凑合。

更重要的是，Android XR 不是从 0 开始写的新系统。它基于 Android 14（API 34），本质上是一个加了空间计算能力的 Android 发行版。这意味着现有的 Android 应用不需要重写就能在上面跑，Google Play 商店直接平移。对于开发者来说，这降低了试错成本；对于 Google 来说，这是它最大的筹码——Meta Quest 再厉害，它的内容生态也是从 0 攒起来的，而 Google 背后有整个 Android 应用库。

但这里有个微妙的变化。Google 以前做 XR 总想"颠覆"什么，这次倒是务实了不少。Android XR 没有发明新的编程语言，没有搞一套全新的 UI 框架，而是把 Jetpack Compose 扩展到了三维空间。Jetpack XR SDK 里的 Spatial Compose 允许你用熟悉的 Kotlin DSL 去定义 3D 面板、空间容器和体积内容。对 Android 开发者来说，这确实比去学 Unity 的 C# 或者 Unreal 的蓝图要亲切得多。

兼容旧应用，是桥梁也是断头台

Android XR 最被宣传的特性之一，是"现有 Android 应用可直接运行"。官方演示里，你在头显里打开一个普通手机应用，它会自动以一个"空间面板"（Spatial Panel）的形式悬浮在眼前，你可以用眼球注视加捏合手势来点击按钮。听起来很美好，实际上这是个充满陷阱的设计。

我专门下载了 Android XR 模拟器和 Jetpack XR SDK 预览版试了一下。把一个普通的 Jetpack Compose 应用打包上去，确实能跑。但问题是，一个在 6 英寸屏幕上设计的手指触控界面，被投射到 3 米外的一个虚拟大屏幕上，交互逻辑完全不对。按钮太大或太小、文字在头显分辨率下要么模糊要么锯齿、滚动操作从手指滑动变成手势捏合，体验极其割裂。

Meta Quest 上早就有了类似的 2D Android 应用兼容层，Quest Store 里那些直接从手机端平移过来的应用，评分通常都很难看。用户会骂："这什么垃圾体验，我还不如拿手机看。" Android XR 如果不对旧应用的交互做强制适配要求，很快就会变成一个充满电子垃圾的仓库。但反过来，如果 Google 要求开发者必须做空间化适配才能上架，那又违背了"零成本迁移"的承诺，回到了 Daydream 时代"没人来开发"的死胡同。

更深层的问题在于输入范式。手机是单点触控，XR 是眼动+手势+语音的多模态输入。Android XR 的 Input SDK 虽然提供了统一的输入映射，但把一个为拇指设计的底部导航栏，搬到需要抬手捏合操作的 3D 空间里，本质上是在把方钉子敲进圆孔。我敢说，未来两年里，绝大多数"移植"到 Android XR 的应用都会是这种半成品状态。

Jetpack Compose for XR：方便，但不够

Google 这次押宝在 Jetpack Compose 上，意图很明显：他们想复制 Android 手机端的成功路径。当年从 View 系统迁移到 Compose 虽然痛苦，但一旦迁移完成，开发效率确实提升了一个量级。现在他们希望开发者用同一套逻辑，只是多 import 几个 androidx.xr 的包，就能做出空间应用。

现实没那么浪漫。Spatial Compose 确实提供了 Subspace、SpatialPanel、Orbiter 等高级组件，让你能用声明式 UI 的方式摆放 3D 元素。但 3D 开发的核心难点从来不在 UI 布局，而在空间感知、性能优化和物理交互。当你在 Compose 里放一个 3D 模型，背后调用的还是 OpenGL ES 或者 Vulkan，帧率能不能稳住 72fps？眼动追踪的注视点渲染（foveated rendering）怎么和 Compose 的渲染管线配合？空间音频的声源定位和头部传递函数（HRTF）怎么处理？这些都不是加一个 @Composable 注解就能解决的。

另外，工具链还是半成品。Android Studio 的 XR 设备模拟器目前只能模拟很基础的空间环境，眼动追踪用手势模拟，延迟和真实设备天差地别。想真机调试？等三星的 Project Moohan 正式发售吧，而且预计价格不会低于 500 美元。对于中小开发者来说，这又是一笔不小的投入。相比之下，Meta Quest 2 早就降到了 200 美元档，Quest 3 虽然贵一些，但生态已经成熟。Android XR 在 2025 年才发售硬件，这空窗期怎么过？

Meta 不会把蛋糕分给你

说到 Meta，这是 Android XR 绕不过去的对手。Quest 系列本质上也是运行着一套深度修改的 Android 系统（基于 AOSP），Meta 在上面盖了 Horizon OS 的房子。2024 年 4 月，Meta 突然宣布把 Horizon OS 开放给第三方硬件厂商，联想、华硕都签了约，摆明了要在 Google 反应过来之前，把"Android 版 VR 生态"的旗号抢到自己手里。

Google 现在推 Android XR，很大程度上是在夺回话语权。因为如果 Meta 的 Horizon OS 先一步成为事实标准，Google 就会像在智能手机时代面对 iOS 那样，再次陷入被动。Android XR 的核心卖点，说到底还是 GMS（Google Mobile Services）和 Google Play。你想在头显里看 YouTube、用 Google Maps 的沉浸式视图、同步 Google Photos？这些是 Meta Horizon OS 给不了或者给得很差的服务。

但问题在于，开发者到底跟谁走？目前全球 Quest 的存量设备超过两千万台，Horizon OS 的开发者社区已经运转了好几年。Android XR 的硬件要到 2025 年底才可能铺货，软件生态从 0 开始。除非 Google 能像当年补贴 Android 手机厂商那样，给 XR 开发者实打实的流量扶持和收入分成，否则大部分人还是会选择"先给 Quest 做，Android XR 等等看"。

更何况，Meta 在 XR 领域的投入是真金白银的亏钱补贴。Quest 硬件常年贴着成本甚至亏本卖，就为了换市场份额。Google 和三星的联盟会不会采取同样的激进策略？我高度怀疑。三星的硬件向来不便宜，Project Moohan 定位看起来就是高端路线，而高端头显的市场容量，看看 Apple Vision Pro 的销量就知道了——技术惊艳，但撑不起生态。

眼动追踪和手势，不是交互的银弹

Android XR 强调的另一个卖点是原生支持眼动追踪和手势识别，不需要手柄。Project Moohan 上有朝外的摄像头做手部骨骼追踪，有内向摄像头做眼球追踪。Google 把这称为"直觉式交互"，但我对这种纯手势+眼动的交互范式持保留态度。

实际用过 Vision Pro 的开发者都知道，纯手势交互在精确操作时极其折磨。捏合选择一个小按钮，误触率高得惊人；长时间抬手操作，手臂酸痛（gorilla arm 问题）比鼠标手还严重。眼动追踪作为指针很快，但作为"确认"输入就很容易造成米达斯触控问题（Midas Touch problem）——你看哪里就触发哪里，系统怎么知道你是"想看"还是"想点"？

Android XR 的 Input SDK 提供了组合输入逻辑，比如"注视+捏合"、"注视+语音确认"，但这需要开发者重新设计整个交互流。对于习惯了触摸屏逻辑的移动应用开发者，这几乎是要求他们重做 UX。而目前 Jetpack XR 的文档和示例代码里，关于复杂交互的最佳实践还非常少。Google 给你画了饼，但和面揉面的活还得你自己干。

开发者到底要不要现在入场？

说了这么多，回到最实际的问题：作为一个 Android 开发者，现在是不是该去学 Jetpack XR SDK，准备抢占"第一波红利"？

我的观点是：关注，但别 all in。

如果你本身就在做 AR/VR 相关的应用，或者你的应用天然适合空间计算（比如室内设计、教育培训、沉浸式视频），那现在确实可以开始研究 Jetpack XR SDK 的预览版了。至少把现有的 Android 应用跑在模拟器上看看效果，评估一下空间化改造的工程量。这个学习成本不高，而且早期入驻的开发者确实能在 Google Play 的新平台推荐位里获得一些曝光。

但如果你只是一个普通的移动端开发者，听到"新机会"就想冲进去，我建议冷静。Android XR 的首发设备要 2025 年才上市，而且大概率只有三星一家。硬件销量未知、用户付费意愿未知、广告变现模式未知。Google 在 XR 领域有反复横跳的黑历史，万一两年后项目又被砍，你花半年学的 Spatial Compose 和 OpenXR 封装细节全打水漂。

更务实的做法是，先确保你的 Android 应用在大屏设备（平板、折叠屏）上体验良好。因为 Android XR 的 2D 兼容模式本质上就是把你的应用当成一个大屏平板应用来跑。如果你的应用已经适配了响应式布局、支持键盘鼠标操作、处理了多窗口生命周期，那它在 Android XR 上的基础体验就不会太差。这样即使 XR 平台起飞，你也能快速跟上；如果平台 flops，你也没什么损失。

写在最后

Google 做 Android XR，技术上这次确实比 Daydream 靠谱，至少有正经的硬件联盟、有基于 Android 14 的系统根基、有 Jetpack 的工具链支撑。但 XR 这个市场，技术从来不是决定性因素。Meta 烧了十年钱，Quest 才勉强做到盈亏边缘；Apple 扛着 M2+R1 芯片做出来 Vision Pro，结果沦为一个精致的 demo 设备。

Android XR 面临的最大挑战，