前言

做后台播放、导航定位、持续录音这类能力时，很多人最先想到的就是申请长时任务，让应用不要被系统挂起。这个方向没问题，但真正落到鸿蒙 6 上，长时任务不是一个只要申请成功就能一直稳定运行的后台通行证。它背后同时受到数量限制、任务类型约束、通知联动和系统一致性校验的共同影响。只要其中一环理解偏了，应用就很容易出现前台正常、切到后台一段时间后任务被系统回收，甚至进程被强制终止的问题。

API 20 的长时任务设计重点，不是给应用尽可能多的后台自由度，而是要求后台能力必须和真实业务严格绑定。你申请了什么类型，就要真的在做什么业务；业务结束了，就应该及时把任务停掉。规则看起来严格，但正因为有这套规则，长时任务这类能力才不会被滥用。

一、先看清 API 20 的核心限制

在 API 20 及之前，一个 UIAbility 同一时刻只能申请一个长时任务。这个限制不是小细节，而是这条版本线最关键的前提之一。只要把这一点忽略掉，后面的架构就很容易全部建歪。

这件事带来的影响非常直接。如果你的应用既要后台播放音频，又要后台定位，不能默认把这两类任务都塞进同一个 UIAbility 里，再指望系统全部放行。更现实的做法是先分清核心后台能力是什么，或者把不同类型的任务拆给不同的 UIAbility 去承接。否则，等代码写到后面才发现能力边界不支持，重构成本会很高。

不过这里还有一个很值得注意的点。虽然一个 UIAbility 同时只能申请一个长时任务，但只要应用里的某个 UIAbility 成功申请了长时任务，整个应用下的所有进程都不会被挂起。也就是说，申请入口是 Ability 级别，但它带来的保活效果是应用级别。这个特性决定了 API 20 并不是完全没有架构余地，而是要求你更谨慎地安排由谁负责申请任务，由谁承接其他业务模块。

从 API 21 开始，这条规则有了明显变化。一个 UIAbility 同一时刻最多可以申请 10 个长时任务，灵活性比 API 20 高很多。但这个变化不能反过来套回 API 20。做兼容时，最稳的方式仍然是按 API 版本走分支逻辑，先用 API 20 的约束把基础能力设计稳，再在 API 21 上放开。

二、真正难的不是申请，而是通过系统校验

很多人把长时任务理解成一个后台开关，申请成功就结束了。实际上，真正麻烦的地方不在申请，而在申请之后。系统会持续做一致性校验，确认你申请的任务类型和实际执行的业务类型是否匹配。如果你申请的是 audioPlayback，系统默认你真的在做音频或视频后台播放；如果系统发现你申请了这类长时任务，却没有真实播放行为，长时任务会被取消。

这就决定了长时任务不能被当成一个泛用型后台保活手段来用。你不能为了让网络轮询、定时刷新或者其他高耗能逻辑继续活着，就顺手申请一个音频播放类型的长时任务。短时间看起来也许能跑，但系统的校验机制本来就是为了拦这类行为。只要任务类型和真实业务不一致，系统介入几乎是迟早的事。

除了任务类型匹配，系统还会关注后台负载。如果运行长时任务的进程在后台的资源消耗持续高于这一类任务的典型负载，系统同样会进行管控。也就是说，就算你申请的类型本身没错，如果后台行为明显超出了这个类型通常应有的资源画像，任务也不一定能一直稳定保留。长时任务的实现，不能只盯着功能是否跑起来，还要同时考虑功耗和资源占用。

还有一个容易被低估的点，是通知联动。长时任务申请成功后，通知栏会显示与任务关联的通知。用户可以通过删除通知来主动停止长时任务。这意味着任务状态和通知状态天然是联动的。应用如果只关心申请和停止接口，却不把通知对应的用户操作纳入状态管理，后面就很容易出现界面还显示任务在运行，实际上任务已经结束，或者任务还在、界面状态却没更新的问题。

三、音频场景里申请和停止都要跟真实播放状态绑在一起

音频播放是最典型的长时任务场景之一，也是最容易写错的一类。很多项目会在开始播放时申请长时任务，这一步本身没有问题。问题往往出在停止流程。对于后台播放音频的应用，在后台停止长时任务的同时，必须暂停或停止音频流，否则应用可能会被系统强制终止。这个约束非常硬，直接关系到进程是否还能继续存活。

这意味着音频相关的长时任务实现，不能拆成两套彼此独立的状态。不能一边把后台任务停了，一边让播放器自己再慢慢停；也不能播放器其实已经停了，却忘了把长时任务回收掉。更稳妥的做法，是把播放状态和长时任务状态收敛到同一个状态机里，开始播放时统一申请，停止播放时统一回收。只有这样，音频流和长时任务之间才不会出现脱节。

在代码层面，第一步不是直接写 startBackgroundRunning，而是先把权限和后台模式配置对。至少要声明 ohos.permission.KEEP_BACKGROUND_RUNNING，并给对应 UIAbility 配好 backgroundModes。如果是音频后台播放，后台模式要和 audioPlayback 对应。少了这一步，后面的业务代码即使逻辑对，也很容易直接申请失败或者表现不稳定。

{
  "module": {
    "requestPermissions": [
      {
        "name": "ohos.permission.KEEP_BACKGROUND_RUNNING"
      }
    ],
    "abilities": [
      {
        "name": "EntryAbility",
        "backgroundModes": [
          "audioPlayback"
        ]
      }
    ]
  }
}

然后再看申请代码。这里最容易写错的地方有两个。一个是 API 20 传入的是任务类型列表，不是多任务对象。另一个是申请成功之后，不要把它理解成任务已经闭环完成，真正的音频播放流程必须马上接上。

import { backgroundTaskManager } from '@kit.BackgroundTasksKit';
import { wantAgent } from '@kit.AbilityKit';

async function startAudioPlaybackContinuousTask(context: Context): Promise<void> {
  const wantAgentInfo: wantAgent.WantAgentInfo = {
    wants: [
      {
        bundleName: 'com.example.audioapp',
        abilityName: 'EntryAbility'
      }
    ],
    actionType: wantAgent.OperationType.START_ABILITY,
    requestCode: 0,
    actionFlags: [wantAgent.WantAgentFlags.UPDATE_PRESENT_FLAG]
  };

  const agent = await wantAgent.getWantAgent(wantAgentInfo);
  const taskTypes: Array<string> = ['audioPlayback'];

  await backgroundTaskManager.startBackgroundRunning(context, taskTypes, agent);

  // 这里表示长时任务申请成功
  // 接下来要立即进入真实的音频播放流程
}

停止逻辑也要跟真实业务一起收口，而不是分开处理：

import { backgroundTaskManager } from '@kit.BackgroundTasksKit';

async function stopAudioPlaybackContinuousTask(
  context: Context,
  stopPlayer: () => Promise<void> | void
): Promise<void> {
  await stopPlayer();
  await backgroundTaskManager.stopBackgroundRunning(context);
}

如果是在页面组件里调用，context 一般可以通过 this.getUIContext().getHostContext() 获取，再转成当前 Ability 可用的上下文对象。关键不是写法多复杂，而是别把上下文、任务申请和真实播放拆成三套互不关联的逻辑。

四、长时任务真正考验的是架构而不是单个 API

长时任务这件事，表面上看只是几个接口调用，实际考验的是架构能力。你得先判断什么业务值得占用后台能力，什么业务不值得。你得明确长时任务由哪个 UIAbility 申请，其他模块如何跟它协作。你还得考虑用户主动通过通知结束任务后，界面状态怎么同步，播放状态怎么回收，异常中断后怎么恢复。所有这些问题，本质上都不是单个 API 能替你解决的。

对于 API 20 来说，更现实的做法通常不是追求同时承载尽可能多的后台能力，而是先把真正核心的长时任务做稳。比如音乐应用优先保证后台播放，导航应用优先保证持续定位，其他非核心逻辑用别的技术方案兜底。很多时候，这种取舍不是退让，而是更符合系统规则的实现方式。

真正稳定的长时任务实现，通常都有几个共同点。任务类型和真实业务严格对应，音频流或定位流和任务状态统一管理，通知交互被纳入状态机，版本差异提前在架构层处理，而不是等到测试阶段再补。只要这些基础做扎实，长时任务就不会只是一个容易翻车的后台能力，而会变成一个可以稳定落地的系统能力。

总结

如果只用一句话概括 API 20 的长时任务现状，那就是它能支撑真实后台业务，但前提是必须严格按系统规则来。一个 UIAbility 同一时刻只能申请一个长时任务；只要应用里的某个 UIAbility 申请成功，整个应用进程都不会被挂起；系统会持续校验任务类型和真实业务是否一致，也会关注后台负载是否异常；通知栏联动和用户主动停止，同样属于这套机制的一部分。

所以，长时任务真正考验的不是你会不会调接口，而是你能不能把后台业务、系统规则和应用架构连成一套完整实现。该拆 Ability 的时候拆 Ability，该停音频的时候停音频，该做版本分支的时候做版本分支。把这些边界想清楚，长时任务就不再只是一个容易出问题的后台能力，而会变成一个可以稳定落地的系统机制。