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

标签：加载   请求   base   用户   运行   测试   场景   通过   选择   

前言

       本文用于介绍Android9的一个新特性——应用待机群组（App Standby Buckets）。

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

       路径为：Android Developers > Docs > 指南

正文

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

群组优先级

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

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

 这些群组是：

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

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

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

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

      活跃

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

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

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

      工作集

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

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

      频繁

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

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

      罕见

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

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

最好的实践

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

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

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

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

结语

       本文最大限度保持原文的意思，由于笔者水平有限，若有不准确或不妥当的地方，请指正，谢谢！

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

标签：加载   请求   base   用户   运行   测试   场景   通过   选择   

原文地址：https://www.cnblogs.com/andy-songwei/p/10694931.html