HarmonyOS 6.1+ 新特性实战(14):后台任务生命周期与重复启动保护方案
后台下载最危险的状态不是失败,而是页面显示“已停止”,系统任务仍在运行;或者用户连续点击两次开始,产生两个通知和两条上传会话。后台能力必须由一份持久化任务记录驱动,页面只是控制器。
方案面向HarmonyOS 6.1.1 Release SDK(API 24),系统Kit调用进入适配层,命令约束、状态归并和恢复策略进入可测试的业务层。范围包含状态与资源生命周期设计、失败恢复和验收合同,不包含业务内容生产、服务端协议改造以及特定厂商网页或媒体源的兼容承诺。

后台运行先满足用户可感知
方案定义taskId、业务类型、系统任务Id、进度、更新时间和ownerPage。开始按钮先查询活动记录,存在相同业务键时只恢复订阅,不再次申请。停止动作先标记STOPPING,再撤销系统任务并关闭网络会话;只有两侧都完成才进入STOPPED。
状态数量不是越多越好。每个状态必须回答三个问题:当前允许哪些命令、收到迟到事件怎样处理、页面退出后是否还可以更新UI。下面的状态对象携带operationId,新的操作开始后,旧操作回调会被拒绝。
export enum BackgroundJobState {
IDLE = 'idle',
STARTING = 'starting',
ACTIVE = 'active',
SUSPENDED = 'suspended',
STOPPING = 'stopping',
STOPPED = 'stopped'
}
export interface BackgroundJobSnapshot {
state: BackgroundJobState;
progress: number;
message: string;
operationId: number;
updatedAt: number;
}
export type BackgroundJobEvent =
| { type: 'START'; operationId: number }
| { type: 'PROGRESS'; operationId: number; progress: number }
| { type: 'SUCCESS'; operationId: number }
| { type: 'FAIL'; operationId: number; message: string };
export function acceptEvent(
snapshot: BackgroundJobSnapshot,
event: BackgroundJobEvent
): boolean {
return event.type === 'START' || event.operationId === snapshot.operationId;
}
| 设计对象 | 保存内容 | 不应该保存的内容 |
|---|---|---|
| 页面状态 | 可展示阶段、进度、错误摘要 | 系统对象和页面Context |
| 适配器 | Kit实例、监听注册、资源句柄 | ArkUI组件引用 |
| 业务记录 | operationId、版本、恢复点 | 未脱敏的敏感原始数据 |
| 诊断信息 | 阶段耗时、错误码、能力检测 | Token、图片原始内容 |
一份任务记录对应一次系统申请
文章区分长时、短时和延迟任务:用户主动发起且需要持续可感知的传输才进入长时任务;短暂状态保存使用短时任务;可延后执行的维护工作交给延迟任务。无法取得对应能力时,当前前台流程继续执行,退后台则暂停并保存断点。
这套分层把系统事实和产品行为分开:Kit适配器负责获得事实,领域对象决定是否接受事件,页面只渲染快照。更换API版本或加入真机能力时,只需要替换适配器;状态归并和异常策略仍可在模拟器中重复验证。
开始操作如何做到幂等
下面是主题专属的接入或核心算法代码。示例刻意保留资源创建、前置条件和清理逻辑,因为高频故障往往出现在成功调用之外。
export interface JobRecord {
businessKey: string;
systemTaskId: number;
progress: number;
state: string;
updatedAt: number;
}
export class JobRegistry {
private jobs: Map<string, JobRecord> = new Map();
start(key: string, systemTaskId: number): JobRecord {
const existing = this.jobs.get(key);
if (existing && ['STARTING', 'ACTIVE', 'SUSPENDED'].includes(existing.state)) {
return existing;
}
const record: JobRecord = {
businessKey: key,
systemTaskId,
progress: 0,
state: 'STARTING',
updatedAt: Date.now()
};
this.jobs.set(key, record);
return record;
}
update(key: string, progress: number): void {
const job = this.jobs.get(key);
if (!job || job.state === 'STOPPED') return;
job.progress = Math.max(job.progress, progress);
job.updatedAt = Date.now();
}
}
代码迁入业务工程时,应把错误码转换为稳定的领域错误,不让页面直接判断系统错误字符串。对于异步回调,还要在写入状态前比较operationId或资源版本;仅检查组件是否存在,无法阻止旧任务污染新页面。
系统暂停后怎样恢复进度
| 故障输入 | 状态变化 | 恢复动作 |
|---|---|---|
| 重复点击开始 | 返回活动记录 | 不重复申请任务 |
| 系统暂停 | 保存断点并标记SUSPENDED | 页面显示原因 |
| 进度长时间不变 | 主动结束或重新建链 | 避免僵尸任务 |
| 权限不可用 | 前台执行、后台暂停 | 核心数据不丢失 |
异常注入按钮用于稳定复现应用侧恢复路径。真实错误发生时,诊断记录同时保存错误码、权限结果、设备能力和用户可见状态;敏感原始数据不进入日志,截图只呈现与问题直接相关的结果。
权限与任务类型选择矩阵
页面层不直接调用Kit,而是通过动作按钮驱动同一份状态模型。这样既能在系统能力可用时接真实适配器,也能在模拟器缺少硬件时验证错误页面、幂等逻辑和资源清理。
@Component
struct BackgroundJobPanel {
@State stateText: string = 'IDLE';
@State progress: number = 0;
@State logs: string[] = [];
private append(message: string): void {
const time = new Date().toLocaleTimeString();
this.logs = [`${time} ${message}`, ...this.logs].slice(0, 8);
}
private startDemo(): void {
this.stateText = 'STARTING';
this.progress = 20;
this.append('开始:后台任务生命周期与重复启动保护');
}
private injectFailure(): void {
this.stateText = 'STOPPED';
this.append('已注入可恢复故障');
}
build() {
Column({ space: 12 }) {
Text('后台任务生命周期与重复启动保护').fontSize(24).fontWeight(FontWeight.Bold)
Text(this.stateText).fontSize(18).fontColor('#2563EB')
Progress({ value: this.progress, total: 100 }).width('100%')
Row({ space: 12 }) {
Button('开始实验').onClick(() => this.startDemo())
Button('注入故障').onClick(() => this.injectFailure())
}
ForEach(this.logs, (item: string) => Text(item).fontSize(13))
}.padding(20).width('100%')
}
}
实施先完成任务注册表和businessKey幂等合同,再接入系统任务适配、通知动作、恢复点持久化与页面订阅。验收要求开始命令快速触发十次只产生一个taskId;退到后台后进度继续或按策略暂停;重新进入页面从注册表恢复;停止后通知、网络和本地记录同时结束。系统专属限制使用支持该能力的设备核对,模拟器只承担应用侧状态与降级路径验收。
任务注册表还应记录最后一次进度更新时间。数据传输长期没有变化时,业务可以先检查网络会话,再决定暂停或结束系统任务,不能靠重复申请延长存活。恢复页面只订阅已有任务,不把“页面重新创建”当成“任务重新开始”。通知中的停止动作使用同一个businessKey,最终汇入统一停止流程。这样从页面、通知或系统暂停回调进入时,都不会出现三套互相竞争的清理代码。
验收记录至少包括SDK版本、模拟器系统版本、操作顺序、预期状态、实际状态和截图编号。快速点击、返回再进入、故障后重试和页面销毁是必测项;涉及资源的主题还要显示活动对象计数,涉及异步任务的主题要验证迟到结果不会改变当前页面。
实施顺序与前后台验收
这套方案的技术闭环由“输入约束—状态模型—Kit适配—异常恢复—可观察验收”组成。业务状态不持有系统对象,适配器不直接操作页面,异常路径有明确的恢复动作,后续SDK升级时可以分别回归每一层。
更多推荐



所有评论(0)