在 HarmonyOS Background Tasks Kit 中，短时任务（Transient Task）主要用于：

• 保存状态
• 提交草稿
• 发送消息
• 快速网络请求
• 缓存落盘

这类实时性较高但执行时间较短的后台任务。

需要特别注意以下约束。

1. 申请时机限制

短时任务不能随时申请。

只能在：

应用前台运行时

或者：

UIAbility 的 onBackground() 回调中

申请。

如果应用已经完全进入后台后再申请：

backgroundTaskManager.requestSuspendDelay(...)

会直接失败。

2. 数量限制

同一个应用：

同一时刻最多 3 个短时任务

超过限制后新申请会失败。

3. 时间配额限制

系统采用配额机制管理短时任务。

默认情况下：

24小时总配额：10分钟

单次申请：

最长约3分钟

低电量场景下：

单次配额可能降至1分钟

配额耗尽后：

当天无法继续申请短时任务

直到系统重新恢复配额。

4. 超时必须处理

申请短时任务时需要传入超时回调。

例如：

backgroundTaskManager.requestSuspendDelay(
  reason,
  () => {
    // 即将超时
  }
)

系统在任务即将到达配额上限时会触发回调。

开发者应该：

保存数据
结束任务
释放资源

然后主动调用：

backgroundTaskManager.cancelSuspendDelay(requestId)

否则系统可能强制结束任务。

5. 不适合长时间业务

短时任务设计目标是：

秒级
几十秒级
最多数分钟

不适合：

大文件下载
持续定位
VPN
长连接保活
音乐播放
蓝牙持续通信

这类场景应该使用：

长时任务（Continuous Task）

或者：

延迟任务（WorkScheduler）

而不是依赖短时任务。

6. 后台时间并非无限延长

很多开发者误以为：

申请短时任务
=
应用不会被挂起

实际上不是。

短时任务只是：

延长后台运行时间

并非永久保活。

时间耗尽后：

应用仍可能被挂起

或者：

被系统回收

这是 HarmonyOS 的后台资源管理机制。

7. 配额计算规则

系统计算配额时有一个容易忽略的细节：

只有应用进入后台后
才开始计算短时任务时间

前台运行期间不会消耗短时任务配额。

另外：

同一个应用同时存在多个短时任务

系统按时间段统计，

不是：

3个任务 = 3倍配额消耗

不会重复扣减同一时间段的配额。

开发建议

最适合短时任务的场景：

退出页面保存数据
聊天消息发送
缓存写盘
同步少量配置
快速上传日志

不建议用于：

长连接
持续同步
大文件上传下载
实时音视频
后台保活

否则容易出现：

任务被中断
配额耗尽
后台执行失败

这些问题。