一.引言
在 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 的更新節奏，掌握第一手遷移時機
僅個人理解,歡迎指正
)
)
