原文地址
Da Real Fragmentation - Alarms
这一个系列主要是讲解Android系统中的Alarms （闹钟）和Sensors（传感器），以及Doze系统对于这些寻常的行为产生的影响。
Alarms
在平常的开发中可能需要调度一系列任务的执行，它们可能是在后台工作，甚至是App进程不在的时候。举个例子，你可能需要在一段时间后发送一个通知或者是定期检查一下某个事件是否产生，一般我们通过 alarms 来实现这些操作。
在Android中根据调度任务的频繁程度，前台还是后台操作或者是 minSdkVersion 的版本这些不同的需求就会产生不同的实现方式。
在一些场景中，可以使用一个简单的 postDelayed() loop循环，但是这种方式的局限之处就是必须保证进程是存活的，如果不能满足这个条件，最好还是使用 ****AlarmManager****，或者是在Lollipop中介绍的****JobScheduler****。一般为了方便，第一选择就是 ****AlarmManager****，但是我们会探索几种不同的操作，并且解释这些操作的优点和缺点，以及 Doze 模式对其产生的影响。JobScheduler 会在接下来的文章中讲到。
Options
为了设置一个闹钟，首先，我们需要了解不同的选项，我们先回顾一下。
- 我们应该分析我们的闹钟是否需要唤醒设备。想象一下，设备从活跃的状态经过一段时间进入睡眠模式，这意味着CPU没有工作，而且系统停止了。在这种情况下，我们只能依靠GSM或者CDMA 广播以及 AlarmManager，持有一个 WakeLock 来维持整个设置保持唤醒的状态，来免于系统进入睡眠模式。所以，如果你想要确保闹钟在预定时间响应，就应该使用
wakeup的版本，但是为了节省电量这种操作也是不被推荐的。另外，如果你并没有设置成wakeup并且设备处于睡眠模式，闹钟就会在下一次设备唤醒的时候被触发。 - 我们可以配置调度的频率。实际上，我们可以考虑设置一次性的闹钟或者是根据一段时间间隔来重复这个闹钟。对于重复性的闹钟，需要小心处理因为如果没有合理的设计那么就会滥用系统的资源。
- 另一个值得考虑的决定就是闹钟是否需要足够的 准确，闹钟有两种模式，准确的以及不准确的，精确 的闹钟会在预定的时间按时发生，而对于不精确的闹钟，Android系统会将一段时间内的多个非精确闹钟合在一起统一来操作，这样能够减少电量的消耗。从这个方面考虑。我们需要尽量避免使用精确的闹钟。
- Android对于闹钟服务支持两种 clock类型：已经经过的时间以及真实的时间（RTC）。第一种对应的时间是指从上一次设备启动相对于现在所经过的时间，第二种使用的是 UTC（世界标准时间） 的统一精确时间。也就是说对于第一种类型适合基于一段时间的闹钟，比如轮询操作。而如果设置基于真实的世界时间的闹钟，这种比较适合比如日历的通知以及时钟的提醒。相较而言，第一种也就是相对时间是一种更好的选择，因为如果用户修改了locale（比如en -> zh）或者设备时间可能会导致App产生一些意料之外的行为。而且，如果你使用真实的世界时给App设置一个具体的时间来同步一个服务可能会造成时间并不是那么准备，当所有的服务同时启动的时候可能会造成一定的延迟或者混乱。
- 最后，我们需要告诉系统当alarm发生时做什么，通过提供一个
PendingIntent可以达到目的。
Types
下面就是一些不同的可用的闹钟类型列表。
- ELAPSED_REALTIME:基于上次设备启动的时间到经过的时间来触发pending intent，但是并不唤醒设备。这个过去时间包括了当设备处于睡眠状态的时间。
- ELAPSED_REALTIME_WAKEUP: 和上面相比就是多了一个唤醒设备，其他是一样的。
- RTC:RTC模式采取的是指定的世界时的方式，当到达指定时间就触发pending intent，并且不唤醒设备。
- RTC_WAKEUP: 同样相比上面就是多了一个唤醒设备。
Methods
在 AlarmManager 中有一系列方法来帮助构建一个alarm。下面就会详细描述每个方法的功能。
- [set()
](https://developer.android.com/reference/android/app/AlarmManager.html#set(int, long, android.app.PendingIntent)):自API 1中加入，在Android 4.3（API 18）以及以前这个方法和setExact()表现一样，但是从API 19开始，这个方法的触发时间可能会被延迟一段时间。和其他的非精确策略一样，这是为了批处理闹钟来达到减少设备唤醒的次数提升电池的效率的目的。而且请注意这个处理的顺序可能和我们设置的时间顺序并不相同。如果你的应用对排序需求比较强烈，那么还是使用setExact()或setWindow()。 - [setExact()
](https://developer.android.com/reference/android/app/AlarmManager.html#setExact(int, long, android.app.PendingIntent)): 在规定的时间准确的被调度，这个方法在API 19被加入，在4.4及以上，主要用来设置一个一次性的闹钟。 - [setWindow()
](https://developer.android.com/reference/android/app/AlarmManager.html#setWindow(int, long, long, android.app.PendingIntent)): 在规定的时间段（区间）内被调度，这个方法同样在API 19加入，它允许系统自己决定一个区间内的某一个时刻触发。 - [setRepeating()
](https://developer.android.com/reference/android/app/AlarmManager.html#setRepeating(int, long, long, android.app.PendingIntent)):调度一个重复的闹钟，主要被用来固定频率的触发闹钟。一个重复闹钟主要有以下几种参数：
1.一个闹钟的类型，指定一个使用时间的单位，以及判断是否在睡眠模式下被触发的类型。
2.触发的时间，如果触发的时间设置在当前时间之前，这个闹钟会立刻触发。
3.闹钟的间隔，设置之后重复的间隔时间，这里需要注意的是在5.1之后的版本中，最小的时间间隔变成一个1分钟(60000毫秒)，如果设置一个小于这个数的值，那么就会自动转化成一分钟。这个时间间隔强制性的改变是不会被设置的targetSdkVersion版本所影响。
4.在闹钟被触发的PendingIntent，如果你设置了第二个闹钟，并且使用了同样的一个延时意图，那么后设置的就会代替原来的。
需要注意的是：在Android4.4或者以上的版本，setRepeating()这个方法和另一个方法setInexactRepeating()表现是一样的，也就是说，所有的重复闹钟都是非精确的。所以，如果应用想要精确的时间，那么必须使用一次性的闹钟模式。
另外的一个需要注意的地方就是，在Android 5.1及更高的版本，闹钟设置的时间必须至少从当前时间延迟5秒，
如果在5秒之内那么这个闹钟就不会被触发。
Conclusion
经过上面的选项以及方法的描述就能看出Android系统中这个Alarm服务的碎片化。
当然这么多字看起来不太直观，那么放一张图出来看看整个步骤。
整个Alarm的分析就到这里，鉴于篇幅原因，在下一篇文章中将会讲解 Doze 系统以及其对于电量的优化导致对Alarm的影响
想要更简单的了解可以check 这个项目 playground 的sample。
备注
这里给出一个简单的创建alarm的例子
private void setSchedule(int day,int min,int sec){
AlarmManager alarmManager = (AlarmManager) getSystemService(Context.ALARM_SERVICE);
Intent intent = new Intent(this,ScheduleReceiver.class);
Calendar calendar = Calendar.getInstance();
calendar.setTimeInMillis(System.currentTimeMillis());
calendar.set(Calendar.HOUR_OF_DAY, day);
calendar.set(Calendar.MINUTE, min);
calendar.set(Calendar.SECOND, sec);
if (calendar.before(Calendar.getInstance())){
return;
}
if (mPending != null){
alarmManager.cancel(mPending);
}
mPending = PendingIntent.getBroadcast(this,0,intent,0);
alarmManager.set(AlarmManager.RTC_WAKEUP,calendar.getTimeInMillis(),mPending);
}
