4.3 一条 XR 项目的完整流水线

4.3 一条 XR 项目的完整流水线

本节摘要：XR 项目从立项到上架的 7 步流水线：概念设计 → 原型设计 → 资产与场景 → 交互与代码 → 测试与优化 → 灰度与上架 → 运营与迭代。每一步都有 XR 特有的"坑"——眩晕、追踪漂移、空间尺度、跨设备兼容性。本节用一张 7 步流程图+每步的"典型耗时+典型坑"清单，把流水线讲清楚。

本节目标

阅读完本节，你应当能够：

1. 列出 XR 项目的 7 步流水线，并标出每步的典型耗时。
2. 说出每步常见的 3 个坑。
3. 解释为什么 XR 项目的"测试"比传统 3D 项目更重。
4. 在 Unity 里配置一份"XR 项目模板"。

一、问题与直觉

XR 项目和传统 3D 项目的流水线差异巨大：

• 传统 3D 项目：核心是"画面好不好"。
• XR 项目：核心是"虚拟与现实的关系"——空间尺度、追踪稳定性、跨设备一致性、合规与安全。

XR 项目的"坑"大多不在"画面"，而在"看不见的工程"。本节按时间顺序把 7 步流水线讲完，每一步标出 XR 特有的坑。

二、7 步流水线

Step 1：概念设计（1-2 周）

回答三个问题：

1. 目标用户：C 端还是 B 端？坐姿、站姿、还是移动？
2. 核心交互：看？操作？移动？社交？
3. 成功指标：日活、付费、留存、效率提升、错误率降低？

XR 特有坑：

• C 端 PMF 模糊：Quest 平台 70% 应用月活 <10 万——找 C 端 PMF 难。
• 场景选择错：做"VR 健身"对，做"VR 办公"难。
• 合规被忽略：眼动、空间映射的合规要求在 B 端更严。

Step 2：原型设计（2-3 周）

低保真原型——重点测"核心交互"是否成立。

XR 特有坑：

• "看起来简单"的操作"实际很难"：用手势旋转 3D 模型，纸面看简单，测试时 30% 用户不会。
• "好玩"≠"有效"：demo 看起来酷，但用户完不成任务。
• 戴头显 10 分钟就开始累：原型阶段就要测"穿戴时长"。

工具建议：Figma 画 UI 流程 + Unity/UE 做最小可玩原型 + 5-10 个目标用户做用户测试。

Step 3：资产与场景（2-4 周）

XR 资产与传统 3D 资产最大的差异是"真实空间尺度"——1 单位的物体在 XR 里要"看起来"是 1 米，不能错。

XR 特有坑：

• 比例错：把"米"做成"厘米"——用户看到的虚拟物体比真实小 100 倍。
• 光照错：PBR 材质在 VR 里光照计算耗时占 40%+——需要光照贴图预烘焙。
• 音效错：空间音频不调好，VR 里所有声源都从头顶传来。

Step 4：交互与代码（4-8 周）

XR 代码的核心挑战是"延迟预算"——所有逻辑必须在 11.1ms 内完成。

XR 特有坑：

• 物理引擎 vs 头动：用 Unity 物理引擎做"球体滚动"时，要小心头动导致的"球体被传过去"的伪影。
• UI 缩放：VR 里的 UI 不能"贴脸"——最佳距离 1-3m。
• 手柄/手势双输入：同时支持手柄和手势时，按键映射要一致。

Step 5：测试与优化（3-5 周）

XR 测试比传统 3D 测试更重。原因是：

• 多种设备组合（Quest 3、Vision Pro、Pico 4、AR 眼镜）。
• 多种环境（办公室、客厅、户外、强光、弱光）。
• 多种用户（瞳距不同、视力不同、对 XR 耐受度不同）。

XR 特有坑：

• 设备兼容性：不同厂商 Runtime 行为差异——同一段 OpenXR 代码在不同头显上结果可能差 10%。
• 追踪漂移：低纹理场景下 SLAM 漂移——必须有"重置"功能。
• 发热降频：连续运行 30 分钟后芯片降频——性能优化要在"温热"状态下做。

Step 6：灰度与上架（2-4 周）

XR 应用上架比传统 App 复杂：

• Quest 应用要通过 Meta 的 VRC（Virtual Reality Check）审核。
• Vision Pro 应用要通过 Apple 的 visionOS 审核。
• Pico 应用要通过 Pico 审核。
• AR 应用上架 iOS/Android 还要通过各平台审核。

XR 特有坑：

• 审核被拒：Meta 经常因"内容健康""年龄分级""空间音频"打回。
• 打包大小：Quest 3 限制 APK < 4GB。
• 性能基线：Quest 3 要求中段机（GPU 加载 90%）保持 90Hz。

Step 7：运营与迭代（持续）

XR 应用的运营是"边走边升级"——很多功能要在真实使用中迭代。

XR 特有坑：

• 没有用户反馈机制：XR 头显里没有"评分"按钮——必须用遥测。
• 空间锚点失效：AR 应用运行 6 个月后，物理环境改了，锚点失效。
• 跨设备体验不一致：Quest 3 用户的体验和 Vision Pro 用户的体验差距大。

三、一份"XR 项目模板"配置

把上面 7 步沉淀成一份 Unity 项目模板：

XRTemplate/
├── Assets/
│   ├── Scenes/
│   │   ├── Main.unity            # 主场景
│   │   └── TestRoom.unity        # 测试场景（含标尺）
│   ├── Scripts/
│   │   ├── XRBootstrap.cs        # 启动 XR
│   │   ├── InputManager.cs       # 多模态输入
│   │   ├── PerformanceHUD.cs     # 性能监控
│   │   └── ResetWorld.cs         # 重置 SLAM
│   ├── Materials/
│   │   └── XRMaterialLibrary     # 预烘焙光照
│   └── Audio/
│       └── SpatialAudioMixer    # 空间音频混音
├── Packages/
│   ├── com.unity.xr.management
│   ├── com.unity.xr.openxr
│   ├── com.unity.xr.oculus
│   └── com.meta.xr.sdk.core
└── Settings/
    └── XR Plugin Settings.json   # 多端打包配置
​

这份模板的价值：把"XR 项目的工程基础设施"沉淀一次，后续项目复用，省 4-6 周启动时间。

本节要点回顾

• XR 项目 7 步流水线：概念→原型→资产→代码→测试→上架→运营。
• XR 项目的"坑"多在"看不见的工程"：空间尺度、追踪漂移、合规、跨设备。
• XR 测试比传统 3D 测试重 30%——多设备、多环境、多用户。
• 把 7 步流水线沉淀为"XR 项目模板"，后续项目节省 4-6 周启动时间。
• 运营期最大风险是"空间锚点失效"——必须支持重新定位。

下一节我们深入"性能预算与优化"——XR 项目的 11.1ms 怎么分配。