Doze和App Standby模式下的Android应用适配

从Android6.0(API23)开始, Google为Android加入了两种省电特性，通过管理Android应用(以下简称应用)在非充电状态下的设备中的运行策略来达到延长用户的Android设备使用时间的目的。这两种特性存在一定的差别，Doze模式通过延缓应用在设备长时间待机状态下对于CPU和网络资源的使用来实现节能；而App Standby则是通过延缓最近未被使用的后台应用对于网络的请求来达到同样的目的。

Doze和App Standby在Android6.0及以上的Android设备中可以影响所有运行状态下的Android应用，无论这些应用的Target API是否是指定为API23。为了确保用户获得在不同Android版本下的应用体验一致性，开发者需要对应用在Doze及App Standby模式下做相应的适配。

Doze初体验

用户的Android设备处于未充电状态，静止且屏幕关闭一段时间之后，Android系统就会自动进入Doze模式。在Doze模式下，Android系统将会通过限制后台应用对CPU密集型服务以及网络的使用来减少电量消耗。此外，Android系统还会推迟后台应用的Jobs、Syncs和Alarms等操作。

正常情况下，Android系统会周期性的退出Doze模式然后执行之前推迟的应用活动。Android系统退出Doze模式的这个短暂期被称作“维护窗口”。在这个较短的维护窗口期间，系统将会恢复所有Doze模式中推迟的Syncs、Jobs和Alarms等操作，并短暂开放后台应用对于网络的访问权限。

在这里插入图片描述

Figure 1. Doze模式为应用提供了一个周期性的可供应用使用网络以完成被推迟任务的维护窗口

在维护窗口的末期，Android系统又会重新进入Doze模式，并再度暂停所有的Jobs、Syncs和Alarms等操作的执行。系统会在多次进入和退出Doze模式之后智能调整时间段，最后显著降低退出Doze模式的频率，为长时间处于未充电状态且没有活动的Android设备最大限度保存电量。

在用户通过移动、点亮屏幕或者连接充电器唤醒Android设备之后，系统将会自动退出Doze模式并恢复应用到正常的工作状态。

Doze模式下的限制

Android应用处于Doze模式下时会受到以下限制：
1.网络访问被挂起
2.Wake Locks被无视
3.AlarmManager创建的Alarms将被推迟到下一个维护窗口，通过setAndAllowWhileIdle()以及setExactAndAllowWhileIdle()设置的Alarms将会在Doze模式下正常执行，同时通过setAlarmClock()设置的Alarms也会正常执行—Android系统将会在设定时间之前自动退出Doze模式
4.Android系统将会停止执行Wi-Fi的扫描
5.Android系统将会停止Sync Adapter的同步操作
6.Android系统也会停止JobScheduler的定时操作

适配Doze模式

Doze模式对不同应用的影响程度依赖于应用本身所提供的能力以及应用所依赖的系统服务。很多应用可以不经过任何修改就在Doze模式下正常运行，而有的应用则必须进行优化后才可以正常的在Doze模式下运行。对Doze模式进行适配主要应当考虑应用对网络、Alarms、Jobs和Syncs的使用，适配Doze模式的应用应当能高效的使用Doze模式下的维护窗口来做一些必要的操作。

Doze模式对于使用AlarmManager的应用会有很大的影响，主要是因为在Android5.1(API22)或以下的Android系统中，当系统进入Doze模式之后，Alarms将会被系统忽略。为了让Android应用能够在处于Doze模式下系统中正常运行Alarms，Android6.0(API23)加入了两个新的Alarms方法：setAndAllowWhileIdle()和setExactAndAllowWhileIdle()，通过这两个方法创建的Alarms在Doze模式下会正常运行。

Note: 使用setAndAllowWhileIdle()和setExactAndAllowWhileIdle()方法的应用，9分钟之内只能运行一次Alarms服务。

Doze模式对于网络的限制很大程度上会影响到应用的正常运行，尤其是对于依赖Tickles和Notification这类实时消息提醒的应用。如果一个应用需要依赖于网络连接来实现不间断的收取消息，那么就应该尽可能的使用GCM服务。

为了确保应用在Doze模式下也能如预期中一样的工作，可以使用adb调试命令来手动使Android系统进入或退出Doze模式来测试应用的表现。

App Standby初体验

在App Standby模式下Android系统会使一个用户长时间未使用的应用进入空闲状态。具体来说，当用户长时间未与应用发生交互操作或以下任意场景都未出现时，Android系统就会使应用进入空闲状态：
1.用户主动启动应用
2.应用存在前台进程（前台活动或前台服务，或有组件被另一前台活动及服务使用）
3.应用创建了一个用户可见的锁屏界面上或者是收入Notification tray中的Notification

当用户给Android设备接入充电电源时，Android系统会将所有处于Standby状态的应用释放，允许它们自由的访问网络并执行所有Standby期间暂停的Jobs和Sync。如果应用长时间处于空闲状态，Android系统将会允许处于空闲状态的应用以大约一天一次的频率访问网络。

通过GCM与处于空闲状态的应用交互

GCM是Google提供的Cloud-to-Device消息推送服务，这项服务允许Android设备上的应用通过它来获取对应后端服务的消息流。GCM提供了一个唯一的、持续性的云端链路，所有对实时消息通信有需求的应用都可以共享这一链路。这一共享链路的存在能够显著的改善耗电速度，因为所有使用GCM的应用将不会需要独自维护一条链路。基于这一点，如果一个应用需要经常与后端服务进行通信，强烈建议开发者使用GCM服务。

GCM通过高优先级GCM消息实现了在Doze和App Standby模式下消息的正常递送。GCM高优先级消息能够在Doze和App Standby模式下稳定的唤醒应用以便它们访问网络，完成预期的工作。GCM会在获取到对应应用的下行消息时短暂的唤醒应用，赋予该应用网络访问和部分唤醒锁的能力，并在一定时间后使系统或应用重回空闲状态。

高优先级GCM消息并不会阻断Doze模式，也不会影响任意其他应用的所处状态。这意味着应用可以通过它在实现稳定高效的通信的同时最大程度的降低对于电池的影响。

因此，在应用需要同服务器下行消息实时交互的情况下，就应该使用GCM。同时，如果服务器和应用已经部署GCM，需要确保对于某些紧急通知使用高优先级GCM消息以便处于Doze模式下的应用也能及时接收该消息。

一些需要考虑的情况

所有的应用都应当具备在Doze模式下管理网络连接、Alarms、Jobs和Syncs的能力，并且在合适的时候使用高优先级GCM消息来通信。在某些特定的情况下，高优先级GCM消息可能并不足以保证应用在Doze模式下的正常运行。对于这些特殊情况，Android系统还提供了一个可配置的白名单机制，处于白名单之中的应用能够免遭Doze和App Standby模式的影响。

在Doze和App Standby模式下处于白名单中的应用能够正常使用网络并持有部分唤醒锁。然而，白名单并不代表一切。处于白名单中的应用也会受到一定的规则限制，比如说：白名单中的应用的Jobs和Syncs以及常规Alarms也会被推迟运行。应用可以通过调用isIgnoringBatteryOptimizations()方法来判断自己是否是处于白名单之中。

用户可以通过Settings>Battery>Battery Optimization来手动配置应用白名单。同样，Android系统也为应用提供了请求白名单的通道。
1.应用可以通过创建ACTION_IGNORE_BATTERY_OPTIMIZATION_SETTINGS intent引导用户前往Battery Optimization界面并将自己加入白名单。
2.应用持有REQUEST_IGNORE_BATTERY_OPTIMIZATIONS权限时可以直接触发一个系统级的Dialog来提醒用户将自己加入白名单（无需进入Settings页面）。
3.应用通过创建ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS intent来触发上述Dialog。任意情况下，用户可以根据个人意愿选择移除白名单中的应用。

Android应用在请求用户将自己加入白名单之前，需要确保自己符合“白名单特例”所述的情况。

**Note:**Google Play条款对于Android6.0+系统中的应用严厉禁止其通过请求用户将自己加入白名单的方式来避免遭受系统电池管理系统的影响，除非该应用的核心功能会在不加入白名单的情况下受到影响。

测试应用在Doze及App Standby模式下的表现

为了确保用户体验的一致性，需要测试应用在Doze以及App Standby模式下的表现。

Doze模式下的测试

可以通过以下几个步骤来测试Android应用在Doze模式下的表现：
1.使用Android6.0+(API23)及以上系统的Android物理或虚拟设备
2.将设备同开发机器相连接
3.运行并保证应用处于活动状态
4.关闭屏幕（应用依旧处于活动状态）
5.通过以下命令强制系统进入和退出Doze模式：

$adb shell dumpsys battery unplug  
$adb shell dumpsys deviceidle step，

某些情况下可能需要运行第二个命令多次。重复上述命令直到设备状态变为空闲态。
6.观察应用在退出Doze模式时的表现，确保应用在系统退出Doze模式时的唤醒过程是平滑的。

App Standby模式下的测试

可以通过下述步骤测试Android应用在App Standby模式下的表现：
1.使用Android6.0+(API23)及以上系统的Android物理或虚拟设备
2.将设备同开发机器相连接
3.运行并保证应用处于活动状态
4.通过以下命令强制应用进入App Standby模式：

$ adb shell dumpsys battery unplug 
$ adb shell am set-inactive <packageName> true

5.通过以下命令模拟唤醒应用：

$ adb shell am set-inactive <packageName> false 
$ adb shell am get-inactive <packageName>

6.观察应用在唤醒后的状态表现，确保应用平缓的从App Standby模式中恢复。特别需要注意的是，你需要确保应用的通知以及后台Jobs在恢复之后正常运行。

白名单特例

下面的表格总结了一些可以接受的加入白名单的情形。大体上来说，除非Android应用在非白名单模式下会影响到其核心功能的使用，并且通过使用高优先级GCM消息也不能解决这一问题，这种情况下才可以使用白名单。

【说明】本文翻译自Android官方文档，链接地址：https://developer.android.com/training/monitoring-device-state/doze-standby.html#support_for_other_use_cases，仅作学习之用，对于使用本文所造成的任何问题本人概不负责。

在低电耗模式下测试您的应用

您可以按以下步骤在低电耗模式下测试您的应用：

使用 Android 6.0（API 级别 23）或更高版本的系统映像配置硬件设备或虚拟设备。
将设备连接到开发计算机并安装您的应用。
运行您的应用并使其保持活动状态。

运行以下命令，强制系统进入闲置模式：

    $ adb shell dumpsys deviceidle force-idle

准备就绪后，运行以下命令，使系统退出闲置模式：
```
    $ adb shell dumpsys deviceidle unforce
    
```

执行以下命令，重新激活设备：

    $ adb shell dumpsys battery reset

在重新激活设备后观察应用的行为。确保应用在设备退出低电耗模式时正常恢复。

在应用待机模式下测试您的应用

如需在应用待机模式下测试您的应用，请执行以下操作：

使用 Android 6.0（API 级别 23）或更高版本的系统映像配置硬件设备或虚拟设备。
将设备连接到开发计算机并安装您的应用。
运行您的应用并使其保持活动状态。

运行以下命令，强制应用进入应用待机模式：

$ adb shell dumpsys battery unplug
    $ adb shell am set-inactive <packageName> true

使用以下命令模拟唤醒您的应用：

$ adb shell am set-inactive <packageName> false
    $ adb shell am get-inactive <packageName>

在唤醒应用后观察它的行为。确保应用从待机模式正常恢复。您应特别检查应用的通知和后台作业是否继续按预期运行。