【共创稿事节】空间计算在电商、文旅、社交等行业的应用场景探索

最后的轻羽

168人浏览 · 2026-09-20 09:09:29

最后的轻羽 · 2026-09-20 09:09:29 发布

【共创稿事节】空间计算在电商、文旅、社交等行业的应用场景探索

方向二：空间计算技术研究与场景实战
技术底座：HarmonyOS 7（API 26）
说明：本文为技术研究与场景设计稿。文中代码基于华为开发者官网公开的 API 签名撰写，属"设计态实现"——Spatial Recon Kit 官方明确暂不支持模拟器，本文所有代码均未在真机/模拟器上完成编译与运行验证，请以官方最新文档为准。

摘要

HarmonyOS 7（API 26）首次把空间计算以"系统级技术栈"的形态完整开放出来：ArkUI 声明式空间界面与沉浸光感负责"界面升维"，ArkGraphics 3D 负责"模型呈现"，Spatial Recon Kit 负责"场景重建"，Audio Kit 负责"听觉定位"。能力齐了，但真正的难题从技术侧转移到了选型侧：电商、文旅、社交三个行业，究竟该用哪一段能力？

本文的核心观点是：空间化不等于 3D 化，行业差异决定技术栈选型。三个行业对空间计算的需求侧重点完全不同——电商要的是"单件商品的可信质感"，文旅要的是"大尺度空间的漫游自由"，社交要的是"人与人之间的在场感"。对应的技术路径分别是"模型链路"“场景链路”“界面链路”，三条链路在内容生产成本、渲染开销、设备门槛上的量级差异可达一个数量级。

文章先解构 API 26 空间计算技术栈的分层与边界，再逐个行业给出场景拆解、参考实现与落地约束，最后提炼一套跨行业通用的"空间化成本—收益四象限"与降级矩阵。

关键词：HarmonyOS 7；API 26；空间计算；3DGS；ArkGraphics 3D；Spatial Recon Kit；沉浸光感；空间音频

一、引言：从"看见内容"到"进入场景"

移动端 UI 的演进有一条清晰的主线：信息密度的提升方式在不断更换。

功能机时代靠层级菜单；
触屏时代靠滚动列表与卡片；
推荐流时代靠算法排序。

这三次跃迁本质上都在做同一件事——在二维平面上更高效地摆放信息。但二维平面的信息承载能力正在逼近天花板：一张商品主图再精美，也传达不了"这个沙发摆在 12 平米客厅里会不会显得拥挤"；一段探店视频再清晰，也回答不了"这家店靠窗的位置到底有几个"；一次视频通话再流畅，也还原不了"他说话时是站在我左边还是右边"。

这些问题的共同点是：答案不在画面里，而在空间关系里。

HarmonyOS 7 给出的解法，是把"空间"从一个设计隐喻，变成一套可被应用直接调用的系统能力。华为官方将这套能力概括为三个方向——空间美学、空间影像、空间交互¹，对应到开发者手里，就是五个可组合的模块：

模块	能力定位	解决的真问题
ArkUI + Spatial UI	声明式空间界面开发范式	用 Z 轴层级替代"加边框、改颜色"的层级表达
沉浸光感（ImmersiveMaterial）	极简接入、全局一键配置	零着色器成本获得材质感、光影与形变反馈
ArkGraphics 3D	轻量级 3D 引擎与渲染管线	按需加载 GLB 模型，做商品/设备的可控展示
Spatial Recon Kit	空间重建与感知（3DGS）	把"专业建模"降级为"拍一圈视频"
Audio Kit（空间音频）	立体声场渲染	让声音携带方位信息，形成听觉空间

这张表有个容易被忽略的细节：五个模块的成本完全不在一个量级。沉浸光感是"配一个属性"，ArkGraphics 3D 是"准备一个模型文件"，Spatial Recon Kit 是"组织一次数据采集"。

而绝大多数空间化改造项目的失败，不是败在渲染跑不动，而是败在选错了成本档位——一个只需要加 Z 轴的页面被塞进了 3DGS 重建，预算和内容供应链当场崩掉。

这正是本文想回答的问题。

二、技术底座：API 26 空间计算技术栈解构

2.1 渲染层：ArkGraphics 3D 与 Spatial Recon Kit 的分工

这两个模块最容易被混为一谈，但官方的定位其实非常清晰：Spatial Recon Kit 是 ArkGraphics 3D 的扩展，需与 ArkGraphics 3D 联合使用²。

理解这句话，是理解整条渲染链路的关键。

ArkGraphics 3D（方舟 3D 图形） 是底座。它基于轻量级 3D 引擎与渲染管线，提供两类工作模式³：

自动场景模式：直接加载 .gltf / .glb 文件，框架自动创建基础相机、光源与交互控制。适合"我只是想把模型摆出来"的需求——商品预览、设备展示。
自定义场景模式：开发者自行管理 Scene、Camera、Light、Node 节点树，可创建图片、材质、环境与自定义着色器，控制动画状态与 ToneMapping 后处理。适合需要精确控制画面与交互的场景。

技术规格上，它支持 glTF 2.0 标准与 MeshOpt 压缩（EXT_meshopt_compression 扩展），底层图形后端要求 OpenGL ES 3.2+ 或 Vulkan 1.0+ 的 GPU 驱动，引擎层基于 ECS 架构并通过 NAPI 暴露接口³。这个"轻量"的定位很重要——它不是 Unity/Unreal 的替代品，它的价值恰恰在于不引入重型引擎进程，Component3D 直接作为页面的一部分渲染，因此可以和普通 ArkUI 页面共存。

Spatial Recon Kit（空间建模套件） 是扩展。它集成 3DGS（3D Gaussian Splatting）的渲染与运算能力，用于"从图像到三维"以及"三维内容的编辑"²。社区普遍将其能力归纳为三层结构⁴：

Spatial Recon Kit
├── spatialImage  → 2D 图像/视频 → 3DGS/Mesh（端侧重建）
├── spatialRender → 3DGS 加载、实时渲染、风格化滤镜
└── spatialEdit   → 高斯点框选、变换、上色、删除、导出 PLY

官方 API 侧，spatialRender 的系统能力为 SystemCapability.Graphics.SpatialRender，自 6.0.1(21) 起提供，加载 3DGS 模型的标准写法是 GSPlugin.loadGSNode()⁵：

import { spatialRender } from '@kit.SpatialReconKit';
import { Scene, RenderContext } from '@kit.ArkGraphics3D';

// 1. 获取默认渲染上下文
let renderContext: RenderContext | null = Scene.getDefaultRenderContext();

if (renderContext != null) {
  // 2. 把 GSPlugin 注册进 ArkGraphics 3D 的渲染管线
  renderContext.loadPlugin(spatialRender.GSPlugin.PLUGIN_ID);

  // 3. 加载场景并挂载 3DGS 节点
  let scene = Scene.load().then(async (scene: Scene) => {
    let uri = "OhosRawFile://assets/gltf/model.glb"; // 3DGS 模型 URI，可为 MP4/PLY/GLB
    let offset = 0;

    let gsNode: spatialRender.GSNode =
      await spatialRender.GSPlugin.loadGSNode(scene, { uri, offset }, scene.root);

    // GSNode 继承自 Node，可按普通 3D 节点操作
    gsNode.position = { x: 3, y: 0, z: 0 };
    gsNode.scale = { x: 1.5, y: 1.5, z: 1.5 };
    gsNode.visible = true;
  });
}

这段代码里藏着整个架构设计的核心：loadPlugin 把 3DGS 的渲染逻辑注册进 ArkGraphics 3D 的渲染管线，loadGSNode 解析出由数万个高斯椭球组成的场景节点，此后的 Camera、Light、Component3D 渲染流程与普通 GLB 模型完全一致。⁶

也就是说，开发者不需要为 3DGS 单独学一套渲染框架——这是鸿蒙空间计算在"开发成本控制"上最务实的一步。

关于大规模场景，API 26 引入了 TiledGSNode（分块 3DGS 渲染对象，Phone/PC/2in1/Tablet/TV 均自 26.0.0+ 支持）⁵。官方术语表对其原理的描述是：将完整模型按空间划分为多个瓦片，渲染时按需加载当前视口所需的瓦片数据，有效降低内存占用和渲染开销⁷。

这是"大场景能不能上手机"的分水岭。华为官网与公开报道给出的量级参考是：花瓣地图等应用实现了 2 平方公里、20 家店铺、累计约 4 亿高斯球的空—地—室内一体化端侧实时渲染⁸。

2.2 界面层：声明式为什么是空间界面的最优解

ArkUI 的声明式范式在进入三维后，优势会被急剧放大。

命令式 UI 需要开发者一步步告诉系统"怎么做"：设置宽度、设置背景、添加子控件、更新 Z 深度……在 2D 时代尚可应付，但空间界面把状态维度从"位置 + 尺寸"扩展成了"位置 + 尺寸 + Z 深度 + 旋转角 + 透视参数 + 光照响应"，手动同步这些状态的复杂度是乘法级的。

声明式把这件事反转过来：开发者只描述"当前状态应该是什么样"，状态变化的同步由框架完成。配合 @State 驱动，一段卡片的空间姿态可以完全由数据描述⁹：

// ArkUI 空间布局：通过 translate.z 与 shadow 构建深度层级
Stack() {
  BackgroundLayer()
    .width('100%')
    .height('100%')

  ContentLayer()
    .translate({ z: 30 })
    .shadow({ radius: 10 })

  ActionButton()
    .translate({ z: 60 })
    .shadow({ radius: 20 })
}

社区实践中被反复验证的一条经验是：Z 轴分层最多三层。浅层（贴近屏幕）、中层、深层，超过三个深度层级后，用户的视觉系统反而无法稳定判断前后关系，depth cue 会互相打架¹⁰。

2.3 材质层：沉浸光感是"性价比最高"的空间化入口

如果要选一个"投入产出比最高"的 API 26 新能力，我会选沉浸光感。

从 API 26.0.0 起，ArkUI 提供沉浸光感能力，由两部分组成¹¹：

沉浸式系统材质（ImmersiveMaterial）：通过影响组件的 backgroundColor、borderColor、borderWidth、shadow 和 materialFilter，让组件呈现具有层次感和通透感的视觉表现。
空间动效：为 Dialog、菜单控制等组件的弹出过程增添形变、流光等动态表现。

它的接入成本低到什么程度？不需要写一行着色器：

import { uiMaterial } from '@kit.ArkUI';

// 创建一个"薄"材质：高透明度 + 按压形变 + 触控光效
private readonly thinMaterial: uiMaterial.Material = new uiMaterial.ImmersiveMaterial({
  style: uiMaterial.ImmersiveStyle.THIN,   // 薄材质，适合搜索框、小浮层
  interactive: true,                        // 启用按压弹性形变
  lightEffect: { color: Color.White }       // 启用触控光效反馈
});

// 应用到组件
Column() {
  Text('ArkUI Immersive Material')
    .fontSize(20)
    .fontWeight(FontWeight.Bold)
}
.width('100%')
.height(96)
.borderRadius(24)
.systemMaterial(this.thinMaterial)

ImmersiveStyle 提供五档材质，从薄到厚依次为 ULTRA_THIN（超高透明度，适合悬浮工具栏）、THIN（适合搜索框）、REGULAR（通用）、THICK（强模糊，适合菜单）、ULTRA_THICK（极强模糊，适合弹窗）¹²。额外可配置 materialColor、colorInvert、applyShadow、interactive、lightEffect 五个属性。

这里有一个新手必踩的坑，值得单独拎出来：沉浸光感有两套接口，服务两类不同的组件¹³——

组件类型	使用接口	来源模块	生效方式	起始版本
普通 ArkUI 组件（Column/Row/搜索框等）	`uiMaterial`	`@kit.ArkUI`	`systemMaterial`	API 26.0.0+
HDS 空间化组件（HdsNavigation/HdsTabs/MiniBar 等）	`hdsMaterial`	`@kit.UIDesignKit`	`systemMaterialEffect`	6.1.0(23)+

把 HDS 的枚举往普通组件上塞（或反过来），编译能过，效果为零。此外还有两个硬约束：开启沉浸光感需确保应用 targetSDKVersion 不低于 26.0.0；且沉浸光感开启后需要大量 GPU 资源，需关注功耗¹⁴。

另一个值得称道的工程设计是自动降级：沉浸光感会根据设备算力档位（高/中/低）和用户系统设置中的三档强度（强/均衡/弱），自动调整材质与动效表现，开发者无需针对组合分别适配¹¹¹²。这意味着"一次定义，全端生效"。

2.4 感知层：空间音频让声音携带方位

空间计算常被简化为"视觉的三维化"，但听觉的方位信息在很多时候更高效。

OHAudioSuite 自 API 23 起提供空间渲染效果节点 EFFECT_NODE_TYPE_SPACE_RENDER，支持三种工作模式¹⁵：

模式	核心接口	效果
固定摆位	`OH_AudioSuiteEngine_SetSpaceRenderPositionParams`	将音源固定在三维空间特定位置
旋转	`OH_AudioSuiteEngine_SetSpaceRenderRotationParams`	音源围绕听者或指定点动态旋转
扩展	`OH_AudioSuiteEngine_SetSpaceRenderExtensionParams`	按半径和角度扩展声场

坐标系采用左手坐标系，X/Y/Z 取值范围均为 [-5.0, 5.0]，单位为米：X 为左右（负左正右）、Y 为上下（负下正上）、Z 为前后（负后正前）¹⁵。开发时需链接 libohaudio.so 与 libohaudiosuite.so。

API 26 还补上了编码侧的短板：AVCodec Kit 新增支持 Audio Vivid 编码（华为主导的超高清音频标准，亦是 UWA 标准之一），意味着开发者可以在应用端直接生成空间音频内容，而不只是播放端解码¹⁶。

2.5 能力边界：一张选型矩阵

把上面的分析收拢成一张表，这是本文给出的第一个可复用工具：

能力	内容生产成本	渲染开销	设备门槛	适配周期	典型适用
沉浸光感材质	零	中（GPU）	API 26+，算力自适应	小时级	卡片/弹窗/工具栏全局升维
ArkUI Z 轴层级	零	低	低	小时级	首页、详情页、个人中心
ArkGraphics 3D（GLB）	中（需建模）	中	GPU 驱动 ES3.2+/Vulkan1.0+	天级	单件商品、设备、虚拟形象
Spatial Recon Kit（3DGS）	低（拍视频）但需采集组织	高	Phone/Tablet/PC/TV，不支持模拟器	周级	商铺、景区、大场景复原
TiledGSNode	同上	中高（分块优化）	26.0.0+	周级	景区级、平方公里级漫游
空间音频	低	低	API 23+（渲染）/26（编码）	天级	导航、讲解、社交、直播

读法：从左往右，单位收益递增，但单位成本也递增。绝大多数应用应该从表格前三行开始，而不是直奔 3DGS。

三、场景一：电商——从"看图猜质感"到"先试后买"

3.1 行业痛点与价值锚点

电商的空间化需求，本质是降低线上购物的"信息不对称成本"。

退货率的构成里，有相当比例来自"实物与预期不符"——摸不到材质、判断不了尺寸、感受不到光泽。传统解法是堆主图、拍视频、写详情文案，但这些都是"二维信息的一维堆叠"，边际收益递减明显。

空间计算给出的解法分三个层次，从轻到重：

层次一：空间化商品卡片（成本 ≈ 0）
用 Z 轴层级 + 沉浸光感重构商品卡的视觉结构：主图上浮一层，价格与行动按钮再上浮一层，背景退到深层。用户的视觉系统会自动解析出"什么是主角、什么是可操作的"。

@Component
struct SpatialProductCard {
  @State isFocused: boolean = false;
  private readonly cardMaterial: uiMaterial.Material =
    new uiMaterial.ImmersiveMaterial({
      style: uiMaterial.ImmersiveStyle.REGULAR,
      interactive: true,
      lightEffect: { color: Color.White }
    });

  build() {
    Stack({ alignContent: Alignment.TopStart }) {
      // 深层：背景氛围
      Image($r('app.media.product_bg'))
        .width('100%')
        .height('100%')
        .objectFit(ImageFit.Cover)

      // 中层：商品主图
      Column() {
        Image($r('app.media.product'))
          .width('100%')
          .height(200)
          .objectFit(ImageFit.Contain)
      }
      .translate({ z: this.isFocused ? 40 : 24 })
      .shadow({ radius: this.isFocused ? 24 : 12, offsetY: 8 })

      // 浅层：价格与行动区
      Row() {
        Text('¥ 1,299').fontSize(20).fontWeight(FontWeight.Bold)
        Blank()
        Button('加入购物车').fontSize(14)
      }
      .width('100%')
      .padding(12)
      .translate({ z: this.isFocused ? 64 : 48 })
      .shadow({ radius: 20, offsetY: 12 })
    }
    .width('92%')
    .height(280)
    .borderRadius(16)
    .systemMaterial(this.cardMaterial)
    .onHover((isHover: boolean) => { this.isFocused = isHover })
    .animation({ duration: 240, curve: Curve.EaseOut })
  }
}

这一层的价值常被低估：它不需要任何 3D 资产，却能让整个列表页的信息层级清晰度上一个台阶。

层次二：GLB 商品模型（成本 = 建模）
这是电商空间化的主战场。用 ArkGraphics 3D 的自动场景模式加载商品 GLB，用户可以 360° 旋转、缩放、切换材质。

对这一层，我想强调一个工程判断：优先用自动场景模式，不要一上来就自定义 Scene。自动场景模式会自动创建基础相机、光源与交互控制³，对"商品预览"这类需求已经足够，且省掉了光照调试的大量时间。只有当需要精确控制材质、环境反射或自定义动画时，才切换到自定义场景模式。

层次三：3DGS 实景与商铺（成本 = 采集）
公开报道显示，京东在鸿蒙上推出的"立影"能力，商家只需用一部鸿蒙手机拍摄商品视频，约 30 分钟即可完成商品建模，毛绒玩具的绒感、褶皱、光泽都能真实还原¹⁷。华为官网亦确认京东接入 3DGS 能力可快速完成商品建模、立体还原细节¹⁸。

这条路径的意义不在"效果更好"，而在把建模从专业技能变成普通操作——这是内容供应链的重构，不是渲染技术的升级。

3.2 电商场景的关键约束

模型体积与首屏时延：GLB 建议启用 MeshOpt 压缩（EXT_meshopt_compression）³，并做懒加载——列表页只上层次一，详情页才加载模型。
不要为 SKU 全量建模：建议按"高客单价 + 高退货率 + 强质感依赖"三维筛选优先建模的 SKU。
沉浸光感的功耗：全局开启会显著增加 GPU 负载¹⁴，商品列表这类长滚动场景建议仅在可视区卡片启用，或走系统自适应档位。

四、场景二：文旅——从"到此一游"到"先游后到"

4.1 行业痛点与价值锚点

文旅的核心是决策前置。游客在出发前最想知道的三件事——这个地方值不值得去、进去之后怎么走、哪个角度最出片——恰恰是二维图文最难传达的。

有意思的是，文旅和电商虽然都用 3DGS，但技术侧重点完全不同：

维度	电商	文旅
对象	单件商品，尺度 < 2m	整个场景，尺度 10²～10³ m
视角	外部环绕观看	内部第一人称漫游
数据	可控环境拍摄	户外光照、人流、动态物体干扰
渲染	单模型整体加载	必须分块，按需加载
关键 API	`GSPlugin.loadGSNode`	`TiledGSNode`（26.0.0+）

分块是文旅场景的生死线。 一个景区级 3DGS 模型的全量加载在手机内存上是不现实的，TiledGSNode 通过"按空间划分瓦片、按需加载视口所需瓦片"，把内存占用从"整个景区"压到"视野所及"⁷。

参考实现思路（设计态）：

import { spatialRender } from '@kit.SpatialReconKit';
import { Scene, RenderContext, Camera } from '@kit.ArkGraphics3D';

// 景区级大场景：使用 TiledGSNode 分块加载
async function loadScenicArea(uri: string): Promise<Scene> {
  const renderContext: RenderContext | null = Scene.getDefaultRenderContext();
  if (!renderContext) {
    throw new Error('RenderContext unavailable');
  }

  await renderContext.loadPlugin(spatialRender.GSPlugin.PLUGIN_ID);
  const scene: Scene = await Scene.load();

  // TiledGSNode 自 26.0.0+ 提供，表示一个分块 3DGS 渲染对象，继承自 Node，
  // 用法参考 Node。官方 API 参考尚未给出构造方法的完整签名，
  // 下方的加载调用为示意写法，落地时请以官方最新 API 参考为准。
  //
  // const tiledNode: spatialRender.TiledGSNode = await <官方加载接口>(scene, { uri }, scene.root);
  // tiledNode.visible = true;
  // 关键差异：TiledGSNode 按视口调度瓦片，无需一次性载入全部高斯点。

  // 第一人称漫游：相机随用户位移推进，驱动瓦片调度
  const camera: Camera = scene.camera;
  // ... 绑定手势/位姿输入，更新 camera.position 与朝向

  return scene;
}

4.2 空间音频：文旅最被低估的体验增量

景区讲解是空间音频的天然场景，而且它比视觉更省电、更不打扰。

基于 EFFECT_NODE_TYPE_SPACE_RENDER 的固定摆位模式，可以把讲解音源绑定到场景中的具体坐标：走到"千年银杏"的坐标点附近，讲解声从对应方位传来；左转时，下一个景点的引导声自然偏向左侧¹⁵。

导航是另一个高价值落点。公开报道提到，地图类应用已实现"按行驶方向匹配左右声道，往哪边拐哪边传来提示音"¹⁹——这种"听声辨位"的体验增量，成本远低于视觉方案。

4.3 端侧重建：把游客变成内容生产者

文旅场景最迷人的一点是：空间资产可以 UGC。

华为官网展示的链路已经相当完整——通过 Remy 将无人机航拍影像变为超大 3D 空间地图，在手机上自由浏览；使用 V2Fun 则一张照片就能生成 3D 模型，支持 360° 预览¹⁸。公开报道补充了量级参考：Remy 端侧标清物体重建平均耗时约 3.5 分钟，空间模式可覆盖 200 余平方米，全景相机视频重建覆盖范围可达 1000㎡，无人机视频重建范围更大⁸。

对比"耗时 10 分钟以上、需联网排队甚至收费"的传统云端重建，端侧重建解决的其实是三个问题：时延、成本、隐私（数据不出设备）⁸。

对文旅行业而言，这意味着一条新的内容飞轮：游客拍摄 → 端侧重建 → 沉淀为空间资产 → 反哺景区数字档案 / 社交分享 / 官方导览。

五、场景三：社交——从"传递信息"到"传递在场感"

5.1 行业痛点与价值锚点

社交产品的空间化逻辑与前两个行业截然不同。电商和文旅处理的是"人与物""人与场景"的关系，社交处理的是**“人与人”**的关系。

传统社交工具传递的是信息，不是在场感：文字聊天知道对方在，但看不到；语音听到声音，但看不到表情；视频看到脸，但感受不到空间位置²⁰。

空间计算能补回的三个维度是：方位、距离、共同在场。

5.2 三个可落地的层次

层次一：空间化界面（成本 ≈ 0）
这是社交产品最快的切入方式。用 Z 轴表达"谁在关注、谁在说话"——当前发言者的头像上浮到浅层并放大，静默成员退到深层并降低不透明度。群聊从"所有人平铺在一个列表里"变成"谁在靠近、谁在后退"。

这一层完全用 ArkUI + 沉浸光感就能实现，不需要任何 3D 资产。我判断这是社交产品在 API 26 上最应该优先做的改造。

层次二：3D 虚拟形象（成本 = 建模）
鸿蒙生态中已有成熟实践： Soul App 鸿蒙版提供"捏脸"系统，用户创建代表自我的虚拟形象，作为身份象征与社交名片²¹。技术上可用 glTF 2.0 作为基础格式，通过扩展实现表情与动作驱动²²。

层次三：空间音频共在（成本 = 低）
这是社交场景性价比最高的一环。用固定摆位模式，把每个发言者的音源摆到虚拟空间的对应位置——朋友的声音从左边传来，多人讨论时各就各位，用户可以"走"到角落私聊¹⁵²⁰。

它不需要任何视觉资产投入，却能把"语音房"的体验从"一堆声音混在一起"升级为"一群人围坐在一起"。

层次四：真实空间分享（成本 = 采集）
将真实空间重建为 3D 模型分享给好友，让社交内容从二维走向三维²³。华为官网已展示"空间壁纸""空间照片"等消费形态，并在生态中形成"拍摄—重建—分享"的闭环¹⁸。

5.3 社交场景的特殊约束

实时性优先于画质：社交的音视频链路对延迟极度敏感，空间音频处理节点应尽量精简，避免过多 DSP 节点串联。
隐私是红线：涉及真实空间重建的场景，必须明确区分"个人空间"与"可分享空间"，重建数据默认本地留存。这一点上，端侧重建的"数据不出设备"特性本身就是最好的产品卖点⁸。
避免眩晕：3D 虚拟形象与空间漫游需限制相机运动速度，避免快速位移引发不适。

六、跨行业的共性设计范式

三个行业拆完，可以提炼出一套通用方法论。

6.1 空间化成本—收益四象限

我用一个二维矩阵来描述空间化改造的优先级判断：

                    高业务价值
                        ↑
   ② 模型化              ① 场景化
   (单件商品/虚拟形象)     (商铺/景区/大空间)
   ArkGraphics 3D        Spatial Recon Kit
                        |
   ←———低改造成本———+———高改造成本———→
                        |
   ③ 光感化              ④ 重建化
   (材质/光影/形变)       (UGC 采集 + 编辑)
   沉浸光感 + Z 轴        spatialImage/Edit
                        ↓
                    低业务价值

落地建议：所有应用都从象限 ③ 起步（零内容成本、全局生效），验证用户反馈后，再向 ② 或 ① 迁移。象限 ④ 需要有明确的内容生产闭环才值得投入。

6.2 "五类页面"启动法

不是每个页面都适合空间化。符合以下特征的页面优先改造²⁴：

页面类型	空间化切入点
首页 / 信息流	引入深度层次与光影动效
商品 / 内容详情页	3D 展示替代 2D 图片
个人中心 / 卡片	悬浮感与材质升级
引导 / Onboarding	沉浸式空间体验
设置 / 工具类页面	空间化交互替代传统列表

反过来，这些页面应当保持平面：登录页、简单设置页、纯表单页、少量选项的确认页、强调输入效率的工具页。这些页面的核心目标是"赶紧完成任务"，过多的层级、材质与动效反而降低效率²⁵。

6.3 三重降级矩阵

空间化能力必须设计降级路径，否则在中低端设备上会反噬体验：

降级维度	触发条件	降级策略
设备算力	低算力档位	依赖系统自适应；HDS 组件先调 `getSystemMaterialTypes()`，不支持 `IMMERSIVE` 时选 `SMOOTH`¹³
用户偏好	系统设置为"弱档"	由系统自动完成参数映射，开发者无需适配¹¹
内容规模	场景超出内存预算	启用 `TiledGSNode` 分块加载，按需请求瓦片⁷
版本兼容	`targetSDKVersion` < 26	参考 ArkTS API 兼容性保护做分支处理¹⁴

6.4 空间资产的可复用性：鸿蒙生态的隐藏红利

这是我在研究中最想强调的一个判断。

传统 3D 内容的最大问题是一次建模、一处消费——耗费成本建的商品模型，只能在商品详情页用一次。而在鸿蒙生态里，空间资产是可以在多个场景间流转的：V2Fun 生成的 3D 模型支持一键沉淀至华为图库²⁶，重建结果可导出 PLY⁴，空间影像可作为锁屏/壁纸消费¹⁸。

用一条链路概括鸿蒙围绕 3DGS 构建的闭环：

理解 → 重建 → 渲染 → 编辑 → 协同 → 分享

当空间资产可以跨应用复用时，建模成本就不再由单个业务承担，而是被整个生态摊薄。 这才是空间计算真正能规模化的经济基础。

七、挑战与展望

7.1 当前的三重挑战

其一，内容供给仍是最大瓶颈。 渲染能力已经就位，但"谁来建模"的问题没有自动解决。端侧重建把门槛降到了"拍一圈视频"，但采集规范（光照、重叠率、运动速度）仍需要被产品化地引导，否则普通用户产出的数据质量不稳定。

其二，功耗与性能的平衡。 官方已明确提示沉浸光感"开启后需要大量 GPU 资源"¹⁴，3DGS 渲染同样是重负载。虽然系统提供算力自适应与分块加载，但应用侧仍需要精细的作用域控制——避免全页面无差别开启。

其三，跨端体验的一致性。 空间化体验在手机、平板、折叠屏展开态、PC/2in1 上的表现差异远大于传统 2D UI。同一份空间资产在不同视口尺寸下的相机参数、层级深度都需要重新调校，这部分工程量的预估常被低估。

7.2 三个值得关注的方向

方向一：空间资产标准化。 当 3DGS、GLB、PLY 多种格式并存时，跨应用复用的前提是格式与坐标系的标准化。期待生态中出现事实标准。

方向二：AI 与空间计算的合流。 API 26 同期开放了端侧视觉 AI 能力——图像超分（端侧 4 倍高清放大）、文搜图（自然语言检索本地图片，全流程端侧闭环）²⁷。把"文搜图"接进空间资产库，用自然语言检索 3D 模型，是一个极具想象力的组合。

方向三：Agent 驱动的空间交互。 HarmonyOS 7 被官方定义为"迈入 Agent 时代"²⁸，当空间界面可被 AI 理解与调度，"说一句话生成一个可漫游的空间"就不是科幻了。

八、结语

回到开头那个问题：电商、文旅、社交，该用哪一段空间计算能力？

我的答案是——先看你的核心对象是什么：

对象是一件商品，走模型链路：ArkGraphics 3D + GLB，自动场景模式起步；
对象是一个空间，走场景链路：Spatial Recon Kit + TiledGSNode，分块加载是前提；
对象是一个人，走界面链路：ArkUI 空间层级 + 沉浸光感 + 空间音频，成本最低、见效最快。

而无论走哪条链路，都值得记住一句话：空间化的目的不是让界面变成立体画，而是用空间关系本身去组织信息。

当一个元素应该被关注时，让它往前站；当它不重要时，让它自然退后。这比加一个红色边框、放大字号要自然得多——就像现实里我们拿起一本书时，书会离眼睛更近，桌面上的其他东西自动变成背景，不需要任何人告诉我们"现在请重点关注这本书"²⁵。

HarmonyOS 7 把这套语言开放给了每一个开发者。剩下的，是学会用它把话说清楚。

参考与出处

HarmonyOS 7 空间计算围绕空间美学、空间影像、空间交互三大亮点，提供 ArkUI、Spatial UI、Audio Kit、Spatial Recon Kit、ArkGraphics 3D 等完整技术栈——中国日报网《HDD 成都站聚焦HarmonyOS 7新特性》 ↩︎
Spatial Recon Kit 集成 3DGS 模型的渲染与运算能力，支持 MP4/PLY/GLB 加载与滤镜风格化；仅支持中国境内（不含港澳台）；适用 Phone/Tablet/PC/2in1/TV；暂不支持模拟器；是 ArkGraphics 3D 模块的扩展，需联合使用——华为开发者官网《Spatial Recon Kit简介》 ↩︎ ↩︎
ArkGraphics 3D 支持 glTF 2.0（.gltf/.glb）与 MeshOpt 压缩，提供自动场景模式与自定义场景模式，可自定义 Light/Camera/Node、Image/Material/Environment/Shader，支持动画控制与 ToneMapping 后处理——华为开发者官网《ArkGraphics 3D简介》 ↩︎ ↩︎ ↩︎ ↩︎
Spatial Recon Kit 三层能力结构（spatialImage / spatialRender / spatialEdit）——HarmonyOS 开发者社区技术文章 ↩︎ ↩︎
spatialRender 系统能力 SystemCapability.Graphics.SpatialRender，起始 6.0.1(21)；GSPlugin.loadGSNode(scene, params, parent)；TiledGSNode 自 26.0.0+ 支持 Phone/PC/2in1/Tablet/TV——华为开发者官网 spatialRender API 参考 ↩︎ ↩︎
loadPlugin 将 GSPlugin 渲染逻辑注册进 ArkGraphics 3D 渲染管线，loadGSNode 解析 3DGS 数据构建高斯体场景节点，后续 Camera/Light/Component3D 渲染与普通模型一致——HarmonyOS 开发者社区《3DGS端侧重建——空间建模与渲染实战》 ↩︎
Tiled 3D Gaussian Splatting（分块 3D 高斯泼溅）：将完整模型按空间划分为多个瓦片，渲染时按需加载当前视口所需瓦片数据，有效降低内存占用和渲染开销——华为开发者官网《Spatial Recon Kit术语》 ↩︎ ↩︎ ↩︎
花瓣地图等实现 2 平方公里、20 家店铺、累计 4 亿高斯球的空—地—室内一体化端侧实时渲染；Remy 端侧 3DGS 标清物体重建平均约 3.5 分钟，空间模式覆盖 200+ ㎡，全景相机视频重建覆盖 1000㎡——赛迪网《鸿蒙 7：跨越分水岭，重塑全场景「新基建」》 ↩︎ ↩︎ ↩︎ ↩︎
ArkUI 声明式语法与 Z 轴空间布局示例——HarmonyOS 开发者社区《基于ArkUI的声明式空间界面开发入门》 ↩︎
Z 轴分层最多三层（浅层/中层/深层）——CSDN《【共创稿事节】空间化改造"贴地版"》 ↩︎
从 API 26.0.0 起 ArkUI 提供沉浸光感，含沉浸式系统材质与空间动效两部分；自动根据设备算力档位与用户设置的三档强度自适应调整——华为开发者官网《鸿蒙开发者沉浸光感视效适配教程》 ↩︎ ↩︎ ↩︎
ImmersiveStyle 五档（ULTRA_THIN/THIN/REGULAR/THICK/ULTRA_THICK）及 materialColor/colorInvert/applyShadow/interactive/lightEffect 属性——华为开发者官网《Immersive Light Sense》 ↩︎ ↩︎
普通 ArkUI 组件用 uiMaterial（@kit.ArkUI，API 26+，systemMaterial）；HDS 空间化组件用 hdsMaterial（@kit.UIDesignKit，6.1.0/23+）；getSystemMaterialTypes() 查询设备支持类型，不支持 IMMERSIVE 时选 SMOOTH——Besthub 技术文章 ↩︎ ↩︎
开启沉浸光感需确保 targetSDKVersion 不低于 26.0.0；开启后需要大量 GPU 资源——华为开发者官网《开启沉浸光感》 ↩︎ ↩︎ ↩︎ ↩︎
OHAudioSuite 自 API 23 提供 EFFECT_NODE_TYPE_SPACE_RENDER，支持固定摆位/旋转/扩展三种模式；左手坐标系，X/Y/Z 范围 [-5.0, 5.0] 米；需链接 libohaudio.so 与 libohaudiosuite.so——华为开发者官网《Spatial Rendering (C/C++)》 ↩︎ ↩︎ ↩︎ ↩︎
AVCodec Kit 新增 Audio Vivid 编码支持，开发者可在应用端生成空间音频内容——ITPUB《鸿蒙空间音效实战》 ↩︎
京东"立影"：商家用一部鸿蒙手机拍摄商品视频，约 30 分钟完成商品建模——今日头条相关报道（第三方数据，供参考） ↩︎
支持 3D 场景重建，通过 Remy 将无人机航拍影像变为超大 3D 空间地图；V2Fun 一张照片生成 3D 模型，支持 360° 预览；大众点评 3D 自由漫步探店；京东接入华为 3DGS 能力快速完成商品建模——华为消费者业务官网《HarmonyOS 鸿蒙操作系统 7》 ↩︎ ↩︎ ↩︎ ↩︎
地图导航按行驶方向匹配左右声道，往哪边拐哪边传来提示音——今日头条《鸿蒙独享！先逛后到、先看后买》 ↩︎
传统社交传递信息而非在场感；空间社交补回方位、距离、共同在场维度——CSDN《【共创稿事节】空间计算在社交场景的应用猜想》 ↩︎ ↩︎
Soul App 鸿蒙版提供"捏脸"系统，虚拟形象作为身份象征和社交名片——中国日报网《Soul App 正式发布鸿蒙版》 ↩︎
虚拟形象采用 glTF 2.0 为基础格式，通过扩展实现表情驱动——CSDN《HarmonyOS 6.0元宇宙社交开发》 ↩︎
将真实空间重建为 3D 模型分享给好友，社交内容从二维走向三维——中关村在线《HarmonyOS 3DGS 打开空间计算之门》 ↩︎
建议优先空间化改造的五类页面：首页/信息流、商品或内容详情页、个人中心/卡片、引导/Onboarding、设置/工具类页面——HarmonyOS 开发者社区征文活动说明 ↩︎
登录页、简单设置页、纯表单页等不适合空间化；空间化的本质是用空间关系组织信息——CSDN《HarmonyOS 7 空间化 UI 实战》 ↩︎ ↩︎
V2Fun 依托鸿蒙空间计算底层能力快速生成高精度 3D 资产模型，支持 AI 模型一键沉淀至华为图库——中国日报网《HDD 成都站》 ↩︎
API 26 Core Vision Kit 新增图像超分（端侧 4 倍高清放大）与文搜图（自然语言检索本地图片，全流程端侧闭环）——HarmonyOS 开发者社区征文活动说明 ↩︎
HarmonyOS 7 宣布迈入 Agent 时代，全新发布鸿蒙空间计算——华为官网《HarmonyOS 7 开发者 Beta 正式启动》 ↩︎