浅谈 Unity XR:从混战到统一,OpenXR 的演进与现实困境
一.引言
在 XR(扩展现实)技术日渐普及的今天,Unity 已成为开发 VR、AR 和 MR 应用的主流平台。然而在这个生态蓬勃发展的背后,XR 的接口标准也经历了混乱到统一的演进过程。从早期的厂商割据,到 Unity 的初步抽象,再到 OpenXR 的出现,一步步走向“写一次,到处运行”的理想。
二.什么是 XR?它和 VR、AR、MR 的关系?
XR 是“Extended Reality”(扩展现实)的缩写,是一个统称,涵盖了以下三类技术:
-
VR(Virtual Reality,虚拟现实):用户完全沉浸在一个虚构的 3D 虚拟世界中,比如使用 Oculus Rift、HTC Vive 体验的游戏或模拟场景。
-
AR(Augmented Reality,增强现实):将虚拟物体叠加到现实世界中,常用于手机、眼镜等设备,如 Google ARCore、Apple ARKit。
-
MR(Mixed Reality,混合现实):虚拟内容与现实世界实时交互并融合,强调更深层次的物理/空间理解,比如 Microsoft HoloLens。
XR 是对 VR、AR 和 MR 的总称,用来泛指所有这类“现实+虚拟”结合的技术。Unity 将这些技术整合进统一框架,统称为 XR 系统。
三.发展进程
1. 各自为战的早期混乱
最初,XR 设备制造商如 Oculus(Meta)、HTC Vive、HoloLens、ARCore(Google)、ARKit(Apple)等各自推出了各自的 SDK。这些 SDK 各不兼容:
-
Meta 使用 Oculus SDK
-
HTC 使用 SteamVR / Vive SDK
-
Android 平台使用 ARCore
-
iOS 则使用 ARKit
这意味着开发者必须针对每个平台分别适配、编写交互逻辑,代码重复、维护困难、移植复杂。
2. Unity XR Plug-in Framework:初步统一
为了缓解上述问题,Unity 推出了 XR Plug-in Management 框架,试图规范 XR 插件的接入流程。Unity 将原本各家 SDK 封装为统一的 XR Plug-in 接口,比如:
-
Oculus XR Plugin
-
ARCore XR Plugin
-
Windows XR Plugin
-
Mock HMD Loader(虚拟测试设备)
配合 XR Interaction Toolkit 和 Input System,Unity 提供了一套可复用的开发范式,一定程度的屏蔽了各个厂商SDK的差异。但开发者仍需手动为不同平台切换插件,部分 API 也仍存在厂商差异。
笔者近期对接一个厂商的设备,导入了它家的SDK,因为厂商接入了 XR Plug-in Management 框架
所以我可以很方便的配置,只需要简单的勾选.但你可能感到疑问,为什么就这么几个选项,前面不是提到一大堆厂商吗?他们的SDK选项去哪了?请往下看!
3. OpenXR:由 Khronos Group 推出的统一标准
OpenXR 是由 Khronos Group(OpenGL/Vulkan 的制定者)主导的跨平台 XR 规范。目标是让所有 XR 平台和设备使用统一的接口标准。
其带来的好处是显而易见的:
-
开发者使用一套 API(如 Unity 的 OpenXR 插件)
-
所有支持 OpenXR 的设备可直接运行
-
极大简化开发成本与平台迁移代价
如今主流厂商如 Meta、Pico、HTC、微软等均已提供 OpenXR Runtime 实现,并逐渐弃用自家旧 SDK。
你可能感到疑问:在OpenXR出现之前,Unity难道没有帮我们屏蔽各个厂商SDK的差异吗?
答案是:
在 OpenXR 出现之前,Unity 的 XR Plug-in Management 确实已经在做“屏蔽厂商 SDK 差异”的工作,但有以下几个重要特征:
Unity XR Plug-in Management 是一个 插件管理框架
它做的事情是:
-
让你能通过 UI 面板方便切换 SDK(比如 Oculus XR Plugin、ARCore Plugin、Windows XR Plugin)
-
提供统一的生命周期管理(初始化、启用、禁用 XR)
但是,它并没有提供统一的运行时行为(比如不同 SDK 的输入系统、空间定位、手柄交互方式等行为仍不同)。
所以 Unity 后来推出了 XR Interaction Toolkit —— 真正统一开发接口
-
XR Plug-in Management 管插件生命周期(选谁、启谁)
-
XR Interaction Toolkit 管开发接口(开发者怎么写)
但这里的问题来了:
各家 SDK 的实现行为和支持范围仍有差异,即使你都使用 Toolkit,有些功能不同厂商支持也不同。
例如:
功能 | Oculus XR Plugin | ARCore Plugin | Windows XR Plugin |
---|---|---|---|
手柄交互支持 | ✅ | ❌ | ✅ |
头部追踪 | ✅ | ✅ | ✅ |
手势识别 | ❌ | ✅ | ❌ |
Haptic(触感)反馈 | ✅ | ❌ | ✅ |
总结:
Unity XR Plug-in Management + XR Interaction Toolkit = 半统一
插件管理是统一的,但底层行为因 SDK 差异仍不一致
需要开发者写一些分平台逻辑,兼容差异(例如 if UNITY_ANDROID && !UNITY_EDITOR
)
OpenXR的强大:
特点 | 之前(XR Plug-in + Toolkit) | OpenXR 之后 |
---|---|---|
插件切换 | 手动切换插件 | 统一一个插件 |
行为统一(如交互/输入) | 存在差异 | 底层行为统一 |
可扩展性(比如手势系统) | SDK 限制 | 通过 OpenXR extension |
厂商适配 | 多套插件 | 一套 OpenXR runtime |
前面提到的我对接的哪家厂商就没实现OpenXR,所以我就不可避免的使用他家特有的API,导致我的代码实现不了一次编写到处运行.
这也回答了刚才的问题:多家厂商的SDK都被统一到OpenXR的选项上了
这需要我们引入OpenXR的包,因为我没引入这个包,所以刚才的截图没有该选项,但是为什么PC下面就有这个选项呢?这其实是一个快捷的预安装选项,勾选之后会自动帮我引入OpenXR的包,引入了包安卓下面也会出现OpenXR选项.
但要注意的是:
虽然 OpenXR 实现了跨厂商 XR 接口的统一,但这并不意味着从此完全脱离厂商 SDK。在许多情况下,厂商会通过 OpenXR 提供基础功能支持,而将高级特性、运行时驱动、扩展能力保留在自己的 SDK 中。因此,即使使用 Unity 的 OpenXR Plugin,我们在开发中仍有可能需要引入厂商的支持插件,例如 HTC 设备需依赖 SteamVR 插件完成设备连接与功能调用。
IOS似乎拒绝加入OpenXR,还需要引入额外的包.
4. Unity + OpenXR:开发者视角
Unity 对 OpenXR 的支持主要通过以下几个官方包实现:
-
OpenXR Plugin:用于注册和管理底层 OpenXR runtime
-
XR Plug-in Management:用于选择 XR 后端(OpenXR、Oculus 等)
-
XR Interaction Toolkit:提供统一的交互行为(抓取、指向、按钮等)
如果所用设备支持 OpenXR,开发者只需勾选 OpenXR,使用 XR Interaction Toolkit 就可实现大部分 XR 功能,无需关注厂商差异。
5. 未完全统一的现实:平台与厂商的落差
尽管 OpenXR 是趋势,但现实中并非所有平台与厂商都已完成迁移:
-
Android 平台 仍常见 ARCore 与 Oculus 插件选项
-
iOS 平台 完全不支持 OpenXR,只能继续使用 ARKit
-
部分中小厂商(如 RhinoX Pro) 提供自研 SDK,虽声称遵循 Unity XR Plug-in 接口,但未实现 OpenXR Runtime,仍需调用其自定义 API
这导致在某些项目中仍不可避免地混用官方与厂商 API。
就比如这家厂商还没完全迁移到OpenXR,所以就遗留了这个选项.
6. OpenXR 并非银弹:平台差异仍存在
尽管 OpenXR 统一了设备差异,但平台差异(如 Android vs Windows)仍需开发者关注:
-
UI 呈现、资源管理、文件路径等仍不一致
-
AR 支持(如环境理解)目前未被 OpenXR 完全覆盖
-
性能调优策略、渲染管线等也需平台自适应
也就是说,OpenXR 是“统一设备行为”的手段,但不是“统一 一切平台差异”的解决方案。
7. 实践建议
-
使用支持 OpenXR 的设备时,优先使用 Unity 官方的 OpenXR 插件和 XR Interaction Toolkit
-
如果设备未支持 OpenXR,需根据厂商文档使用其 SDK,放弃 XR Toolkit 的部分功能
-
针对多平台部署,需做好平台判断与抽象封装
-
持续关注厂商 SDK 和 Unity 的更新节奏,掌握第一手迁移时机
仅个人理解,欢迎指正