任务进度在主页面显示为百分之六十四，闪控窗里只有一行简化文字和一个“暂停任务”按钮。用户点下去以后，按钮立即变成了“暂停中”。这一步看起来很顺畅，但真正麻烦的是：如果任务在另一端已经推进到了版本九，而闪控窗仍持有版本八，暂停请求可能被服务端拒绝。界面这时不能继续假装任务已暂停，也不能把新进度覆盖回旧值。本文选择一个可重复推演的演示样例，不宣称遇到过真实线上故障。Demo 叫 FloatCommand，页面为 FloatActionPage。演示任务 ORDER-417 在 18:24 从修订版本 rev=8、进度 64% 发起暂停指令 C-417；服务端返回 REVISION_CONFLICT，附带 rev=9、进度 67%、仍在 RUNNING 的权威快照。最终页面文字应是“已恢复进行中”，而不是“暂停成功”。## 一、暂停按钮不等于暂停结果闪控窗适合承载紧凑而明确的操作入口：看到正在进行的任务，立即进行必要的控制。它却不应该成为任务事实的第二份来源。创建与维护闪控窗，是系统表现层的问题；用户点击后能否暂停，是业务服务层的问题。两者如果混写，最常见的结果就是界面响应很快，数据却在多个入口之间互相覆盖。我把一次操作拆成四个时刻：用户点击、页面进入乐观态、权威结果返回、最终显示收敛。乐观态允许按钮立即反馈，但它的文字必须是“暂停中”，不能提前写成“已暂停”。只有服务端确认暂停成功，而且返回的新快照合法，才可以显示终态。另一个约束容易漏掉：闪控窗的内容可能被销毁、重新创建，或主页面与闪控窗同时存在。不能用某个组件实例保存“唯一事实”，也不能在两个页面各自维护独立的 isPaused。更稳妥的做法是由应用业务层持有权威快照、待确认指令和最近一次冲突原因，各个 UI 只订阅投影后的状态。这里的 FloatViewController 是本文讨论的闪控窗集成边界；下面代码重点实现与窗口系统解耦的 ArkTS 业务仲裁。官方文档确认该闪控窗接口家族存在，但具体创建参数、支持模板与设备条件必须按目标 SDK 的参考页面实施。本文不拿一个未经核验的 create() 参数对象充数。## 二、先固定契约，再谈按钮动画演示协议只有一个任务和一条待确认命令，故意不引入复杂的事件总线。revision 是任务权威版本，不是 UI 刷新次数；commandId 用来判断哪条应答归属于哪次用户操作；progress 始终来自最新权威快照；presentation 只描述页面暂时该怎样显示。把四者混成一个布尔值，就无法表达“正在请求暂停，但服务器仍然处于运行中”的状态。下面先给出类型约束。这段代码解决的是“一个状态字段承担过多含义”的问题，普通 ArkTS 类型和纯业务数据即可表达，不依赖不可验证的系统回调。tsexport type RunState = 'RUNNING' | 'PAUSED';export type ViewState = 'RUNNING' | 'PAUSING' | 'PAUSED' | 'CONFLICT';export interface TaskSnapshot { taskId: string; revision: number; progress: number; runState: RunState;}export interface PauseCommand { commandId: string; taskId: string; expectedRevision: number;}export interface PauseReply { commandId: string; accepted: boolean; reason: string; actual: TaskSnapshot;}这里没有让 ViewState 混进 TaskSnapshot，因为后者代表业务服务端的事实，前者是可丢弃的表现层状态。expectedRevision 必须由发起时的权威版本取得，不能从被动画修改过的“页面版本号”倒推。progress 的允许范围应在服务端和应用边界两次验证；样例只使用已经校验过的整数百分比。真实系统还应对任务所有权、登录态、操作权限做校验。## 三、乐观态只承诺反馈，不承诺成功页面点击时允许先把按钮置灰、显示“正在确认暂停”，但不得改写权威任务状态。等应答到达后，再以服务端版本为准更新展示。最重要的异常分支是：应答的 commandId 不等于当前待处理指令，或者应答携带的版本比当前快照更旧。前者意味着它属于另一轮操作，后者意味着它不够新，都不能直接覆盖当前 UI。下面是演示业务层的核心。它没有发真实网络请求；beginPause 和 resolve 只负责应用本地的状态仲裁，网络、超时、授权与窗口生命周期都应在集成层补齐。tsexport class PauseArbiter { private current: TaskSnapshot; private pendingId: string = ''; private viewState: ViewState = 'RUNNING'; constructor(initial: TaskSnapshot) { this.current = initial; } beginPause(commandId: string): PauseCommand | null { if (this.pendingId !== '' || this.current.runState !== 'RUNNING') { return null; } this.pendingId = commandId; this.viewState = 'PAUSING'; return { commandId: commandId, taskId: this.current.taskId, expectedRevision: this.current.revision }; } resolve(reply: PauseReply): void { if (reply.commandId !== this.pendingId || this.pendingId === '') { return; } this.pendingId = ''; if (reply.actual.taskId !== this.current.taskId || reply.actual.revision < this.current.revision) { this.viewState = 'CONFLICT'; return; } this.current = reply.actual; this.viewState = reply.accepted && reply.actual.runState === 'PAUSED' ? 'PAUSED' : 'CONFLICT'; } snapshot(): TaskSnapshot { return this.current; } presentation(): ViewState { return this.viewState; }}这段代码有意不用“失败后恢复点击前缓存”的办法。因为点击前缓存只有版本八，而服务端已经返回版本九；将旧缓存写回，就会把百分之六十七错误地降回六十四。正确的回滚是撤掉乐观态，以更新的权威快照重建 UI，而不是简单恢复旧画面。CONFLICT 也不等于系统异常关闭，它是本次业务指令未被接受的显示结论。实际服务还需提供幂等语义，同一个 commandId 的多次传输不能导致重复暂停。这里的类只防止当前 UI 的并发点击，不可替代服务端幂等与身份鉴权。组件退出时应取消订阅并避免把旧组件回调写入新界面；请求是否允许继续，应由任务服务决定，而不是默认在窗口关闭时取消业务操作。## 四、把冲突显示成可执行的下一步演示页只保留三个可见信息：任务名、权威进度、最近一次操作解释。按钮文案依 presentation() 决定，而不是依靠网络 Promise 是否结束。为了让读者看清流程，第三段代码用本地固定应答复现冲突，不包含真实后台调用。```ts@Entry@Componentstruct FloatActionPage { private arbiter: PauseArbiter = new PauseArbiter({ taskId: ‘ORDER-417’, revision: 8, progress: 64, runState: ‘RUNNING’ }); @State title: string = ‘任务进行中 · 64%’; @State status: string = ‘等待操作’; @State canPause: boolean = true; private demonstratePause(): void { const cmd = this.arbiter.beginPause(‘C-417’); if (cmd === null) { return; } this.status = ‘暂停中 · C-417’; this.canPause = false; Promise.resolve().then(() => { this.arbiter.resolve({ commandId: ‘C-417’, accepted: false, reason: ‘REVISION_CONFLICT’, actual: { taskId: ‘ORDER-417’, revision: 9, progress: 67, runState: ‘RUNNING’ } }); const actual = this.arbiter.snapshot(); this.title = 任务进行中 · ${actual.progress}%; this.status = ‘已恢复进行中 · rev9 · 版本冲突’; this.canPause = true; }); } build() { Column({ space: 14 }) { Text(‘FloatCommand · ORDER-417’).fontSize(18); Text(this.title).fontSize(23).fontWeight(FontWeight.Bold); Text(this.status).fontSize(14); Button(‘暂停任务’) .enabled(this.canPause) .onClick(() => this.demonstratePause()); }.padding(22).width(‘100%’); }}````Promise.resolve() 是为了演示“先有请求态、后有应答态”的事件顺序，并非网络请求实现；图片中的 HiLog 也只是与这套示例一致的预期日志。把它换成真实接口前，应在服务调用边界对超时和断网分别设计“未知是否执行”的状态，不能把超时等价成未暂停。发生版本冲突后，页面应显示最新任务修订与建议重新获取，而不是无限自动重试同一个旧版本。![](https://i-blog.csdnimg.cn/direct/89bbfcc45cd64e1996a5c1f77d3323c5.png)## 五、演示对照：错误结果必须能被看出来预期演示日志按时间推进：18:24:01 ORDER-417 rev=8 progress=64 RUNNING；18:24:02 C-417 PAUSING expectedRev=8；18:24:03 C-417 REVISION_CONFLICT actualRev=9 progress=67；最后为 18:24:03 UI RUNNING 67% conflict=1 applied=0。这些值是预设案例而非真机采集结果，作用是检验业务代码与界面说明之间是否一致。在演示完成态中，闪控窗入口不应挂着“已暂停”的绿色标记；主页面与紧凑视图都应显示 ORDER-417、百分之六十七和版本冲突。用户可选择重新读取任务状态，再决定是否再次请求暂停。若服务端返回已经处于 PAUSED的更新快照，页面才展示“已暂停”。主页面更新也不能强行覆盖仍在执行中的新指令，只能进入统一的业务仲裁器。![](https://i-blog.csdnimg.cn/direct/4fd4084ff7e8405d83b1424e39538d6d.png)## 六、验证路径和边界调试时最先检查的是操作前后的revision：客户端发出的 expectedRevision 与服务器判定使用的版本是否一致。随后检查 commandId对应关系，再检查实际runState与界面ViewState` 有没有被误当作同一件事。为了发现旧应答污染，还需要构造“先到达较新快照，后到达旧命令应答”的情况。日志记录命令 ID、任务 ID、版本与裁决即可，不应包含访问令牌、用户姓名或完整业务凭据。接入真正的 Float View 还必须在支持机型上验证窗口出现、缩小、销毁、权限变化与页面重建。该部分与本篇业务仲裁无关，所以没有伪造控制器构建参数或声称跑通设备。华为官方提供 闪控窗开发指南 和 floatView API 参考，正式接入时须按目标 API 版本逐项复核。这一问题的关键不在按钮是否立即变灰，而在于“立即反馈”和“权威生效”之间是否留有清晰边界。**乐观态能被撤销，权威版本不能被旧界面回滚。**这是紧凑窗口与完整页面共享操作状态时最值得写入代码审查清单的一条规则。