从彩色透视到MR开发：Unity OpenXR实战与性能优化

1. 先看这四条快报：它们分别改变了什么

这几天的 VR 圈信息密度确实有点高：SteamFrame 的彩色透视配件被曝光，首发时每台还附赠《半条命：Alyx》；《枪手契约》VR 版定档 9 月 10 日；Bigscreen Beyond 2 宣布永久降价。对普通玩家来说，这几条就是“要不要买”的问题；但对做 VR 内容和应用开发的人来说，它们是四份不同方向的信号，分别指向硬件形态、内容分发、玩法节奏和成本结构。

我把这四条信息放在一起看，是因为它们恰好覆盖了 VR 开发最现实的一条链路：设备能不能把真实世界喂给应用（透视能力）→ 平台愿不愿意用内容带动装机（首发捆绑）→ 开发者能不能做出真正适配 VR 的玩法（定档产品）→ 终端成本能不能降下来（价格策略）。任何一环卡住，下游的开发投入都会变得犹豫。

需要提前说明的是，本文不讨论具体售价、发售日期和硬件规格，这些信息变化快，且必须以官方公告为准。本文要做的是把这些动态当作“技术风向”，拆解它们对开发者真正有影响的部分，然后给出一套可以落地运行的彩色透视（Color Passthrough）开发流程。如果你正在用 Unity 做 VR/MR 应用，或者正准备把 2D 交互改成空间交互，下面的内容可以直接拿去用。

1.1 彩色透视配件曝光，最值得关注的是“透视质量”而不是“配件本身”

所谓彩色透视，简单讲就是头显不摘下，通过外部摄像头把真实环境以彩色画面实时渲染到眼前。它和早期的黑白透视（灰度透视）最大差别在于：彩色透视能保留颜色、文字、标识和材质细节，人眼对真实世界的判断不会被打断。

对开发者来说，这带来的是交互范式的变化。在纯 VR 里，用户处在一个封闭的虚拟空间中，交互靠手柄射线；在彩色透视的 MR 里，用户能看到自己的桌面、键盘、杯子，于是“把虚拟面板贴在真实桌面上”“用手直接抓取真实物体旁的虚拟按钮”才成立。这也是为什么彩色透视被看作 MR 应用的地基能力。

但“支持彩色透视”和“彩色透视好用”是两件事。真正影响体验的是三个指标：

所以在拿到任何一台新设备时，我更建议先跑一个“透视标定 Demo”，而不是直接开始做业务。后面第 4 节会给出这个 Demo 的完整做法。

1.2 首发捆绑《半条命：Alyx》，反映的是平台对“标杆内容”的依赖

这条消息在玩家眼里是福利，在开发者眼里是另一层意思：平台仍然需要一款“必须玩”的内容来证明硬件价值。《半条命：Alyx》之所以长期被当作 VR 内容的天花板，不只是画面好，而是它把 VR 的交互做成了玩法本身——抓取、换弹、翻找、投掷，全都依赖手部动作和空间理解。

这对我们的启发很直接：如果你的应用只是把 2D 界面搬进 3D 空间，那用户戴上头显的动机就很弱。VR 内容的护城河往往来自“这个操作只有 VR 能做”。在做技术选型时，可以先问自己一个问题：我的核心操作，用鼠标键盘能不能完成？如果能，那 VR 版本的价值就需要重新设计。

1.3 《枪手契约》定档 9.10，说明 VR 射击仍是内容供给的主力品类

射击类在 VR 里长盛不衰，原因是它的交互映射最自然：手柄指向即枪口，扳机即开火，换弹即抓取弹匣。技术实现上，这类项目的共性也很强——射线检测、弹道模拟、后坐力、命中反馈、网络同步。

对独立开发者来说，射击品类的技术门槛不在渲染，而在手感调优和性能稳定。一帧掉到 60 以下，瞄准就会飘；手柄延迟超过 20ms，玩家就会觉得“打不中是我的问题”。第 5 节会专门讲帧率与延迟的优化手段。

1.4 Bigscreen Beyond 2 永久降价，说明“轻量化 + 降本”是确定方向

轻量化的意义在于佩戴时长。头显越轻、越不压脸，单次使用时间就越长，这对内容方是利好——用户愿意在应用里待更久，留存和付费才有基础。成本下降则直接影响 B 端项目的硬件采购预算：一台设备降几百块，几十台的部署成本就能省出一笔开发费用。

从工程角度看，轻量化设备通常意味着算力被拆分到外部（例如由 PC 或手机承担渲染），这就要求开发者更重视串流链路的质量：编码延迟、码率自适应、丢包恢复。这部分内容在第 5 节和第 6 节会展开。

2. 彩色透视的核心概念与技术分工

在动手之前，必须先把几个容易混淆的概念理清楚。很多新手卡住，不是因为代码写错，而是没搞明白“透视画面到底是谁渲染的”。

2.1 透视画面不是引擎渲染的，而是合成器合成的

这是最关键的一句话。以 Unity 为例，你写Camera渲染的只是虚拟物体；真实世界的画面从摄像头采集，经过畸变校正、色彩校正、时间对齐，最后由系统合成器（Compositor）与引擎提交的图层混合，再送到显示屏。

所以整条链路是：

1. 摄像头采集原始图像帧
2. 运行时做去畸变、双目对齐、色彩匹配
3. 引擎提交“透视图层”或开启透传背景
4. 合成器把透视层与虚拟层按深度或图层顺序混合
5. 显示到屏幕

理解了这条链路，你就知道为什么“透视画面颜色怪”“透视和虚拟物体错位”“开启透视后掉帧”这些问题的根因往往不在你的 C# 代码里，而在运行时、权限或者图层配置上。

2.2 单眼透视、立体透视和深度图是三个不同层级

很多设备的“支持彩色透视”其实只保证前两项，深度图是可选能力。如果你的应用需要“虚拟球从真实桌面上滚下去”，就必须确认深度或空间网格可用；否则只能退化成“贴一个平面”。

2.3 OpenXR 与平台 SDK 的分工要分清

OpenXR 是跨厂商的开放接口标准，它定义的是“应用怎么向运行时请求能力”，比如手柄输入、眼动、透视、深度。它不定义具体某个厂商的摄像头型号和调参方式。

因此实际项目里通常是两层：

• 上层：OpenXR + 引擎插件（Unity 的 OpenXR Plugin、XR Interaction Toolkit、AR Foundation）
• 下层：平台运行时（SteamVR、各厂商 PC 端运行时、一体机系统运行时）

跨平台项目应该尽量把逻辑写在 OpenXR 层，把平台差异收敛到一个IPassthroughProvider接口后面。这是本文后面代码组织的主线。

3. 环境准备与版本说明

这一节说明本文示例的运行环境。由于不同引擎版本、插件版本差异较大，本文不写死具体版本号，只给出“选择原则”，你按项目实际情况调整。

3.1 硬件与运行时

• 一台支持彩色透视的头显（一体机或 PC VR 均可）
• 对应的 PC 端运行时或设备系统运行时，并确保已开启透视相关权限
• 一根合格的数据线（PC 串流场景），优先选官方线材或带宽足够的线

需要注意的是，透视功能通常涉及摄像头权限。一体机首次启用时会弹权限框，如果误点拒绝，后续所有透视调用都会静默失败——这类问题在排查时优先级很高，第 6 节会单独列出。

3.2 引擎与插件选择

Unity 侧建议的组合是：

• Unity 2021 LTS 及以上（LTS 版本更稳）
• XR Plug-in Management
• OpenXR Plugin
• AR Foundation（提供跨平台的相机图像与透视背景能力）
• XR Interaction Toolkit（提供手柄交互和输入动作）

这里强调一个原则：插件版本要和 Unity 版本对齐。Unity 的包管理器里，OpenXR Plugin 和 AR Foundation 都有明确的版本兼容区间，混用很容易出现“编译通过但运行时找不到 Feature”的情况。

# 查看当前项目已安装的 XR 相关包（在项目根目录执行） cat Packages/manifest.json | grep -E "xr|openxr|arfoundation"

3.3 示例项目结构

本文示例采用如下目录结构，方便你对照放置文件：

PassthroughDemo/ ├── Assets/ │ ├── Scenes/ │ │ └── PassthroughDemo.unity │ ├── Scripts/ │ │ ├── Runtime/ │ │ │ ├── PassthroughController.cs │ │ │ ├── VrInputRouter.cs │ │ │ └── FrameStatsLogger.cs │ │ └── Editor/ │ │ └── XrSetupChecker.cs │ ├── Settings/ │ │ └── passthrough-runtime.json │ └── Materials/ │ └── VirtualPanel.mat ├── Packages/ │ └── manifest.json └── ProjectSettings/ └── XRPackageSettings.asset

4. 完整实战：搭建一个彩色透视 MR Demo

这个 Demo 的目标很明确：戴上头显后，能看到真实的房间，同时在真实桌面前方固定一块虚拟面板，用手柄射线点击面板上的按钮，并在面板上实时显示当前帧率和透视开关状态。麻雀虽小，但它把透视、输入、UI、性能监控四条主线都串起来了。

4.1 创建项目并安装依赖

新建 3D（URP）项目后，先装依赖。管线建议用 URP，因为 MR 场景对透明和后期处理的要求比内置管线更容易控制。

# 示例：通过 Unity CLI 以批处理方式打开项目并触发一次资源导入 # 具体 Editor 路径请替换为你本机的安装路径 "/Applications/Unity/Hub/Editor/<你的版本>/Unity.app/Contents/MacOS/Unity" \ -projectPath "$(pwd)/PassthroughDemo" \ -batchmode \ -quit \ -logFile ./import.log # Windows 示例 # "C:\Program Files\Unity\Hub\Editor\<你的版本>\Editor\Unity.exe" ^ # -projectPath "%cd%\PassthroughDemo" -batchmode -quit -logFile .\import.log

安装完成后，在Packages/manifest.json中应当能看到类似下面的依赖项（版本号按你的实际环境填写，不要直接照抄）：

{ "dependencies": { "com.unity.xr.management": "4.x.x", "com.unity.xr.openxr": "1.x.x", "com.unity.xr.arfoundation": "5.x.x", "com.unity.xr.interaction.toolkit": "2.x.x", "com.unity.inputsystem": "1.x.x", "com.unity.render-pipelines.universal": "12.x.x" } }

这里需要特别提醒：不要手动拼版本号。正确做法是在 Package Manager 里选择“Add package by name”，让 Unity 自己解析可用版本，再确认没有编译错误。

4.2 开启 OpenXR 与透视扩展

路径是Edit → Project Settings → XR Plug-in Management，勾选目标平台的 OpenXR。然后在OpenXR → Features列表里，按设备能力勾选：

• 基础交互相关的 Feature（手柄输入）
• 透视 / Passthrough 相关 Feature（名称依插件版本而异）
• 深度 / 空间网格相关 Feature（如果要做遮挡）

这一步最容易踩的坑是：Feature 勾了但没生效。原因通常是勾选后没有重启 Editor，或者当前 Build Target 与勾选平台不一致。我一般会写一个编辑器脚本做自检，避免团队里每个人都要重复确认。

// 文件路径：Assets/Scripts/Editor/XrSetupChecker.cs using UnityEditor; using UnityEngine; using UnityEngine.XR.OpenXR; public static class XrSetupChecker { [MenuItem("Tools/XR/检查 OpenXR 配置")] public static void CheckOpenXRSettings() { var settings = OpenXRSettings.GetSettingsForBuildTargetGroup( EditorUserBuildSettings.selectedBuildTargetGroup); if (settings == null) { Debug.LogError("未找到 OpenXR 设置，请先在 XR Plug-in Management 中启用 OpenXR。"); return; } if (!settings.IsExtensionEnabled("XR_KHR_composition_layer_depth")) { Debug.LogWarning("深度合成层扩展未启用，虚拟物体与真实环境的遮挡可能不准确。"); } Debug.Log($"OpenXR 渲染模式：{settings.renderMode}"); Debug.Log("检查完成，若修改过 Feature，请重启 Editor 后再次验证。"); } }

上面用到的OpenXRSettings.GetSettingsForBuildTargetGroup和IsExtensionEnabled属于 OpenXR Plugin 提供的编辑器 API，具体可用性请以你所在插件版本的文档为准。如果方法名在某个版本中不存在，请按编译提示调整，不要强行保留。

4.3 编写透视控制脚本

透视的开启与关闭，本质上是控制相机背景层是否显示外部图像。以 AR Foundation 的ARCameraBackground为例，核心就是切换它的enabled。

// 文件路径：Assets/Scripts/Runtime/PassthroughController.cs using System; using UnityEngine; using UnityEngine.XR.ARFoundation; /// <summary> /// 统一管理透视开关与相机背景显示。 /// 挂在 XR Origin 的 Camera 对象上，或手动指定 cameraManager。 /// </summary> [RequireComponent(typeof(ARCameraManager))] public class PassthroughController : MonoBehaviour { [SerializeField] private ARCameraManager cameraManager; [SerializeField] private ARCameraBackground cameraBackground; [SerializeField] private bool enableOnStart = true; /// <summary>透视状态变化时抛出，方便 UI 联动。</summary> public event Action<bool> OnPassthroughChanged; public bool IsEnabled { get; private set; } private void Awake() { if (cameraManager == null) { cameraManager = GetComponent<ARCameraManager>(); } if (cameraBackground == null) { cameraBackground = GetComponent<ARCameraBackground>(); } } private void Start() { SetPassthrough(enableOnStart); } /// <summary>打开或关闭透视背景。</summary> public void SetPassthrough(bool enabled) { if (cameraBackground == null) { Debug.LogWarning("未找到 ARCameraBackground，透视背景无法切换。"); return; } // 关闭时同时停掉相机背景渲染，减少一层无用的绘制开销 cameraBackground.enabled = enabled; IsEnabled = enabled; OnPassthroughChanged?.Invoke(enabled); Debug.Log($"[Passthrough] 当前状态：{(enabled ? "开启" : "关闭")}"); } /// <summary>尝试抓取一帧相机图像，用于截图、识别或调试。</summary> public bool TryAcquireFrame(out XRCpuImage image) { image = default; if (cameraManager == null || !cameraManager.enabled) { return false; } return cameraManager.TryAcquireLatestCpuImage(out image); } }

几个容易忽略的点：

第一，ARCameraBackground关闭后，相机就只会渲染虚拟内容，画面会变成纯虚拟背景，这在“沉浸模式”和“混合模式”切换时很有用。

第二，TryAcquireLatestCpuImage拿到的XRCpuImage是必须释放的，否则会持续占用内存甚至导致采集失败。正确写法是using包裹或者在用完时显式调用Dispose()。后面第 7 节会强调这一点。

第三，透视开关不要每帧调用。它是配置级操作，频繁切换会导致合成器重建图层，反而掉帧。

4.4 输入动作与手柄映射

输入部分推荐用 Input System 的 Action 方式，而不是直接读按键。原因是 Action 可以在不同设备之间做映射，跨平台时改动最小。

// 文件路径：Assets/Scripts/Runtime/VrInputRouter.cs using UnityEngine; using UnityEngine.InputSystem; /// <summary> /// 手柄输入路由：把 OpenXR 的输入动作分发给业务逻辑。 /// 需要配合 XR Interaction Toolkit 的 InputActionProperty 使用。 /// </summary> public class VrInputRouter : MonoBehaviour { [SerializeField] private InputActionProperty selectAction; [SerializeField] private InputActionProperty gripAction; [SerializeField] private InputActionProperty menuAction; public bool IsSelectPressed { get; private set; } public bool IsGripPressed { get; private set; } private void OnEnable() { EnableAction(selectAction, OnSelectPerformed, OnSelectCanceled); EnableAction(gripAction, OnGripPerformed, OnGripCanceled); EnableAction(menuAction, OnMenuPerformed, null); } private void OnDisable() { DisableAction(selectAction, OnSelectPerformed, OnSelectCanceled); DisableAction(gripAction, OnGripPerformed, OnGripCanceled); DisableAction(menuAction, OnMenuPerformed, null); } private static void EnableAction(InputActionProperty property, System.Action<InputAction.CallbackContext> performed, System.Action<InputAction.CallbackContext> canceled) { if (property.action == null) return; if (performed != null) property.action.performed += performed; if (canceled != null) property.action.canceled += canceled; property.action.Enable(); } private static void DisableAction(InputActionProperty property, System.Action<InputAction.CallbackContext> performed, System.Action<InputAction.CallbackContext> canceled) { if (property.action == null) return; if (performed != null) property.action.performed -= performed; if (canceled != null) property.action.canceled -= canceled; property.action.Disable(); } private void OnSelectPerformed(InputAction.CallbackContext ctx) => IsSelectPressed = true; private void OnSelectCanceled(InputAction.CallbackContext ctx) => IsSelectPressed = false; private void OnGripPerformed(InputAction.CallbackContext ctx) => IsGripPressed = true; private void OnGripCanceled(InputAction.CallbackContext ctx) => IsGripPressed = false; private void OnMenuPerformed(InputAction.CallbackContext ctx) { // 示例：菜单键切换透视，交给你自己的 PassthroughController 实例 var controller = FindObjectOfType<PassthroughController>(); if (controller != null) { controller.SetPassthrough(!controller.IsEnabled); } } }

注意FindObjectOfType在每帧调用会有性能问题，这里只在按键回调里调用，频率极低，可以接受。生产项目更推荐用事件总线或序列化引用，避免运行时的查找开销。

4.5 运行与验证

把相机、PassthroughController、VrInputRouter挂好，另建一个世界空间的 Canvas 作为虚拟面板，绑定按钮回调。然后在真机上运行（透视能力在编辑器里通常无法完整模拟）。

验证分四步走：

1. 戴上头显，确认能看到真实环境并有颜色。
2. 在面板上点击按钮，确认透视可以开关，且状态文案同步变化。
3. 快速左右转头，观察真实物体边缘是否出现明显拖影。
4. 打开性能面板，记录稳定运行时的帧率和帧时间。

如果第 3 步出现拖影，大概率是透视延迟或渲染帧率不足；如果第 1 步是黑白画面，说明彩色透视扩展没启用，或者设备本身不支持彩色。这两类问题的排查方式完全不同，第 6 节会给对照表。

5. 性能与画面质量：决定 MR 体验上限的两个变量

透视类应用的性能瓶颈和普通 VR 不太一样。普通 VR 的压力主要来自虚拟物体的绘制；MR 应用还要额外承担相机采集、色彩转换和合成开销。所以优化思路要分两条线走。

5.1 分辨率与渲染缩放要分开看

很多新手会把“透视画面糊”归因于渲染分辨率。实际上这是两件事：

• 透视清晰度由摄像头分辨率和合成链路决定，你改渲染分辨率不会让它变清楚
• 虚拟物体清晰度由渲染分辨率和抗锯齿决定，可以调
• 两者错位由标定和时间对齐决定，调不了，只能通过减少延迟缓解

在实际项目里，我会把渲染缩放控制在 1.0 附近，优先保证帧率稳定，而不是一味拉高分辨率。因为对 MR 来说，抖动带来的不适远大于分辨率不足。

5.2 透视层和合成层的分工要交给运行时

引擎提交的图层越少、越简单，合成器越容易优化。所以在设计上应遵循：

• 透视层只负责真实背景，不要在透视层上叠 UI
• 虚拟 UI 放在单独的图层里，避免每帧重建
• 需要遮挡时，优先使用运行时提供的深度或网格，而不是自己算

如果一个应用同时开启了透视、深度、手部追踪和高质量后期，帧率一定会掉。我的建议是先做“能力开关表”，让用户按需开启：

{ "passthrough": { "enabled": true, "colorMode": "color", "depthOcclusion": false, "renderScale": 1.0 }, "performance": { "targetFps": 72, "adaptiveResolution": true, "maxGpuBudgetMs": 11.0 }, "features": { "handTracking": false, "eyeTracking": false } }

// 文件路径：Assets/Scripts/Runtime/RuntimeConfigLoader.cs using System; using System.IO; using UnityEngine; [Serializable] public class RuntimeConfig { public PassthroughConfig passthrough; public PerformanceConfig performance; } [Serializable] public class PassthroughConfig { public bool enabled; public string colorMode; public bool depthOcclusion; public float renderScale; } [Serializable] public class PerformanceConfig { public int targetFps; public bool adaptiveResolution; public float maxGpuBudgetMs; } public static class RuntimeConfigLoader { public static RuntimeConfig Load(string fileName = "passthrough-runtime.json") { var path = Path.Combine(Application.streamingAssetsPath, fileName); if (!File.Exists(path)) { Debug.LogWarning($"未找到配置文件：{path}，使用默认值。"); return new RuntimeConfig { passthrough = new PassthroughConfig { enabled = true, renderScale = 1.0f }, performance = new PerformanceConfig { targetFps = 72, adaptiveResolution = true } }; } var json = File.ReadAllText(path); return JsonUtility.FromJson<RuntimeConfig>(json); } }

把能力做成配置而不是硬编码，好处是同一份构建可以在不同设备上跑，遇到性能差的机器直接关掉高消耗特性，不用重新出包。

5.3 功耗与散热要提前纳入测试

轻量化设备（比如分体式头显）往往把渲染放在外部，头显本体只负责显示。这类设备的续航和发热测试必须在前中期就做，否则上线后会出现“玩 20 分钟就降频”的反馈。

一个实用的办法是记录每帧耗时并定期输出统计，光照、后处理、透明层的变化都会体现在数据上。

// 文件路径：Assets/Scripts/Runtime/FrameStatsLogger.cs using System.IO; using UnityEngine; /// <summary> /// 极简帧率采样器：每 5 秒输出一次统计，便于对比不同配置下的性能。 /// </summary> public class FrameStatsLogger : MonoBehaviour { [SerializeField] private float reportInterval = 5f; [SerializeField] private bool writeToFile = true; private float _elapsed; private int _frames; private float _worstFrameMs; private StreamWriter _writer; private void Start() { if (!writeToFile) return; var path = Path.Combine(Application.persistentDataPath, "frame-stats.csv"); _writer = new StreamWriter(path, append: false); _writer.WriteLine("timestamp,fps,avg_frame_ms,worst_frame_ms"); Debug.Log($"性能日志输出到：{path}"); } private void Update() { _elapsed += Time.unscaledDeltaTime; _frames++; _worstFrameMs = Mathf.Max(_worstFrameMs, Time.unscaledDeltaTime * 1000f); if (_elapsed < reportInterval) return; var fps = _frames / _elapsed; var avgMs = _elapsed * 1000f / _frames; Debug.Log($"[FrameStats] FPS={fps:F1} 平均帧时间={avgMs:F2}ms 最差帧时间={_worstFrameMs:F2}ms"); _writer?.WriteLine($"{System.DateTime.Now:O},{fps:F2},{avgMs:F2},{_worstFrameMs:F2}"); _writer?.Flush(); _elapsed = 0f; _frames = 0; _worstFrameMs = 0f; } private void OnDestroy() { _writer?.Dispose(); _writer = null; } }

拿到 CSV 之后，可以用一段小脚本快速看趋势，比一帧一帧盯日志高效得多。

# 文件路径：tools/analyze_frame_stats.py import csv import sys from statistics import mean def analyze(path: str) -> None: with open(path, newline="", encoding="utf-8") as f: rows = list(csv.DictReader(f)) if not rows: print("日志为空，检查采样脚本是否真的在运行。") return fps = [float(r["fps"]) for r in rows] worst = [float(r["worst_frame_ms"]) for r in rows] print(f"采样段数: {len(rows)}") print(f"平均 FPS: {mean(fps):.2f}") print(f"最低 FPS: {min(fps):.2f}") print(f"最差帧时间峰值: {max(worst):.2f} ms") # 低于 60 FPS 视为需要关注的段 bad = [i for i, v in enumerate(fps) if v < 60] if bad: print(f"存在 {len(bad)} 段低于 60 FPS，索引: {bad[:10]}{' ...' if len(bad) > 10 else ''}") else: print("所有采样段均高于 60 FPS。") if __name__ == "__main__": if len(sys.argv) != 2: print("用法: python analyze_frame_stats.py frame-stats.csv") sys.exit(1) analyze(sys.argv[1])

这种“采样 + 落盘 + 离线分析”的链路，比在头显里盯着一个数字有用得多。特别是做多设备适配时，你可以把不同设备的 CSV 放在一起对比，很快就能定位到是哪个特性吃掉了性能。

6. 常见问题与排查思路

MR 项目的报错往往很“安静”：不崩、不报红，就是效果不对。下面这张表是我在实际项目里整理的高频问题清单。

关于“虚拟物体和真实环境错位”，这是最容易被误判的问题。很多开发者第一反应是去调相机位置或者改 FOV，结果越调越偏。正确的顺序是：先确认设备是否处于标定完成状态，再看帧率是否稳定，最后才怀疑坐标变换。因为延迟造成的错位，在静止时是看不出来的，只有快速转头才明显——这也是为什么测试时一定要做“摇头测试”。

关于“手柄按钮无响应”，最常见的错误是只Subscribe了回调但忘了action.Enable()。Input System 的 Action 默认是禁用状态，尤其是通过代码动态创建时。第 4.4 节的代码里专门做了Enable和Disable的成对处理，就是踩过这个坑之后加的。

还有一类问题来自“特性叠加”。比如同时开了透视、手部追踪和高质量后期，在性能较弱的设备上会触发自适应降频，表现就是“一开始很流畅，几分钟后变卡”。这类问题在实验室的台式机上几乎复现不了，必须用目标设备长时间跑。我的做法是每次改动后固定跑 15 分钟压力场景，记录 CSV，和上一版做对比。

7. 工程最佳实践

上面把流程跑通了，接下来是让它能长期维护的部分。这几点在 MR 项目里尤其重要，因为调试成本比普通应用高得多——每次验证都要戴设备。

7.1 用接口隔离平台差异

不要把平台特有的 API 散落在业务代码里。定义一个能力接口，把差异收敛到实现类：

// 文件路径：Assets/Scripts/Runtime/IPassthroughProvider.cs public interface IPassthroughProvider { bool IsSupported { get; } bool IsEnabled { get; } void SetEnabled(bool enabled); bool TryGetDepthAvailability(out bool available); }

业务层只依赖这个接口，换设备时只换实现。这个习惯在跨平台项目里能省下大量返工。

7.2 资源必须显式释放

XRCpuImage、各种NativeArray、相机纹理都需要显式释放。前面提到过TryAcquireLatestCpuImage的返回值必须Dispose，这里再强调一次，因为它的泄漏是渐进式的——短时间测试看不出来，跑久了才会出现采集失败。

7.3 日志要带上下文

MR 应用的日志最好包含：设备型号、运行时版本、当前透视状态、当前渲染缩放。出问题时这几项信息能省掉一半沟通成本。建议在启动时打一条汇总日志，而不是零散地到处打。

7.4 权限和隐私要写在前面

透视会用到摄像头，这属于敏感权限。工程上要做到：

• 首次使用前明确告知用途
• 提供关闭透视的入口，且关闭后功能仍可用（降级而不是崩溃）
• 不采集、不落盘、不上传原始相机画面，除非业务确实需要且用户明确同意

这不是合规套话，而是产品设计的一部分。一个不打招呼就开摄像头的应用，用户第二次就不会打开了。

7.5 性能预算要前置

建议在项目启动时就定一条硬线：目标帧率的单帧时间预算。比如目标 72 FPS，单帧预算约 13.9ms，那么渲染、逻辑、合成加起来不能超过这个数。把预算写进文档，每次加新特性前先问“这要吃掉多少毫秒”。等到上线前再优化，往往只能删功能。

8. 接下来可以往哪走

如果你已经跟着把 Demo 跑起来了，接下来有几个方向值得深入。

第一个方向是遮挡与空间理解。有了深度或空间网格，虚拟物体才能“藏在”真实桌子后面，这是 MR 沉浸感的关键一步。可以从简单的平面检测开始，再过渡到网格。

第二个方向是手部交互。手柄到手势的迁移是趋势，但手势识别的稳定性和误触率仍需打磨。建议先做“手势 + 手柄”双通道，让用户自己选。

第三个方向是串流质量。如果你的目标设备是分体式的，编码延迟和码率自适应就绕不开。可以从固定码率开始测，再逐步引入动态调整。

第四个方向是内容节奏。回到开头那几条快报——平台愿意用标杆内容带硬件，说明“能玩”比“能跑”更重要。技术上跑通只是起点，真正的难点是设计出只有 VR 才能完成的核心操作。

最后留一个可以直接用的自检清单，每次出包前过一遍：

1. 透视开关是否在无权限时优雅降级？
2. 快速摇头时是否有明显拖影？
3. 连续运行 15 分钟，帧率是否稳定在目标值以上？
4. 所有XRCpuImage是否都有对应的释放？
5. 配置文件缺失时是否有合理默认值？
6. 日志里能否看到设备型号和运行时版本？
7. 关闭透视后，核心功能是否仍然可用？

把这几条做成团队 checklist，比事后救火划算得多。硬件在变、内容在变，但“能稳定跑、能优雅退化、能快速定位问题”这三件事，在任何一代 VR 设备上都不会过时。