应用待机分桶

Android 9（API 级别 28）及更高版本支持应用待机分桶。应用待机分桶有助于系统根据应用的使用时间新近度和使用频率来确定应用资源请求的优先级。优先级分桶有五个，系统会根据应用使用模式将每个应用放置在其中一个分桶中，并会根据应用所在的分桶限制每个应用可用的设备资源。

优先级分桶

系统会动态地将每个应用分配到一个优先级分桶，并根据需要重新分配应用。系统可能依赖于某个预加载的应用，该应用使用机器学习技术判断每个应用将被使用的可能性，并将应用分配到相应的分桶。

如果设备上没有该系统应用，系统默认会根据应用的使用时间新近度对应用进行排序。系统会将更活跃的应用分配到为其赋予更高优先级的分桶，从而为应用提供更多系统资源。具体而言，分桶决定了应用的作业运行频率以及应用可以触发 alarm 的频率。这些限制仅适用于设备使用电池供电的情况。设备充电时，系统不会施加这些限制。

优先级分桶如下：

• 活跃：应用目前正在使用或不久前才被使用过。
• 工作集：应用会被定期使用。
• 常用：应用经常被使用，但不是每天都使用。
• 极少使用：应用不经常被使用。
• 受限：应用会消耗大量的系统资源，或可能出现不希望出现的行为。

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

以下说明适用于非预测性的情况。与上文所述不同，当预测功能使用机器学习技术来预测行为时，会根据对用户后续操作的预测结果（而不是根据近期使用情况）选择分桶。例如，一个最近用过的应用可能最终会出现在“极少使用”分桶中，因为机器学习技术预测该应用在数小时内可能不会被使用。

活跃

如果某个应用当前在使用中、不久前才被使用过，或出现以下任一情况，则会被分配到活跃分桶中：

• 启动了 activity。
• 运行了一项长时间运行的前台服务。
• 用户点按了该应用的通知。

如果应用位于“活跃”分桶中，系统不会对应用的作业或 alarm 施加任何限制。

用户互动会使应用被分配到“活跃”分桶中

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

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

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

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

• 用户在与 Android Automotive OS 互动时连接到您的应用（您的应用在此过程中使用了前台服务或 CONNECTION_TYPE_PROJECTION）。

工作集

如果某个应用经常运行，但当前未在使用中，则会被分配到工作集分桶中。 例如，用户几乎每天都会启动的社交媒体应用就可能位于“工作集”分桶中。如果以间接的方式使用，应用也会被提升到“工作集”分桶。

如果某个应用位于“工作集”分桶中，系统会对其运行作业和触发 alarm 的能力施加轻度限制。如需了解详情，请参阅电源管理限制。

常用

如果某个应用会定期使用，但不一定每天使用，则会被分配到常用分桶中。例如，用户在健身房运行的锻炼跟踪应用可能位于“常用”分桶中。

如果某个应用位于“常用”分桶中，系统会对其运行作业和触发 alarm 的能力施加较高的限制。如需了解详情，请参阅电源管理限制。

极少使用

不经常使用的应用会被分配到极少使用分桶中。例如，用户仅在入住酒店期间才会运行的某个酒店应用就可能位于“极少使用”分桶中。

如果某个应用位于“极少使用”分桶中，系统会对其运行作业和触发 alarm 的能力施加严格的限制。系统还会限制该应用的互联网连接功能。如需了解详情，请参阅电源管理限制。

受限

此分桶是在 Android 12（API 级别 31）中引入的，它在所有分桶中的优先级最低，限制最高。系统会考虑应用的行为（例如，用户与之互动的频率），以决定是否要将您的应用放在“受限”分桶中。

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

• 用户未与您的应用互动的时间达到指定天数。在 Android 12（API 级别 31）和 12L（API 级别 32）中，此天数为 45 天。Android 13 将此天数减少到 8 天。

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

如果系统将您的应用放在“受限”分桶中，它会受到以下限制：

• 您每天可以在 10 分钟的批处理会话中运行作业一次。在此会话期间，系统会将该应用的作业与其他应用的作业编入一组。
  • 受限作业不能自行运行。必须至少还有另一项作业（可以是任何其他作业）与其同时运行或待处理。
• 与在其他限制较少的分桶中运行时相比，在”受限“分桶中，您的应用可以运行的加急作业更少。
• 您的应用每天可以调用一次 alarm。此 alarm 可以是精确 alarm 或不精确 alarm。

免于进入“受限”分桶

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

• 配套设备应用
• 处于演示模式的设备上运行的应用
• 设备所有者应用
• 个人资料所有者应用
• 持久性应用
• VPN 应用
• 具有 ROLE_DIALER 角色的应用
• 用户在系统设置中明确指定提供“无限制”功能的应用
• 具有活跃 widget 的应用
• 至少被授予下列权限之一的应用：
  • USE_EXACT_ALARM
  • SCHEDULE_EXACT_ALARM（Android 13 [API 33] 或更低版本中）
  • ACCESS_BACKGROUND_LOCATION

评估优先级分桶

如需查看您的应用分配到的分桶，请执行以下操作之一：

• 调用 getAppStandbyBucket()。

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

  adb shell am get-standby-bucket PACKAGE_NAME

只要您的应用被放在值大于 STANDBY_BUCKET_ACTIVE (10) 的应用待机分桶中，系统就会对您的应用加以限制。

最佳实践

如果您的应用遵循低电耗模式和应用待机模式的最佳实践，那么随后的电源管理功能并不难。不过，以前运行良好的某些应用行为现在可能会导致问题。

• 请勿试图迫使系统将您的应用放到某个分桶中。系统放置优先级的方法可能会变化，并且每个设备制造商都可能会选择使用自己的算法编写自己的分区应用。请改为确保应用无论位于哪个分桶都运行正常。
• 没有启动器 activity 的应用可能永远不会被提升到“活跃”分桶。请考虑重新设计应用，使其具有此类 activity。

• 如果用户无法与应用通知互动，则无法触发应用提升到“活跃”分桶。在这种情况下，不妨考虑重新设计一些允许用户互动的通知。如需了解一些相关准则，请参阅 Material Design 通知设计模式。

• 如果应用在收到高优先级 Firebase Cloud Messaging (FCM) 消息时不显示通知，用户便无法与应用互动，因而无法将其提升到“活跃”分桶。事实上，高优先级 FCM 消息的唯一预期用途就是向用户推送通知，因此这种情况绝不能出现。在 Android 12L（API 级别 32）及更低版本中，如果您将不会触发用户互动的 FCM 消息误标为高优先级，会导致系统降低后续消息的优先级。

• 如果应用拆分为多个软件包，这些软件包可能位于不同的分桶中，并具有不同的访问权限级别。请测试其软件包被分配到不同分桶的这些应用，以确保应用运行正常。