一段商品环拍视频里有二十四个候选画面，采集页如果只是把“已采集 24 帧”写成绿色，很容易给人一种已经具备重建条件的错觉。可是镜头停顿、焦点失准和室内玻璃反光，都可能让数量充足的帧集变成质量不稳定的输入。我想讨论的不是把 3DGS 重建模型搬进这篇文章，而是更靠前、也更容易被忽略的一层：应用交付给重建流水线之前，怎样把帧级判断做成可以解释、可以中止的质量闸门。## 一、先把“采到了”和“能提交”分开示例叫 ScanFrameGate，用于给商品环拍的三维重建做一页采集质检。演示批次编号为 GS_20261017_03，输入二十四条预先构造的候选帧元数据；十八条通过，六条被剔除，界面显示 INPUT_READY。这些数字来自演示数据，不是实际手机摄像头、3DGS 算法或任何设备上的测量结果。业务上需要两个计数器。captured 表示采集事件被记录的次数，accepted 表示经过质量条件后可以进入下游候选列表的次数。两者不能混用。更不能把 INPUT_READY 误当成系统重建成功：它只说明本地规则检查通过，实际管线仍可能因为视角覆盖、特征不足或输入格式而拒绝。在这个方案里，我刻意不直接调用未核实的空间重建回调。华为公开介绍了 3DGS 端侧重建能力和相应应用场景，具体接入需要根据开发者可用 SDK、文档及设备能力确定。本文的代码范围是 ArkTS 业务侧帧元数据质检，其中清晰度、曝光误差和新颖度都是上游已计算好的归一化数值，绝非系统自动提供的字段。也就是说，评价规则可复用，采集算法和空间接口仍由实际工程另行接入。## 二、三个分数，分别回答三个不同问题画质闸门最常见的误区是制造一个无法解释的“总分”。焦点不清晰、曝光严重偏差与视角重复，本质上对应不同补采动作。把它们加权成八十分，反而很难告诉用户应该把镜头往哪边移。我更愿意让每条候选帧只能拿到一个主拒绝原因，并且把阈值记录在批次元数据里。示例约定 sharpness 越大代表越清晰，最小允许 0.62；exposureError 越小代表曝光偏差越弱，最多 0.30；novelty 越大代表与已接收帧的视角或视觉差异越大，最小 0.14。这三个数的分布仅供演示，并不代表 3DGS 官方推荐阈值。若项目采用其他评分模型，必须用自己的标注样本重新标定。下面这段代码解决“一个帧被拒绝时应当给出什么可读原因”的问题。ts// entry/src/main/ets/model/FrameJudge.etsexport interface FrameCandidate { id: string; timestampMs: number; sharpness: number; exposureError: number; novelty: number;}export type RejectReason = 'BLUR' | 'EXPOSURE' | 'DUPLICATE' | 'NONE';export function judgeFrame(f: FrameCandidate): RejectReason { if (f.sharpness < 0.62) { return 'BLUR'; } if (f.exposureError > 0.30) { return 'EXPOSURE'; } if (f.novelty < 0.14) { return 'DUPLICATE'; } return 'NONE';}顺序是一种业务决策：当一帧同时模糊又重复，界面先报“画面模糊”，因为用户只有先改善成像质量，才有必要判断视角信息量。换一个业务，这个优先级可能完全不同。输入为 NaN、超出零到一的范围、时间戳逆序或缺少 ID 时，上述基础判断还不够，因此正式工程还需要在进入判断器之前做 schema 校验，不能让不合法数值绕过比较操作。另一个容易误判的点是 novelty。它不是只比较上一帧的像素差，更合理的做法是与已经接收的代表帧集合比较。这里采用一个上游评分接口的结果字段，避免用一个伪造的图像相似度公式冒充已完成的视觉算法。界面提示“视角重复”只表示本地筛选规则的结论，不意味着重建模型最终认为它没有价值。## 三、把闸门做成批次状态机只有 judgeFrame 还不够。用户可能连点“完成”，后台却继续送来数个候选帧；也可能按下取消后，旧批次结果才到达。如果只根据列表长度判断是否提交，就可能把不同批次混入同一个输入集。我给每次采集分配独立批次 ID，先校验归属，再判断质量，最后决定是否关闭这一批输入。下面的管理器解决重复 ID、超量追加和关闭后仍接收帧的问题。它只保存轻量元数据，不持有原始图片像素或相机缓冲区，因此无法替代照片资源的释放逻辑。ts// entry/src/main/ets/model/FrameGate.etsimport { FrameCandidate, judgeFrame, RejectReason } from './FrameJudge';export class FrameGate { readonly batchId: string = 'GS_20261017_03'; readonly limit: number = 24; accepted: FrameCandidate[] = []; rejected: Map<string, RejectReason> = new Map(); state: string = 'COLLECTING'; private seen: Set<string> = new Set(); append(f: FrameCandidate): void { if (this.state !== 'COLLECTING' || this.seen.has(f.id)) { return; } if (this.seen.size >= this.limit) { return; } this.seen.add(f.id); const reason: RejectReason = judgeFrame(f); if (reason === 'NONE') { this.accepted.push(f); } else { this.rejected.set(f.id, reason); } } close(): void { if (this.state !== 'COLLECTING') { return; } this.state = this.accepted.length >= 18 ? 'INPUT_READY' : 'NEED_RECAPTURE'; } cancel(): void { this.state = 'CANCELLED'; this.accepted = []; this.rejected.clear(); this.seen.clear(); } get captured(): number { return this.seen.size; }}这里并没有声明 Set 和 Map 能做跨线程原子提交。真正的生产链路应当在同一个执行上下文串行投递帧状态，或者在任务边界添加消息代次；如果多个 Worker 同时修改同一批次，就需要把写入收敛到单一调度者。close() 的十八帧阈值也只是产品演示值。即使达到十八帧，也要额外检查环拍覆盖、模糊区域分布以及输入格式，不能直接启动未经审核的模型服务。图中的 DevEco、模拟器和 HiLog 是与代码字段对应的静态演示画面。左侧目录指出判断器和状态管理的位置，底部展示“收集—筛选—输入就绪”的期望事件序列。演示中的期望日志为 captured=24、accepted=18 rejected=6、BLUR=2 EXPOSURE=2 DUPLICATE=2、state=INPUT_READY，并非真机输出。正式调试时应把每条 append 的判断原因记录成结构化日志，并对原始图像路径做脱敏，避免把用户拍摄位置或素材 URI 原样写入线上日志。## 四、用确定性输入检查边界，而不是编一组实测帧率为了让审阅者不用设备也能核对数量关系，我准备了二十四条测试输入：第 4、10 帧人为设置清晰度不足；第 8、16 帧曝光误差超限；第 12、20 帧新颖度不足；其余十八帧满足本地闸门。它们是构造数据，不能据此推断摄像头稳定性或 3DGS 真实精度。第三段代码解决“同样的筛选逻辑，每次回归检查是否得到同样的数量和状态”的问题。ts// entry/src/main/ets/testing/GateFixture.etsimport { FrameCandidate } from '../model/FrameJudge';import { FrameGate } from '../model/FrameGate';export function runFixture(): FrameGate { const gate: FrameGate = new FrameGate(); for (let n = 1; n <= 24; n++) { const id: string = `F_${n.toString().padStart(3, '0')}`; const f: FrameCandidate = { id, timestampMs: n * 100, sharpness: (n === 4 || n === 10) ? 0.48 : 0.82, exposureError: (n === 8 || n === 16) ? 0.44 : 0.12, novelty: (n === 12 || n === 20) ? 0.05 : 0.36 }; gate.append(f); } gate.close(); return gate; // 预期 captured=24 accepted=18 rejected=6}这段代码的价值不是写出二十四次循环，而是可以把“不小心更改阈值”“重排拒绝原因优先级”“关闭后仍然追加”的问题转成可比较的断言。实际工程还应补充同 ID 重复、取消后重入、非法浮点、空批次和元数据异常的测试。对于 padStart 之类的语言特性也要以工程实际 ArkTS 编译配置为准；如果目标工具链的类型检查不接受某种语法，应做兼容替换，而不是把纸面代码宣称已经跑通。## 五、手机页面该怎样解释这十八帧我会把页面上部展示成一行明确的判断：GS_20261017_03、INPUT_READY、18/24 已接受。按演示规则折算的接受率为 75%，下面不是炫耀百分比的动画，而是三条可操作的原因提示：模糊两帧、曝光两帧、重复两帧。它们来自构造输入的逻辑计数，并非真实环境下的图像质量分布。“下一步：提交重建”按钮应当仍有前置校验：实际用户点击前要完成授权状态、素材格式、模型包可用性和设备能力的确认。若没有接入真实的重建 SDK，按钮只能进入演示说明页，绝不能向用户展示虚构的重建进度条。当前截图中的按钮文案使用“检查完成”，就是为了把筛选完成和系统重建完成分开。如果产品允许中断采集，取消行为必须同时处理原始文件句柄、图像缓存、正在执行的评分任务和尚未消费的事件。当前 cancel() 清理的只有业务侧数组与集合，图像缓冲区仍应由拥有该资源的组件负责释放。不要让“业务列表空了”成为“内存已经回收”的证据。## 六、从业务闸门走向真实 3DGS，至少还要补哪几步第一是分数来源。清晰度可能使用梯度统计或学习模型，曝光误差可以根据亮度分布产生，而新颖度需要考虑视角覆盖而不是单纯像素差。本文不把这些指标包装成 HarmonyOS 内置 API；接入时要明确模型版本、分数范围、边界样本和设备计算成本，并给各环节设置超时。一个采集质量闸门如果在主线程执行昂贵图像分析，可能让取景预览出现卡顿，反而破坏采集体验。第二是回收原则。相机采集、PixelMap、压缩编码和 3DGS 输入组装属于不同资源所有者。判断器只保留 ID 与数值，原图是否存盘由素材仓库决定；提交下游后是否允许删除缓存，需要下游确认接收成功。对失败重试使用同一个批次号，必须同时带上尝试序号，防止旧回调覆盖新一轮的 INPUT_READY 状态。第三是验收口径。正式验证不是看图上是不是十八帧，而是用一组带标注的真实样本计算误拒与漏拒，再检查在光线突变、环拍中途暂停、应用后台化后的恢复表现。如果技术团队拿不到可靠的质量标签，宁可把闸门设成软提醒，也不要把不确定判断做成用户无法越过的硬阻断。华为关于 3DGS 的公开资料为能力与适用场景提供了依据，本文代码使用通用 ArkTS 数据结构，不声称包含官方重建调用。具体的空间计算接入范围、设备要求和权限，应以所使用 SDK 对应版本的官方指导为准。当前没有 DevEco 编译记录或真机采集数据，截图和数值均为设计演示。真正能带走的工程结论是：输入数量、输入质量与重建完成状态应由三个不同的判定层承担，任何一层都不应替另外一层作出承诺。资料参考： 华为开发者联盟《空间计算能力接入》；《3DGS 端侧重建管线》（具体接口需以项目可访问版本核对）。