一.引言

在 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。