一.引言
在 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 的更新节奏，掌握第一手迁移时机
仅个人理解,欢迎指正