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