一、重建之前，先知道相机到底绕了几圈

有一类3DGS采集问题并不复杂，却经常在后期才被发现：操作界面一直显示正在拍摄，帧数量也持续增长，但镜头始终停留在物体正前方，背侧始终没有可靠视角。把这些帧直接交给重建流程，算法并不能凭空补齐缺失的表面。相比只把拍摄张数写在屏幕上，我更关心一个可解释的问题：已有视角覆盖了哪些方位，还有哪些方向需要补拍？

本文用一个独立的采集辅助页 OrbitCoverage 说明这件事。约定以目标物体为圆心，把水平环拍方位分成十二个三十度区间。输入十个有效的方位角，预期得到 COVERED 10/12、83.3%；90° 和 270° 起始的两个区间为空，因此页面显示 BLOCKED。

华为官方介绍了HarmonyOS空间计算与3DGS端侧重建能力，也提供专门的空间重建开发指导。但应用自定义的角度分桶并不是系统提供的“重建质量评分”API，它只是一个采集前后的业务辅助检查，真正重建仍需遵守空间能力的设备、权限、输入和流程要求。

二、先把角度契约说清楚

在设计数据结构前，必须回答方位角从哪里来。真实项目中的角度可以由可靠的相机姿态和目标坐标系换算；如果来源是一张手工清单，那么结果只能解释清单，不足以证明设备真的到了对应位置。这里为避免引入无法验证的姿态SDK签名，直接使用离线注入的方位角数组。字段 yaw 以度为单位，允许负值和超过一圈的等价角，但拒绝非有限数。id 是采集帧业务键，发生重复时要先解决数据来源，而不是悄悄当作新帧。

我们不按帧数计算覆盖率。某个方向拍一百张，仍只能让那个方向对应的一个方位桶变为已覆盖。方位桶按照左闭右开区间解释，例如 60° 落在 [60°,90°)，90° 落在 [90°,120°)。360° 与 0° 属于同一个桶。该约定必须在界面和数据层保持一致，否则接近边界的补拍提示会左右跳动。

第一段代码处理输入归一化与分桶，输出的编号是业务自定义的整型集合，不关联具体3DGS系统API。

interface CaptureFrame {
id: string;
yaw: number;
}

interface CoverageResult {
covered: number[];
missing: number[];
invalidIds: string[];
}

function normalizeYaw(degrees: number): number {
return ((degrees % 360) + 360) % 360;
}

function inspectCoverage(frames: CaptureFrame[]): CoverageResult {
const seenIds: Set<string> = new Set<string>();
const hit: Set<number> = new Set<number>();
const invalidIds: string[] = [];
frames.forEach((frame: CaptureFrame) => {
if (!frame.id || seenIds.has(frame.id) || !Number.isFinite(frame.yaw)) {
invalidIds.push(frame.id);
return;
}
seenIds.add(frame.id);
hit.add(Math.floor(normalizeYaw(frame.yaw) / 30));
});
const covered: number[] = Array.from(hit).sort((a, b) => a - b);
const missing: number[] = [];
for (let bucket = 0; bucket < 12; bucket++) {
if (!hit.has(bucket)) missing.push(bucket * 30);
}
return { covered, missing, invalidIds };
}

seenIds 保护帧身份，hit 保护覆盖统计，两者不能混为一谈。遇到同一个 id 重复上报，本例把第二次记为异常；如果业务需要允许覆盖替换，应先规定替换版本，再决定覆盖集合如何回滚。这里的 Math.floor 只在归一化之后执行，保证负角不会生成负桶。Set 自动去重，最终排序只是为了稳定展示。异常输入保留在 invalidIds，不能因“覆盖数看起来够了”就忽略。

三、让十二个方位桶与状态共用同一份结果

页面命名为 CoveragePage.ets。模型输入在示例中固定为十张示例帧：0、30、60、120、150、180、210、240、300、330 度。它们恰好使第三号和第九号桶为空，对应 90°、270°。按照上面函数的约定，covered.length 为10，missing.length 为2。前端不需要再独立写一套“根据角度猜颜色”的逻辑，否则数据清单和示意图可能出现两套统计口径。

第二段把检查结果接入ArkUI。为了保持示例简洁，只使用基本的 @State、ForEach、Column 与 Text 组件；环形图可在正式项目中替换为自绘组件，检测算法无需改变。

@Entry
@Component
struct CoveragePage {
private frames: CaptureFrame[] = [
{ id: 'F-101', yaw: 0 }, { id: 'F-102', yaw: 30 },
{ id: 'F-103', yaw: 60 }, { id: 'F-104', yaw: 120 },
{ id: 'F-105', yaw: 150 }, { id: 'F-106', yaw: 180 },
{ id: 'F-107', yaw: 210 }, { id: 'F-108', yaw: 240 },
{ id: 'F-109', yaw: 300 }, { id: 'F-110', yaw: 330 }
];
@State covered: number[] = [];
@State missing: number[] = [];
@State phase: string = 'WAITING';

aboutToAppear(): void { this.refreshCoverage(); }

private refreshCoverage(): void {
const report: CoverageResult = inspectCoverage(this.frames);
this.covered = report.covered;
this.missing = report.missing;
this.phase = report.invalidIds.length > 0 || report.missing.length > 0
? 'BLOCKED' : 'READY';
console.info(`OrbitCoverage COVERED ${report.covered.length}/12 ${this.phase}`);
}

build() {
Column({ space: 12 }) {
Text('OrbitCoverage · OrbitCoverage').fontSize(24).fontWeight(FontWeight.Bold)
Text(`COVERED ${this.covered.length}/12 · ${(this.covered.length / 12 * 100).toFixed(1)}%`)
Text(this.phase).fontColor(Color.Orange)
ForEach([0, 30, 60, 90, 120, 150, 180, 210, 240, 270, 300, 330],
(angle: number) => {
Text(`${angle}°  ${this.missing.includes(angle) ? 'MISSING' : 'OK'}`)
.fontSize(15)
}, (angle: number) => `${angle}`)
}.padding(20)
}
}

83.3% 在固定示例数据中是预期结果，实际文字由 covered.length / 12 * 100 动态格式化，不能随意硬编码。@State 更新会触发相关界面更新，aboutToAppear 用于加载当前示例输入。组件消失之后若存在真实监听、定时器或传感器订阅，应在相应生命周期内取消。

四、检查比“覆盖率好看”更重要的三个边界

首先，方位桶不是几何覆盖证明。即便十二区间全部被命中，相机仍可能俯仰角过高、拍摄距离波动、主体被遮挡或照片严重模糊。视角只有水平维度，无法替代基于相机位姿、图像质量和实际重建反馈的联合判断。这个工具应把结论写成“方位盲区提示”，不能写成“3DGS模型质量达标”。

其次，要警惕拍摄清单中重复写入的帧。相同ID用不同角度上报时，表面上可能补满盲区，实际是一次同步重放。当前处理将第二条丢进 invalidIds 并阻止最终状态变为READY；更严格的现场方案应为帧绑定采集会话、时间戳与来源轨迹，并明确是否允许覆盖。浮点精度也需要照顾，359.999° 会进入最后一桶，360.000° 会回到第一桶，这本来符合约定，不应误当系统bug。

第三，采集过程是持续变化的。实时预览若每收到一张帧就立刻刷新十二项和日志，可能在高频采集时产生不必要的界面重绘。应先在业务层合并相同桶的变化，再以稳定节奏更新 @State。如果引入异步文件列表或相机回调，还需要给当前采集会话加版本标识，防止上一轮清单的晚到帧写入新会话。

五、用离线断言核实预期输出

第三段代码是纯ArkTS层的自检用例，输入仍来自构造数据。它验证缺口的位置而非仅比较百分比，所以未来更改采集角度时，不能只看“覆盖了十个方向”就当通过。测试代码可以放在对应单测环境里，也可以作为开发期本地计算核对，不涉及设备传感器。

const checkFrames: CaptureFrame[] = [0, 30, 60, 120, 150,
180, 210, 240, 300, 330].map((yaw: number, index: number) => {
return { id: `F-${101 + index}`, yaw };
});
const report: CoverageResult = inspectCoverage(checkFrames);
const missingText: string = report.missing.join(',');
const expected: boolean = report.covered.length === 10 &&
missingText === '90,270' && report.invalidIds.length === 0;
console.info(`OrbitCoverage EXPECTED ${expected ? 'PASS' : 'FAIL'}`);

按上述输入推导，页面应出现“COVERED 10/12”“83.3%”“BLOCKED”以及 90° MISSING、270° MISSING 两条补拍提示；日志应描述同一业务编号。实际接入3DGS重建时，还要根据设备支持情况、用户授权、相机姿态来源以及官方接口的生命周期再做集成验证。

如果需要提高精度，可把水平方位桶扩展成“方位角×俯仰角”的二维格，并引入目标距离、画面模糊度、光照一致性等辅助质量项。不过桶越细并不等于越真实：估计姿态的误差可能比桶宽更大，导致盲区提示频繁跳变。应先依据业务可接受的角度误差设定采样策略，再讨论自动补拍路径。

除了角度统计，还可以给补拍建议增加一个“可信来源”字段：人工录入、姿态换算、批量导入应使用不同标记。由姿态换算得到的结果需要明确坐标系方向、相机朝向与物体中心的定义；人工录入只是工作记录，不能对外表达为视觉算法自动发现。建议把会话编号和原始输入快照一起存档，便于事后解释某次扫描为什么被挡下，也避免把修改后的角度清单误当成当时采集的数据。这个小约束会让质量检查的可追溯性提高很多。

六、工程落点与资料边界

本文核心价值不在十二个小格子，而在区分“采集到了很多帧”和“关键方位确实覆盖”。把样例角度经过归一化、去重、分桶、判缺四步，工程就有了一份能复核的辅助结果。对采集员来说，两处明确的补拍位置比一句含糊的“采集质量偏低”更容易执行；对研发来说，错误输入和重复帧都能追踪到来源，而不是依赖后期重建异常猜原因。

参考资料：华为开发者《空间计算能力》 https://developer.huawei.com/consumer/cn/features/spatialization%EF%BC%8C%E4%BB%A5%E5%8F%8A%E3%80%8A%E7%A9%BA%E9%97%B4%E9%87%8D%E5%BB%BA%E5%BC%80%E5%8F%91%E6%8C%87%E5%AF%BC%E3%80%8B https://developer.huawei.com/consumer/cn/doc/harmonyos-guides/spatial-recon-c-spatial-recon-pipeline%E3%80%82