HarmonyOS 7.0 / API 26 3DGS 采集质量门禁模糊帧、轨迹断点和重建失败如何提前拦住这篇只解决一个问题前面那篇 3DGS 文章讲的是任务队列、后台执行和失败回滚。这篇换一个角度只讲重建开始之前的采集质量门禁。3DGS 端侧重建最烦人的地方是用户拍了一圈应用跑了半天最后告诉他失败。这个体验很差开发侧也不好排查。我的处理思路是把失败尽量提前在采集阶段就把模糊帧、轨迹断点、光照突变和重复提交拦下来。验证环境和活动口径检查项说明系统方向HarmonyOS 7.0 / API 26满足 HarmonyOS 5.0.0 及以上活动范围文章方向HarmonyOS 新能力、端侧重建、应用性能稳定性核心问题3DGS 采集质量不够导致后续重建失败验证方式用采集帧质量、轨迹连续性、重建前检查三个阶段验证这篇不写成“概念介绍”。如果开发者照着做至少能得到一套可落地的质量门禁结构。问题怎么发生常见写法是用户点击开始后一路收集数据等采集结束再提交重建任务。这个流程看起来顺但问题也明显中间有几帧严重模糊最后才发现重建不稳定用户绕物体时轨迹断了算法输入已经不连续光照忽明忽暗纹理点不稳定用户重复点击提交后台出现两份互相覆盖的重建结果。这些问题如果放到最后处理成本很高。更好的做法是在采集阶段就给出提示让用户马上补拍、重拍或暂停。案例一模糊帧提前拦截用户移动设备太快时采集帧会出现明显模糊。这个时候不要继续装作一切正常而是记录 blurScore并把提示放到当前采集页。interface CaptureFrameQuality { frameId: string; blurScore: number; lightScore: number; trackingLost: boolean; timestamp: number; } type CaptureDecision accept | retry_current_angle | pause_and_hint; class GsCaptureQualityGate { decide(frame: CaptureFrameQuality): CaptureDecision { if (frame.trackingLost) { return pause_and_hint; } if (frame.blurScore 0.62) { return retry_current_angle; } if (frame.lightScore 0.35) { return retry_current_angle; } return accept; } }这段代码的重点不是分数本身而是不要把所有问题都推到重建阶段。采集阶段能判断的问题就在采集阶段解决。案例二轨迹断点不要硬拼另一个常见问题是轨迹断了。用户绕物体一圈中间突然对不上后面继续采集也只是把坏数据越堆越多。interface CapturePathState { acceptedFrames: number; lostCount: number; lastStableAt: number; } class CapturePathGuard { shouldContinue(state: CapturePathState): boolean { if (state.acceptedFrames 12 state.lostCount 2) { return false; } if (Date.now() - state.lastStableAt 5000) { return false; } return true; } }这里我宁愿让用户补拍也不愿意让他等一个大概率失败的重建结果。端侧能力越重越要提前控制输入质量。和任务队列那篇的区别文章关注点解决的问题任务队列和失败回滚重建任务开始之后怎么治理重复提交、后台执行、取消和回滚本文采集质量门禁重建任务开始之前怎么拦截坏输入模糊帧、轨迹断点、光照突变这两个方向不重复。一个是任务治理一个是输入治理。真实项目里两个都需要。我会怎么验收快速移动设备时页面能提示补拍当前角度轨迹连续失败时不继续提交重建任务光照变化太大时提示用户换光线或重新采集重复点击提交时只保留一条有效任务日志里能看到 frameId、decision、reason 和 timestamp。总结3DGS 端侧重建不是把按钮接上就结束。输入质量不稳定后面的队列、缓存、回滚都会被拖下水。我的建议是先做采集质量门禁再做重建任务队列。先把坏数据挡住再让好数据进入重建链路这样失败率和排查成本都会低很多。