OpenXR 新增「空间容器」扩展：XR 应用可像桌面窗口一样多任务并存
10 月 19 日，OpenXR 新增空间容器扩展（编号 811 与 814）：应用可在有界窗口与全屏沉浸之间切换，适合多任务 XR 应用的开发者。
10 月 19 日，Khronos 的 OpenXR 工作组发布博客，宣布 OpenXR 新增两个已批准的扩展：XR_EXT_spatial_container（注册编号 811）和 XR_EXT_spatial_container_self_rendering（编号 814）。OpenXR 是跨平台 VR 与 AR 应用的统一接口。在 OpenXR 1.x 里，一个应用独占用户看到的全部画面。空间容器（spatial container）要改变的正是这一点：它是由系统统一管理的显示区域，外观接近桌面窗口，多个应用可以同时悬浮在用户周围。
要点
- 两个扩展都标为「已批准」（Ratified），修订版本为 1。规范页的最后修改日期是 2026 年 8 月 6 日。
- 启用空间容器的会话只在
XR_SESSION_STATE_IDLE与XR_SESSION_STATE_LOSS_PENDING之间切换，可见、可交互和关闭状态改由每个容器的事件通知。 - 新建容器默认不可见、模式为有界（
BOUNDED）。要全屏需先请求沉浸（IMMERSIVE）模式；数量受maxSpatialContainerCount限制，超出时返回XR_ERROR_LIMIT_REACHED。
背景
OpenXR 1.x 的应用模型是：应用掌握全部画面，运行时只为安全做细微调整。规范概述写明，这一模型无法覆盖多个同时进行的体验。
Road to VR 把这个缺口放在 visionOS 旁边比较。Apple Vision Pro 自 2024 年发售起就有 Shared Space，多个 3D 应用可以并排摆放、随意移动。Quest 目前一次只能运行一个空间应用，但系统仪表盘、浏览器和 2D 窗口可以与它并存。Road to VR 还指出，Apple 使用自己的 API，不在 OpenXR 支持的平台之列。
「容器」一词容易和 Linux 容器混淆。微软的 WSL 3.0 把 Linux 容器带进了 Windows（参见 WSL 3.0 的条目），那是运行 Linux 容器的能力。空间容器是交给应用绘制画面的显示区域，两者只是同名。
事实部分
规范把这项能力拆成两个扩展：811 负责创建、显示和关闭容器，814 规定应用如何把画面交给运行时。下表是规范中可以直接核对的参数与默认值。
| 项目 | 规范中的说法 |
|---|---|
| 扩展编号与状态 | 811 与 814 均为 Instance 扩展，修订版本 1，状态为 Ratified |
| 依赖关系 | 811 依赖 OpenXR 1.0，814 依赖 811 |
| 新建容器的默认状态 | 不可见、不可交互，模式为 XR_SPATIAL_CONTAINER_BOUNDS_MODE_BOUNDED_EXT |
| 尺寸参数 | suggestedBounds，单位为米；{0, 0, 0} 表示没有偏好，运行时可以忽略 |
| 数量上限 | maxSpatialContainerCount，超出时返回 XR_ERROR_LIMIT_REACHED |
| 能力上报 | supportsBounded 与 supportsImmersive；运行时必须拒绝不受支持的模式 |
会话层面的变化同样具体。启用后，xrBeginSession 与 xrEndSession 都会返回 XR_ERROR_SPATIAL_CONTAINERS_ENABLED_EXT。它们的替代者是 814 中的 xrBeginSpatialContainerRenderingEXT 与 xrEndSpatialContainerRenderingEXT。规范说明，这两个函数不在每一帧里调用，它们决定哪些容器参与渲染。
显示与隐藏通过 xrRequestSpatialContainerVisibleEXT 申请，结果由事件返回，运行时可以拒绝。规范举的例子是：用户用系统的「最小化」按钮隐藏了容器，之后应用再申请显示，有些运行时会拒绝，并发出 XrEventDataSpatialContainerVisibleRequestDeniedEXT。部分实现还需要与系统服务通信，申请可能要等用户在系统对话框里操作后才完成。
用户点关闭按钮，或会话进入 XR_SESSION_STATE_LOSS_PENDING，运行时都会发出 XrEventDataSpatialContainerClosedEXT。应用收到后应停止使用该容器、清理相关状态，再销毁它。位置同样由系统决定：Khronos 博客写明，容器位置由运行时控制；规范还允许运行时在有界与沉浸之间切换时改变容器的位置和朝向。
怎么试
OpenXR SDK 1.1.65 在 hello_xr 示例里新增了空间容器模式，GitHub 发布时间为 10 月 16 日（UTC）。代码是 openxr_program_spatial_containers.cpp，共 1409 行，比直接读规范更快看懂生命周期。示例先用 xrGetSystemProperties 读取 supportsBounded 与 supportsImmersive，然后最多创建三个容器，且不超过 maxSpatialContainerCount。代码注释写明，边界模式要在显示前设定，之后才调用 xrRequestSpatialContainerVisibleEXT。运行中，输入动作会调用 xrRequestSpatialContainerBoundsModeEXT，在有界与沉浸之间切换最后一个容器。
示例本身不会给设备增加新能力。要跑起来，设备的运行时必须已经实现这两个扩展。Khronos 说实现会在 2026 年陆续出现，我们没有查到哪款头显已经公布支持。
各方说法
Khronos 说，这两个扩展来自 18 个月的合作，参与的有多家 OpenXR 运行时和引擎厂商。规范的贡献者名单包括 Google、Meta、Unity、Varjo、ByteDance、Qualcomm、Valve、Microsoft、Collabora、Godot、LÖVR 和 NVIDIA。
博客收录了七段具名表态。Google 平台与 SDK 负责人 Jared Finder 说，Google 很高兴把空间容器支持带到 Android XR。Godot 团队写明，下一版会支持空间容器。Meta、PICO、Unity、Varjo 和 Collabora 的表态以赞同为主，没有给出交付时间。Valve 与 Microsoft 只出现在贡献者名单里，没有对外表态。
Road to VR 的 Scott Hayden 把它和 visionOS 相提并论，口吻偏向预测：现有 OpenXR 头显很可能很快开始实现，但规范发布并不等于现有头显立即支持。文中列出的 OpenXR 平台包括 Quest、SteamVR 系 PC VR 头显与 Steam Frame、Android XR 头显、Varjo、Magic Leap 和 XREAL。这份清单说明的是 OpenXR 的覆盖面，不是空间容器的承诺名单。
IT之家 的中文报道基本转述了 Khronos 与 Road to VR 的内容，并称 OpenXR 生态中的各平台预计从今年起陆续实现。我们在 Hacker News 上搜索 OpenXR spatial containers，没有找到讨论。
编辑判断
对做 XR 应用的团队，这是架构层面的改动。过去一个应用对应一个会话、一个渲染循环；现在要按容器管理生命周期：创建、设定边界模式、申请显示、等可见事件、渲染，收到关闭事件后销毁。xrBeginSession 与 xrEndSession 启用后直接报错，老的渲染循环要按容器重写，不能小修小补。
最大的保留意见在控制权。位置由系统决定，尺寸只是建议，运行时可以忽略；显示请求可能被拒绝，也可能延迟。开发者能做的是声明想要的模式与大小，并处理结果。对需要精确摆放界面的应用，这是实际限制。
时间表仍然不确定。Khronos 说生态会在 2026 年陆续实现，但没有给出日期；Google 与 Godot 的表态是其中最具体的两条。我们查到的材料里，Meta 没有给出 Quest 的支持时间，Apple 也不在 OpenXR 之列。Khronos 还在推进「系统提供渲染器」的扩展，目前尚未发布。
有两个细节容易读错。这两个扩展至迟在 9 月初就已批准：SDK 1.1.63 的发布说明已把它们列为新批准的多厂商扩展，10 月的公告则把规范、示例和厂商表态一起公开。另外，多任务窗口也不是 XR 的首例，Road to VR 提到，visionOS 自 2024 年起就有 Shared Space。这次的新意是给 OpenXR 平台提供一套跨厂商的共同写法。