应用待机分组

Android 9（API 级别 28）及更高版本支持应用待机分组。应用待机分组可帮助系统根据应用的最近使用频率和使用频率，优先处理应用的资源请求。根据应用的使用模式，每个应用都被放入五个优先分组之一。系统会根据应用所在的分组限制每个应用可用的设备资源。

优先级分组

系统会动态地将每个应用分配到一个优先级分组，并根据需要重新分配应用。系统可能依赖预加载的应用，该应用使用机器学习来确定每个应用的使用可能性，并将应用分配到适当的分组。

如果设备上不存在系统应用，系统默认根据应用最近的使用情况对应用进行排序。更活跃的应用被分配到优先级更高的分组，从而使更多系统资源可用于该应用。特别是，分组决定了应用的作业运行频率和应用触发警报的频率。这些限制仅在设备依靠电池供电时适用。当设备正在充电时，系统不会施加这些限制。

优先级分组如下：

  • 活跃：应用正在使用或最近使用过。
  • 工作集：应用处于常规使用状态。
  • 常用：应用经常使用但不是每天使用。
  • 不常用：应用不常使用。
  • 受限：应用消耗大量系统资源或可能表现出不良行为。

除了这些优先级分组之外，还有一个特殊的从未使用分组，用于已安装但从未运行的应用。系统对这些应用施加了严格的限制。

以下描述适用于非预测情况。相比之下，当预测使用机器学习来预测行为时，分组是根据用户下一步操作的预期而不是基于最近的使用情况选择的。例如，最近使用的应用可能最终会进入不常用分组，因为机器学习预测该应用可能在几个小时内不会被使用。

活跃

应用在使用时、最近使用时或执行以下任何操作时，都处于活跃分组：

  • 启动 Activity。
  • 运行长时间运行的前台服务。
  • 用户从通知中点击。

如果应用处于活跃分组，系统对应用的作业或警报施加最小限制。

  • 从 Android 16（API 级别 36）开始，如果后台作业是由活跃分组中的应用启动的，它们将获得充足的运行时配额。这包括直接使用 JobScheduler 调度的作业，以及由 WorkManager 或 DownloadManager 等其他库创建的作业。

用户互动将应用指定为活跃

在 Android 9（API 级别 28）及更高版本中，当用户以特定方式与您的应用互动时，系统会暂时将您的应用放入活跃分组。用户停止与您的应用互动后，系统会根据使用历史记录将其放入一个分组。

以下是触发此系统行为的互动示例：

  • 用户点击您的应用发送的通知。

  • 用户通过点击媒体按钮与您应用中的前台服务互动。

  • 用户在使用 Android Automotive OS 时连接到您的应用，其中您的应用使用前台服务或 CONNECTION_TYPE_PROJECTION。

工作集

如果应用经常运行但不活跃，则处于工作集分组。例如，用户几乎每天启动的社交媒体应用很可能处于工作集分组中。如果应用被间接使用，也会被提升到工作集分组。

如果应用处于工作集分组中，系统会对其运行作业和触发警报的能力施加轻微限制。有关详细信息，请参阅电源管理资源限制。

常用

如果应用经常使用但并非每天使用，则处于常用分组。例如，用户在健身房运行的健身追踪应用可能处于常用分组中。

如果应用处于常用分组中，系统会对其运行作业和触发警报的能力施加更强的限制。有关详细信息，请参阅电源管理资源限制。

不常用

如果应用不常使用，则处于不常用分组。例如，用户仅在该酒店住宿时运行的酒店应用可能处于不常用分组中。

如果应用处于不常用分组中，系统会对其运行作业和触发警报的能力施加严格限制。系统还会限制应用连接互联网的能力。有关详细信息，请参阅电源管理资源限制。

受限

此分组是在 Android 12（API 级别 31）中添加的，具有所有分组中最低的优先级和最高的限制。系统会考虑您的应用行为（例如用户与您的应用的互动频率），以决定是否将您的应用置于受限分组。

在 Android 13（API 级别 33）及更高版本中，除非您的应用符合豁免条件，否则系统会在以下情况下将您的应用放入受限分组：

  • 用户在特定天数内未与您的应用互动。在 Android 12（API 级别 31）和 12L（API 级别 32）上，天数为 45 天。Android 13 将天数减少到 8 天。

  • 您的应用在 24 小时内调用了过多的广播或绑定。

如果系统将您的应用放入受限分组，则适用以下限制：

  • 您可以在每天一次的 10 分钟批处理会话中运行作业。在此会话期间，系统会将您的应用的作业与其他应用的作业进行分组。
    • 受限作业不会自行运行。同时必须至少有一个其他作业正在运行或待处理，这可以包括任何其他作业。
  • 与系统将您的应用放入限制较少的分组时相比，您的应用可以运行更少的加速作业。
  • 您的应用每天可以调用一次警报。此警报可以是精确警报或非精确警报。

受限分组的豁免

以下类型的应用豁免进入受限分组，并绕过不活跃触发器，即使在 Android 12 及更高版本上也是如此：

评估优先级分组

要检查您的应用被分配到哪个分组，请执行以下操作之一：

  • 调用 getAppStandbyBucket()。

  • 在终端窗口中运行以下命令：

    adb shell am get-standby-bucket PACKAGE_NAME

当您的应用被放入值大于 STANDBY_BUCKET_ACTIVE (10) 的应用待机分组时，系统会限制您的应用。

最佳实践

如果您的应用遵循低电耗模式和应用待机的最佳实践，那么后续的电源管理功能就不会很难。但是，以前运行良好的一些应用行为可能会导致问题。

  • 不要试图操纵系统将您的应用放入某个特定分组。系统确定优先级的方法可能会改变，并且每个设备制造商都可能选择编写自己的分组应用及其算法。相反，请确保您的应用无论在哪个分组中都能正常运行。
  • 如果应用没有启动 Activity，它可能永远不会被提升到活跃分组。考虑重新设计您的应用以包含此类 Activity。

  • 如果用户无法与应用通知互动，则用户无法触发应用提升到活跃分组。在这种情况下，请考虑重新设计一些允许用户互动的通知。有关指导，请参阅 Material Design 的通知设计模式。

  • 如果应用在收到高优先级 Firebase Cloud Messaging (FCM) 消息时没有显示通知，则用户无法与应用互动，从而无法将其提升到活跃分组。实际上，高优先级 FCM 消息的唯一预期用途是向用户推送通知，因此这种情况不应发生。在 12L（API 级别 32）及更低版本上，如果您不当地将不触发用户互动但标记为高优先级的 FCM 消息，可能会导致未来的消息优先级降低。

  • 如果应用跨多个软件包拆分，这些软件包可能位于不同的分组中并具有不同的访问级别。测试这些应用时，将软件包分配到各种分组以确保应用行为正常。