HarmonyOS 3DGS 端侧重建解读：从采集向导到重建队列、预览渲染和性能边界

3DGS 很容易被写成“端侧三维重建很酷”。但真正做应用时，开发者遇到的不是概念问题，而是工程问题：用户怎么拍才算有效采集，哪些帧应该丢弃，重建任务要不要排队，预览时帧率和发热怎么控制，失败后怎么告诉用户重新补拍。

这篇文章只解决一个具体问题：如果要在 HarmonyOS 应用里设计一条 3DGS 端侧重建链路，应用层应该如何组织采集、筛帧、重建、预览和性能验证。

本文不会夸大能力，也不把算法细节写成伪代码。我们站在应用工程角度，重点看四件事：

1. 采集阶段如何引导用户拿到可用素材。
2. 重建阶段如何用任务状态机避免页面失控。
3. 预览阶段如何控制帧率、内存和发热。
4. 失败场景如何回退到补拍或低清预览。

一、先定边界：3DGS 不是“拍一张图变 3D”

3DGS 端侧重建依赖多视角素材、足够纹理、稳定光照和可控设备性能。应用层不能假设用户随手拍一下就能得到可用模型。

条件	对结果的影响	应用层该做什么
多视角覆盖不足	模型缺面、漂浮、孔洞	用采集向导提示绕拍
光照变化大	颜色不稳定、重建噪声	提示保持光照稳定
运动模糊	关键帧质量差	采集时做模糊过滤
设备性能不足	预览掉帧、发热	降级预览质量
任务中断	半成品不可用	保存任务状态并允许重试

用户关心的是“我怎么拍才能成功”，不是算法名称。3DGS 应用第一步应该做采集体验，而不是直接放一个重建按钮。

二、资料与版本边界：本文写应用层链路，不替代算法 SDK

本文示例面向 HarmonyOS NEXT / ArkTS 工程，围绕空间重建类能力、相机采集、任务编排和渲染预览做应用层设计。具体重建算法、SDK 参数和设备支持范围，应以当前官方文档和 SDK 为准。

层级	本文关注	不展开
采集层	采集向导、帧质量、角度覆盖	相机底层算法
重建层	任务状态机、队列、失败回退	3DGS 内部训练算法
预览层	LOD、帧率、内存、发热	图形引擎底层实现
验证层	质量指标、性能记录	学术指标推导

应用层的关键不是“实现 3DGS 算法”，而是把用户采集、重建任务和端侧预览组织成稳定体验。

三、采集任务建模：先让素材可用

采集任务要记录对象、角度、帧质量和设备环境。不要只保存一串图片路径。

export type CaptureStep = 'prepare' | 'capturing' | 'quality-check' | 'ready' | 'failed';

export interface CaptureFrame {
  frameId: string;
  uri: string;
  angleDegree: number;
  blurScore: number;
  lightScore: number;
  timestamp: number;
}

export interface ReconstructionCaptureSession {
  sessionId: string;
  objectName: string;
  step: CaptureStep;
  frames: CaptureFrame[];
  createdAt: number;
}

这段模型的意义：

1. angleDegree 用来判断视角覆盖，不只是保存图片。
2. blurScore 和 lightScore 让应用层能筛掉差帧。
3. step 让页面状态可控，避免“采集中”和“检查中”混在一起。
4. sessionId 串起采集、重建和预览日志。

真实项目中，清晰度和光照数值可以来自相机能力、图像分析模块或 SDK 回调。应用层只需要定义好接收和判断边界。

四、采集向导：用覆盖率提示用户补拍

用户不会天然知道 3DGS 需要怎样的多视角。应用可以按角度桶判断覆盖率。

export interface CaptureCoverage {
  totalBuckets: number;
  coveredBuckets: number;
  missingAngles: number[];
  ready: boolean;
}

export function calculateCoverage(frames: CaptureFrame[]): CaptureCoverage {
  const bucketSize = 30;
  const totalBuckets = 12;
  const buckets = new Set<number>();

  for (const frame of frames) {
    if (frame.blurScore < 0.65 || frame.lightScore < 0.6) {
      continue;
    }
    buckets.add(Math.floor(frame.angleDegree / bucketSize));
  }

  const missingAngles: number[] = [];
  for (let index = 0; index < totalBuckets; index++) {
    if (!buckets.has(index)) {
      missingAngles.push(index * bucketSize);
    }
  }

  return {
    totalBuckets,
    coveredBuckets: buckets.size,
    missingAngles,
    ready: buckets.size >= 10
  };
}

这段代码不是算法标准，而是产品向导：告诉用户“还差哪些角度”。如果覆盖不足就直接重建，后面失败率会很高，用户也不知道错在哪里。

五、帧筛选：差帧进入重建，只会浪费时间

采集完成后，先筛帧。模糊、过暗、重复角度太多的素材，都应该在应用层提示用户处理。

export interface FrameFilterResult {
  accepted: CaptureFrame[];
  rejected: CaptureFrame[];
  reasonMap: Record<string, string>;
}

export function filterFrames(frames: CaptureFrame[]): FrameFilterResult {
  const accepted: CaptureFrame[] = [];
  const rejected: CaptureFrame[] = [];
  const reasonMap: Record<string, string> = {};

  for (const frame of frames) {
    if (frame.blurScore < 0.65) {
      rejected.push(frame);
      reasonMap[frame.frameId] = '画面模糊，建议重新采集';
      continue;
    }

    if (frame.lightScore < 0.6) {
      rejected.push(frame);
      reasonMap[frame.frameId] = '光照不足或变化过大';
      continue;
    }

    accepted.push(frame);
  }

  return { accepted, rejected, reasonMap };
}

这段代码的价值是把失败提前。重建耗时通常比筛帧高，差帧越早被拦截，用户等待越少，设备发热也越低。

六、重建任务状态机：不要让页面猜任务进度

重建过程可能很长，页面不能靠一个 loading 变量撑到底。

export type RebuildStatus =
  | 'waiting'
  | 'preparing'
  | 'reconstructing'
  | 'optimizing'
  | 'preview-ready'
  | 'failed'
  | 'cancelled';

export interface RebuildTask {
  taskId: string;
  sessionId: string;
  status: RebuildStatus;
  progress: number;
  acceptedFrameCount: number;
  modelUri?: string;
  errorMessage?: string;
}

export function updateTaskProgress(
  task: RebuildTask,
  status: RebuildStatus,
  progress: number
): RebuildTask {
  return {
    ...task,
    status,
    progress: Math.max(0, Math.min(progress, 100))
  };
}

状态机解决三个问题：

1. 页面能准确展示“准备中、重建中、优化中、可预览”。
2. 任务失败时能保留错误信息。
3. 用户取消时不会和失败状态混淆。

3DGS 类任务最怕“转圈等结果”。状态拆清楚，用户等待时才知道发生了什么。

七、重建队列：端侧任务要控制并发

端侧重建很消耗 CPU、GPU、内存和电量。不要允许多个重建任务同时跑。

export class RebuildQueue {
  private runningTaskId?: string;
  private waitingTasks: RebuildTask[] = [];

  enqueue(task: RebuildTask): void {
    this.waitingTasks.push(task);
  }

  next(): RebuildTask | undefined {
    if (this.runningTaskId || this.waitingTasks.length === 0) {
      return undefined;
    }

    const task = this.waitingTasks.shift();
    this.runningTaskId = task?.taskId;
    return task;
  }

  finish(taskId: string): void {
    if (this.runningTaskId === taskId) {
      this.runningTaskId = undefined;
    }
  }
}

这段队列很简单，但能防止一个严重问题：用户连续点多个对象重建，设备同时跑多个高负载任务。端侧重建要先稳，再谈快。

八、预览渲染：根据设备状态选择 LOD

重建完成后，预览也不能无脑最高质量。需要根据设备温度、帧率、内存选择不同 LOD。

export type PreviewQuality = 'low' | 'medium' | 'high';

export interface PreviewDeviceState {
  fps: number;
  memoryMb: number;
  thermalLevel: 'normal' | 'warm' | 'hot';
}

export function resolvePreviewQuality(state: PreviewDeviceState): PreviewQuality {
  if (state.thermalLevel === 'hot' || state.fps < 45 || state.memoryMb > 700) {
    return 'low';
  }

  if (state.thermalLevel === 'warm' || state.fps < 55) {
    return 'medium';
  }

  return 'high';
}

预览降级不是偷工减料，而是保护体验。用户更能接受“低清但流畅”，不容易接受“高清但卡顿、发热、闪退”。

九、失败回退：告诉用户要补哪一段

重建失败时，不要只提示“重建失败”。要告诉用户是覆盖不足、画面模糊、光照问题，还是设备性能不足。

export type RebuildFailReason =
  | 'coverage-not-enough'
  | 'too-many-blur-frames'
  | 'low-light'
  | 'device-overload'
  | 'unknown';

export interface RebuildFailureAdvice {
  reason: RebuildFailReason;
  message: string;
  retryable: boolean;
}

export function getFailureAdvice(reason: RebuildFailReason): RebuildFailureAdvice {
  const map: Record<RebuildFailReason, RebuildFailureAdvice> = {
    'coverage-not-enough': { reason, message: '视角覆盖不足，请围绕物体补拍缺失角度', retryable: true },
    'too-many-blur-frames': { reason, message: '模糊帧过多，请放慢移动速度重新采集', retryable: true },
    'low-light': { reason, message: '光照不足，请在稳定光照下重新采集', retryable: true },
    'device-overload': { reason, message: '设备负载较高，建议稍后重试或使用低清预览', retryable: true },
    'unknown': { reason, message: '重建未完成，请保存素材后稍后重试', retryable: true }
  };
  return map[reason];
}

失败提示越具体，用户越愿意继续尝试。3DGS 应用不是一次失败就结束，而是要引导用户补齐采集条件。

十、性能记录：别只看模型有没有出来

3DGS 应用验收不能只看“模型生成了”。还要记录耗时、帧率、内存、温度和失败率。

export interface RebuildPerformanceRecord {
  sessionId: string;
  frameCount: number;
  rebuildSeconds: number;
  previewFps: number;
  peakMemoryMb: number;
  thermalLevel: string;
  success: boolean;
}

export function acceptedForDemo(record: RebuildPerformanceRecord): boolean {
  return record.success
    && record.previewFps >= 50
    && record.peakMemoryMb <= 800
    && record.rebuildSeconds <= 180;
}

这里的阈值要按设备和业务调整。它的作用是建立验收思路：采集质量、重建速度和预览流畅度要一起看。

十一、常见问题排查：先看采集，再看重建

现象	优先怀疑	检查方法	修复方向
模型缺面	视角覆盖不足	查看 missingAngles	引导补拍缺失角度
模型噪点多	模糊帧或光照不稳	查看筛帧结果	拒绝差帧进入重建
重建中途失败	设备负载高或任务被打断	查任务状态机	加队列和恢复机制
预览掉帧	LOD 过高	看 FPS 和内存	降低预览质量
用户不知道怎么补救	失败提示太泛	看错误文案	给出补拍建议
连续重建发热	并发任务过多	查队列状态	限制同时运行任务

排查顺序不要反过来。很多“算法失败”其实是采集失败，很多“预览卡顿”其实是没有做 LOD。

十二、3DGS 上线前体验验收表

检查项	通过标准
采集向导可用	用户知道怎么绕拍和补拍
帧质量可筛选	模糊、低光照素材不会直接进入重建
任务状态清晰	页面能显示重建阶段和进度
重建并发受控	同一时间只有可控任务运行
预览可降级	帧率低或发热时能降 LOD
失败提示具体	用户知道下一步怎么补救
性能有记录	耗时、FPS、内存、温度都有数据

3DGS 端侧能力越强，越要把用户路径写清楚。否则能力看起来先进，体验却容易不稳定。

十三、推荐落地顺序

如果你要从零开始做，可以按这个顺序：

1. 先做采集向导，不急着接重建。
2. 建立帧质量和角度覆盖判断。
3. 写重建任务状态机和队列。
4. 接入重建能力或 SDK。
5. 做低、中、高三档预览质量。
6. 增加失败提示和补拍入口。
7. 最后用性能记录做端侧验收。

这个顺序能把风险前置。采集不稳定时，不要急着调重建参数；预览不稳定时，不要直接提高模型质量。

十四、3DGS 与端侧重建相关资料

1. 华为开发者文档：空间重建相关能力
   https://developer.huawei.com/consumer/cn/doc/
2. 华为开发者文档：相机服务
   https://developer.huawei.com/consumer/cn/doc/harmonyos-guides/camera
3. 华为开发者文档：图形与渲染相关能力
   https://developer.huawei.com/consumer/cn/doc/harmonyos-guides/graphics
4. 华为开发者文档：性能调优
   https://developer.huawei.com/consumer/cn/doc/harmonyos-guides/performance

十五、把 3DGS 做成稳定体验，而不是一次炫技

3DGS 端侧重建的应用价值不只在模型生成那一刻，而在完整链路：采集可引导、素材可筛选、任务可恢复、预览可降级、失败可补救。应用层把这些边界做稳，用户才会觉得这项能力可靠，而不是“偶尔成功的一次演示”。

最后可以用下面这张表做一次工程复盘：

问题	稳定做法
用户不知道怎么拍	采集向导提示角度覆盖和补拍位置
重建前素材不可用	先筛掉模糊帧、低光照帧和重复角度
重建过程页面失控	用任务状态机展示阶段和进度
设备发热或预览卡顿	按 FPS、内存、温度选择 LOD
失败后用户无从下手	给出补拍、降级预览或稍后重试建议

这五个问题都能回答，3DGS 功能才更接近真实可用，而不是只适合演示环境。