【官网翻译】性能篇（一）应用待机群组

前言

       本文翻译了Android开发者文档中的一篇官方文档，用于介绍Android9的一个新特性——应用待机群组（App Standby Buckets）。

       中国版官网原文地址为：https://developer.android.google.cn/topic/performance/appstandby。

       路径为：Android Developers > Docs > 指南 > Best practies > App Standby Buckets

 

正文

        Android 9（API level 28）引入了一个新的电池管理特征，应用待机群组。应用待机群组帮助系统根据应用的最近使用时间和使用频率给应用对资源的请求排出优先次序。基于应用的使用模式，每个应用被放置到5个群组中的一个。系统根据应用所在的群组，会限制每个应用对设备资源的使用。

群组优先级

        系统将每个应用动态分配到某一优先级的群组中，并根据须要从新分配应用。系统可能依赖一个预加载的应用，该应用使用机器学习来决定每个应用被使用的可能性，而且将应用分配到适当的群组中。若是系统应用没有展现在设备上，系统会默认根据他们最近被使用时间进行排序。更多活跃的应用被分配到给予应用更高优先级的群组中，从而让这些应用可以使用更多的系统资源。特别地，群组决定了应用工做运行的频率，应用可能触发警报的频率，以及应用可能收到高优先级【FCM】消息的频率。仅仅只有当设备正在使用电池电源的时候这些限制才适用；当设备正在充电的时候，系统不会把这些限制条件强加到应用上。

★ 注意：每个厂商均可觉得非活跃应用如何分配群组设置他们本身的标准。你不该该去尝试影响你的应用被分配到哪个群组。相反，你应该聚焦于确保你的应用不管可能在哪一个群组都表现良好。你的应用能够经过调用一个新的方法【UsageStatsManager.getAppStandbyBucket】找到它当前在哪个群组中。

 这些群组是：

• 活跃：应用当前正在被使用或者最近刚刚被使用过
• 工做集：应用常常被使用
• 频繁：应用常常被使用，但不是天天
• 罕见：应用不是频繁使用

      另外，还有一个特殊的“从不”群组，为那些安装后历来没有使用过的应用而设计。系统给这些应用强加了几个限制。

★ 注意：那些在Doze白名单中的应用在基于限制的应用待机群组中是豁免的。

 

★ 注意：下面的描述适用于非预测性的场景。相反，当预测使用机器学习来预测行为时，群组被选择是为了用户接下来的行为，而不是基于最近的使用。例如，一个最近被使用的应用可能以分配到“罕见”群组而了结，由于机器学习预测该应用可能在接下来的几个小时内都将不会被使用。

      活跃

      若是用户正在使用一款app或者很是频繁使用一款应用，那么这款应用就在“活跃”群组中。例如：

• 该应用启动了一个activity
• 该应用正在运行一个前台service
• 该应用拥有一个与被前台应用使用的内容提供者相关联的同步适配器
• 用户点击了来自该应用的通知。

      若是一款应用在“活跃”群组中，系统将不会放置任何限制在应用的工做、警报或FCM信息上。

      工做集

      若是应用常常运行但当前不是活跃的，那么这款应用处于“工做集”群组。例如，一款用户大部分时间都启动着的社交媒体应用颇有可能在“工做集”群组中。若是应用被间接使用，那么也会被提高到“工做集”群组中。

      若是应用在“工做集”群组中，系统会强加一些轻微的限制到它运行工做和触发警报的能力上。详情请查看【电量管理限制】。

      频繁

      若是应用按期使用，但不是天天都必需的，那么它在“频繁”群组中。例如，一款用户在健身房运行的用于追踪锻炼的应用就有可能在“频繁”群组中。

       若是应用在“频繁”群组中，系统会施加更大的限制在它运行工做和触发警报的能力上，并对高优先级的FCM消息上施加上限。详情请查看【电量管理限制】。

      罕见

       若是一款应用不常用，那么它在“罕见”群组中。例如，只有当用户待在某家旅馆时才会运行的该旅馆应用，可能会在“罕见”群组中。

       若是应用在“罕见”群组中，系统会对它运行工做、触发警报以及接收高优先级FCM消息的能力施加严格的限制。系统也会限制该应用链接到因特网的能力。详情请查看【电量管理限制】。

 

最好的实践

       若是应用已经为Doze和应用待机遵循了最好的实践，那么处理新的电量管理特征就不是难事。但是，一些之前工做得很好的应用行为可能会致使一些问题。

• 不要试图篡改系统来把你的应用放入到指定的某个群组或其它群组中。系统把应用分配到群组的方法能够改变，而且每个设备厂商均可以选择用他们本身的算法来写他们本身的用于分群组的应用。相反，你应该确保应用不管在哪一个群组中都应该合适地表现。
• 若是应用没用用于启动的Activity，它可能永远都不会提高到“活跃”群组中。你可能要从新设计你的应用让它拥有这样的Activity。
• 若是应用的通知是失效的，那么用户将没法经过与通知交互来把触发应用提高到“活跃”群组。在这种状况下，你可能须要从新设计一些合适的通知，好让这些通知容许来自用户的响应。想了解指导意见，请查看材料设计【通知设计模式】。
• 类似地，若是应用在收到高优先级FCM消息的时候没有显示通知，这将不会给用户和应用交互的机会来提高该应用到“活跃”群组。实际上，使用高优先级FCM消息的惟一意图是给用户推送通知，因此这种情形应该绝对不能发生。若是在没有触发用户交互时，你不恰当地标记FCM消息为高优先级，这样会致使其余负面的影响；例如，这样会致使你的应用耗尽它的配额，致使真正紧急的FCM消息被当成正常优先级。

★ 注意：若是用户重复地移除通知，未来系统会给用户限制通知的选择权。不要仅仅为了尝试保持你的应用在“活跃”群组中而使用通知给用户发送垃圾信息。

• 若是应用被拆分为多个包，这些包可能在不一样的群组中，而且有不一样的访问级别。你应该确保使用被分配到不一样群组中的包来测试应用，以确保应用正常运行。

 

结语

       本文最大限度保持原文的意思，因为笔者水平有限，如有翻译不许确或不稳当的地方，请指正，谢谢！