HarmonyOS 7.0 / API 26 3DGS 端侧重建任务压测：点云采集、后台队列和失败回滚如何设计

HarmonyOS 7.0 / API 26 3DGS 端侧重建任务压测：点云采集、后台队列和失败回滚如何设计

先把问题说清楚

3DGS 重建一旦放到端侧，最容易出问题的不是算法名词，而是采集阶段、任务阶段、失败阶段没有边界。 这类问题看起来像一个新能力适配问题，真正写代码时会变成三件事：什么时候能用、失败时怎么退、结果怎么验证。

我这篇不按功能介绍来写，而是按排查顺序写。先确定 HarmonyOS 7.0 / API 26 的能力边界，再做两个能复现的场景，最后把处理逻辑收口成一个小封装。这样以后换到别的页面或者别的设备形态，也能沿用同一套判断方式。

官方能力点先对齐

这里最容易踩坑的是把“能调通”当成“能上线”。能调通只说明主路径没问题，真正上线前还要看失败路径、降级路径、日志字段和多设备边界。

验证环境和复现口径

这篇按 HarmonyOS 7.0 / API 26 的开发口径来拆，不写成泛泛的概念介绍。为了避免方案只停在文字上，我把验证范围先定死：

• 版本口径：HarmonyOS 7.0 / API 26，兼容活动要求里的 HarmonyOS 5.0.0 及以上技术分享范围。
• 验证入口：先用一个独立 controller 跑状态流，再接到 ArkUI 页面。
• 复现方式：主路径跑一次，重复进入跑一次，能力不可用或中断场景再跑一次。
• 回归标准：状态顺序不能乱，失败原因必须能在日志里看到，页面不能出现旧任务回写新状态。

如果这四点做不到，就算文章里把特性名称写得再新，也不能算真正解决开发问题。

问题是怎么发生的

以前容易把重建按钮当成一次普通提交，点击后只等结果，失败了给一个通用错误。

这个写法短期看很快，但只要遇到状态变化，就会暴露问题。比如设备能力变化、窗口尺寸变化、任务中断、用户重复点击、后台恢复、审核材料检查，这些都不是主路径能覆盖的。

我一般会把它拆成四个阶段：

• 第一阶段：先判断版本、设备和上下文，不直接执行重逻辑。
• 第二阶段：把任务状态写清楚，避免重复进入。
• 第三阶段：执行过程中保留取消、降级和失败原因。
• 第四阶段：回到页面以后用日志和可见状态验收。

案例一：主路径可复现

用户连续点击两次重建，第二次必须复用或拒绝已有任务，不能并发写同一份输出目录。

这类场景的关键不是多写 if，而是让状态机挡住错误顺序。下面这个小封装保留了 stage、reason、traceId 和 updatedAt，排查时能看到每一步发生了什么。

type Stage = 'idle' | 'checking' | 'running' | 'fallback' | 'done' | 'failed'; interface RebuildJobQueueState { stage: Stage; reason?: string; traceId: string; updatedAt: number; } class RebuildJobQueue { private current: RebuildJobQueueState = { stage: 'idle', traceId: 'trace-' + Date.now(), updatedAt: Date.now() }; start(scene: string): RebuildJobQueueState { if (this.current.stage === 'running') { return this.fail('已有任务正在执行，拒绝重复进入'); } this.current = { stage: 'checking', traceId: scene + '-' + Date.now(), updatedAt: Date.now() }; return this.current; } run(): RebuildJobQueueState { if (this.current.stage !== 'checking') { return this.fail('状态顺序不对，先检查再执行'); } this.current.stage = 'running'; this.current.updatedAt = Date.now(); return this.current; } fallback(reason: string): RebuildJobQueueState { this.current.stage = 'fallback'; this.current.reason = reason; this.current.updatedAt = Date.now(); return this.current; } done(): RebuildJobQueueState { this.current.stage = 'done'; this.current.updatedAt = Date.now(); return this.current; } private fail(reason: string): RebuildJobQueueState { this.current.stage = 'failed'; this.current.reason = reason; this.current.updatedAt = Date.now(); return this.current; } }

这段代码不依赖页面组件，所以可以先用普通 ArkTS/TypeScript 思路验证状态流，再接到 ArkUI 页面里。页面只负责展示状态，不应该直接决定任务能不能继续。

案例二：失败和降级路径

重建到 60% 时应用退后台，任务要能取消、保存进度，回到前台后给出继续或重来的选择。

失败路径一定要有明确的 reason。没有 reason 的失败提示，开发阶段不好排查，上线后用户也不知道该重试、切换设备，还是返回上一页。

const flow = new RebuildJobQueue(); console.info('case-a-start', JSON.stringify(flow.start('case-a'))); console.info('case-a-run', JSON.stringify(flow.run())); console.info('case-a-done', JSON.stringify(flow.done())); const conflict = new RebuildJobQueue(); conflict.start('case-b'); conflict.run(); console.info('case-b-repeat', JSON.stringify(conflict.start('case-b-repeat'))); console.info('case-b-fallback', JSON.stringify(conflict.fallback('能力不可用，进入降级链路')));

预期日志大概是这样：

case-a-start stage=checking case-a-run stage=running case-a-done stage=done case-b-repeat stage=failed reason=已有任务正在执行，拒绝重复进入 case-b-fallback stage=fallback reason=能力不可用，进入降级链路

为什么我选状态机，而不是到处写布尔值

我更倾向第三种。HarmonyOS 7.0 / API 26 的新能力越来越多，很多能力都不是一次性调用就结束，而是有环境判断、执行过程、降级策略和验证结果。状态机不是为了显得复杂，是为了让排查变得可控。

接到 ArkUI 页面时注意什么

页面层建议只做三件事：

• 显示当前 stage，让用户知道是在检查、执行、降级还是失败。
• 根据 reason 给出下一步操作，比如重试、切换设备、继续普通模式。
• 在 aboutToDisappear 或页面切换时处理取消和回收，避免旧任务回写新页面。

一个比较稳的写法是把能力判断和任务控制放在 controller 里，页面只订阅结果。这样后面换成折叠屏、平板、鸿蒙电脑窗口，页面结构变了，核心策略也不用跟着重写。

验收清单

最后总结

3DGS端侧重建 这类 HarmonyOS 7.0 / API 26 能力，文章和代码都不能只写主路径。真正有价值的是把问题怎么发生、怎么复现、怎么降级、怎么验证讲清楚。

我的判断标准很简单：如果这段方案以后换一个页面还能复用，日志里也能查到失败原因，那它才算工程上站得住。