不少细心的开发者已发现，在华为终端开放实验室发布的最新绿色应用达标率调查报告中，国内千款主流应用有 63 款应用在灭屏时 Alarm 占用大于 20 次/小时，这些应用最终也因为此检测项未通过导致无法获得绿色应用标记。
那么在绿色应用检测过程中为什么会把灭屏时 Alarm 占用作为一个重要衡量标准进行检测呢，开发者又该如何针对此项标准对应用进行开发呢？本篇文章将给出你答案。
安卓设备为了节省电量，在设备无操作时会将屏幕变暗，然后灭屏，最终休眠 CPU。但有时应用可能需要不同的行为，比如一些游戏或视频类应用可能需要持续亮屏，还有一些应用可能不需要持续亮屏，但需要 CPU 保持运行，直到完成相关关键操作。为此，安卓系统提供了在必要时保持设备唤醒且省电的方案，分别是 Wakeup 和 AlarmManager，这也就是 Alarm(闹钟) 在安卓系统存在的原因。
一、Alarm 是什么
熟悉安卓系统的开发者都知道，Alarm 可以完成闹钟式定时任务，安卓系统主要通过 AlarmManager 类对其进行管理，我们可以通过 AlarmManager 在一些 Alarm 设定的时间点启动服务进行事件处理，同时还可以用 Alarm 来初始化一些长时间运行的操作，手机每天启动一个服务来下载天气预报的数据其实就是 Alarm 最熟悉的实用场景。
我们了解了 Alarm 是用来做什么的，那么 Alarm 都有哪些特性呢？
二、Alarm 特性
1、Alarm 允许在设定的时间或时间间隔发送 Intent（意图）；
2、将 Alarm 与 Broadcast Receiver（广播接收器）进行结合启动 Service（服务），并执行其它操作；
3、Alarm 可在应用之外运行，所以即使应用没有启动、设备处于休眠状态，也可以通过 Alarm 来触发应用事件及操作；
4、Alarm 可以使应用对于系统资源进行最小化占用，可以在不依赖 timer（计时器）或者后台持续运行的 Service 来执行一些操作；
三、Repeating Alarm（重复闹钟）
Repeating Alarm（重复闹钟）是一种相对灵活的简单机制，但并非在所有场景下都适合，在应用需要触发网络操作时，如果使用 Repeating Alarm，可能会因为 Alarm 设计不当导致电量过度消耗，增加服务器负载。但通常情况下，在应用运行之外触发操作需要从服务器同步数据，这就需要借助 Repeating Alarm 来实现。当要同步数据的服务器是自有的，Google Cloud Messaging(GCM) 配合 sync adapter 同步框架是比 AlarmManager 更好的解决方案。sync adapter 同步框架可以提供 AlarmManager 所有的功能，而且更加灵活。
当设备在 Doze 模式下处于空闲状态时，Alarm 不会被触发。任何预先设置的 Alarm 将被推迟，直到设备退出 Doze 模式。如果需要设备在空闲状态也能完成相关操作，可以使用 setAndAllowWhileIdle() 或 setExactAndAllowWhileIdle() 来保证 Alarm 被执行；也可以使用新的 WorkManager API 来完成后台单次或定期的执行工作。使用 setInexactRepeating() 时，不能像使用 setRepeating() 时自定义间隔，如果要自定义间隔，必须使用间隔常量：
INTERVAL_FIFTEEN_MINUTES、INTERVAL_DAY 等
四、Repeating Alarm 最佳实践
使用 Repeating Alarm 进行的每一个设置都会影响应用对系统资源的占用，那么该如何以最小的系统资源占用使用 Repeating Alarm 呢？
在 Repeating Alarm 触发的网络请求里添加随机性（抖动）操作：
①当 Alarm 触发时，先执行无需访问服务器或从服务器获取数据的操作。
②与此同时，对于包含网络请求的 Alarm，在设定时间上添加一些随机变量。
降低 Alarm 触发频率。
除非必要，否则不使用唤醒设备的 Alarm。
除非必要，否则不要使用高精度的 RTC 时钟来触发 Alarm。
使用 setInexactRepeating() 来替换 setRepeating()。当使用 setInexactRepeating() 时，安卓系统会同步多个应用的 Repeating Alarm，并同时触发它们。这样可以减少系统唤醒设备的总次数，从而减少手机电量消耗。从安卓系统 4.4（API 级别 19）开始，所有 Repeating Alarm 都是不精确的。尽管 setInexactRepeating() 相对于 setRepeating() 做了改进，但如果手机上的应用都在接近的时间内集中访问服务器，仍会给服务器造成压力。因此，很有必要对于网络请求的 Alarm 添加一些随机性。
尽可能避免使用基于 RTC 的 Alarm。
基于 RTC 的 Alarm 扩展性不好，使用 ELAPSED_REALTIME 对 Alarm 进行设置更好一些。
五、Repeating Alarm 的设置
Repeating Alarm 适合用来执行常规事件及查找数据，接下来我们来认识一下 Repeating Alarm 具有哪些特性？
Alarm 类型的选择；
触发时间，如果设定的触发时间已经过去了，则 Alarm 会立即触发；
Alarm 的间隔：每天、每小时、每 5 分钟等；
触发 Alarm 时需执行的 Pending Intent，如果第二个 Alarm 设置使用之前存在的 Pending Intent，系统会默认替换之前的 Alarm。
六、选择一个 Alarm 类型
设置 Repeating Alarm 时首要考虑因素就是它的类型。
Alarm 有两种通用时钟类型：“elapsedreal time（相对时间）” 和 “real time clock（RTC 实时时间）”。相对时间使用 “自系统启动以来的时间” 作为参考，实时时间使用 UTC 时间。这意味着相对时间适合根据时间的推移设置 Alarm，因为它不受时区/区域设置的影响，实时时间更依赖于当前区时设置 Alarm。
两种时钟类型都有一个设备 “唤醒” 机制，可以在屏幕熄灭后唤醒 CPU，这就确保了 Alarm 在设定时间被触发。如果你的应用具有时间依赖性（例如要求在有限窗口执行特定操作），可以使用该机制。如果不使用设备 “唤醒” 机制，所有 Repeating Alarm 都将在设备下次唤醒时全部触发。
如果以特定时间间隔触发 Alarm，最好使用相对时间类型。反之，如果需要在一天中的特定时间触发 Alarm，则需要选择一种基于 UTC 时间的实时时间类型。
以下是所有时钟类型：
ELAPSED_REALTIME——根据设备启动后的时间来处理 Pending Intent，但不会唤醒设备，设备休眠时间也会被统计进来。
ELAPSED_REALTIME_WAKEUP——在设备启动后经过设定的时间长度，唤醒设备并处理 Pending Intent。
RTC——在设定时间处理 Pending Intent，但不会唤醒设备。
RTC_WAKEUP——唤醒设备并在设定时间处理 Pending Intent。
七、Alarm 设置示例
1、相对时间 Alarm 设置示例
以下是使用 ELAPSED_REALTIME_WAKEUP 进行 Alarm 设置示例。
30 分钟内唤醒设备并触发 Alarm，之后每 30 分钟触发一次 Alarm：
// Hopefully your alarm will have a lower frequency than this!
alarmMgr.setInexactRepeating(AlarmManager.ELAPSED_REALTIME_WAKEUP,
AlarmManager.INTERVAL_HALF_HOUR,
AlarmManager.INTERVAL_HALF_HOUR, alarmIntent);
一分钟内唤醒设备并触发一个一次性 Alarm：
private AlarmManager alarmMgr;
private PendingIntent alarmIntent;
...
alarmMgr = (AlarmManager) context.getSystemService(Context.ALARM_SERVICE);
Intent intent = new Intent(context, AlarmReceiver.class);
alarmIntent = PendingIntent.getBroadcast(context, 0, intent, 0);
alarmMgr.set(AlarmManager.ELAPSED_REALTIME_WAKEUP,
SystemClock.elapsedRealtime() +
60 * 1000, alarmIntent);
2、实时时间 Alarm 设置示例
以下是一些使用 RTC_WAKEUP 进行 Alarm 设置的示例。
在下午 2 点左右唤醒设备并触发 Alarm，之后每天在同样的时间重复触发一次这个 Alarm：
// Set the alarm to start at approximately 2:00 p.m.
Calendar calendar = Calendar.getInstance();
calendar.setTimeInMillis(System.currentTimeMillis());
calendar.set(Calendar.HOUR_OF_DAY, 14);
// With setInexactRepeating(), you have to use one of the AlarmManager interval
// constants--in this case, AlarmManager.INTERVAL_DAY.
alarmMgr.setInexactRepeating(AlarmManager.RTC_WAKEUP, calendar.getTimeInMillis(),
AlarmManager.INTERVAL_DAY, alarmIntent);
在上午 8 点 30 分准时唤醒设备，之后每隔 20 分钟触发一次 Alarm：
private AlarmManager alarmMgr;
private PendingIntent alarmIntent;
...
alarmMgr = (AlarmManager) context.getSystemService(Context.ALARM_SERVICE);
Intent intent = new Intent(context, AlarmReceiver.class);
alarmIntent = PendingIntent.getBroadcast(context, 0, intent, 0);
// Set the alarm to start at 8:30 a.m.
Calendar calendar = Calendar.getInstance();
calendar.setTimeInMillis(System.currentTimeMillis());
calendar.set(Calendar.HOUR_OF_DAY, 8);
calendar.set(Calendar.MINUTE, 30);
// setRepeating() lets you specify a precise custom interval--in this case,
// 20 minutes.
alarmMgr.setRepeating(AlarmManager.RTC_WAKEUP, calendar.getTimeInMillis(),
1000 * 60 * 20, alarmIntent);
八、Alarm 设置的取消
应用取消 Alarm 设置，需要调用 AlarmManager 里 cancel() 的方法，把不想被触发的 PendingIntent 实例传入 cancel() 里。例如：
// If the alarm has been set, cancel it.
if (alarmMgr!= null) {
alarmMgr.cancel(alarmIntent);
}
九、设备重启时如何触发 Alarm
默认情况下，设备关闭时会同时关闭所有 Alarm。为防止这种情况发生，可以在用户重新启动设备时应用自动重新启动 Repeating Alarm。可以确保 AlarmManager 在用户无需手动重启 Alarm 的情况下继续执行其任务。
以下是步骤：
1、在应用 manifest 中设置 RECEIVE_BOOT_COMPLETED 权限。允许应用在系统完成启动后接收 ACTION_BOOT_COMPLETED 广播（仅在用户已经至少启动过应用一次时才有效）：
2、实现一个 BroadcastReceiver 来接收广播：
public class SampleBootReceiver extends BroadcastReceiver {
@Override
public void onReceive(Context context, Intent intent) {
if (intent.getAction().equals("android.intent.action.BOOT_COMPLETED")) {
// Set the alarm here.
}
}
}
3、使用可过滤的 ACTION_BOOT_COMPLETED 操作的 Intent 过滤器将 receiver 添加到应用程序的 manifest 文件中：
android:enabled="false">
4、在 manifest 文件中，将启动 receiver 设置为 android:enabled="false"。这意味着除非应用明确启用 receiver，否则不会被调用，这可以防止启动 receiver 被不必要地调用。可以按如下方式启用 receiver：
ComponentName receiver = new ComponentName(context, SampleBootReceiver.class);
PackageManager pm = context.getPackageManager();
pm.setComponentEnabledSetting(receiver,
PackageManager.COMPONENT_ENABLED_STATE_ENABLED,
PackageManager.DONT_KILL_APP);
以这种方式启用 receiver 后，即使设备被重新启动，receiver 也会保持启用状态。换句话说，通过代码启用 receiver 会覆盖 manifest 文件的设置，即使重新启动也是如此，receiver 将继续启用，直到应用将它关闭。可以按如下方式禁用 receiver：
ComponentName receiver = new ComponentName(context, SampleBootReceiver.class);
PackageManager pm = context.getPackageManager();
pm.setComponentEnabledSetting(receiver,
PackageManager.COMPONENT_ENABLED_STATE_DISABLED,
PackageManager.DONT_KILL_APP);
十、Doze 和 App Standby 模式对 Alarm 的影响
Doze 和 App Standby 模式在安卓 6.0（API 级别 23）中被引入，旨在延长设备电池寿命。当设备处于 Doze 模式时，任何标准 Alarm 都将会延迟，直到设备退出 Doze 模式或维护窗口被打开。如果需要在 Doze 模式下触发 Alarm，可以通过使用 setAndAllowWhileIdle() 或 setExactAndAllowWhileIdle()。应用在一段时间内未被使用，同时应用在前台没有任何进程时，将进入 App Standby 模式。当应用处于 App Standby 模式时，Alarm 会像在 Doze 模式下一样延迟。当应用运行或设备接入电源时，此限制将被解除。
DevEco 检测方案
综上所述，频繁唤醒设备的 Alarm 对设备电池寿命影响较大，华为 DevEco 云测平台通过检测应用在后台灭屏 1 小时内触发唤醒设备 Alarm 的次数来衡量应用是否存在不合理使用 Alarm 的情况。具体测试方法如下：
将应用安装，启动，正常操作几分钟后，回到首页，放置后台，灭屏。执行以下指令：
清理上次的测试数据：adb shell dumpsys batterystats --reset
允许记录所有 wake 信息：adb shell dumpsys batterystats --enable full-wake-history
模拟拔除电缆：adb shell dumpsys battery unplug
一小时后，执行 adb bugreport > bugreport.txt 导出 bugreport 报告
通过分析 bugreport（参考 Battery Historian 的搭建），Wakeup alarm info 里面的 Alarm 累计唤醒次数进行判断。
本文参考《Schedule repeating alarms》进行翻译整理
文章原地址为：