Android定时服务

Android定时服务有两种方式，一种是JavaAPI里面的Timer类，一种是Android的Alarm机制。这两种方式在多数情况下都能实现类似的效果， 但 Timer有一个明显的短板，它并不太适用于那些需要长期在后台运行的定时任务。我们都知道，为了能让电池更加耐用，每种手机都会有自己的休眠策略，Android 手机就会在长时间不操作的情况下自动让 CPU 进入到睡眠状态，这就有可能导致 Timer 中的定时任务无法正常运行。而 Alarm 机制则不存在这种情况，它具有唤醒 CPU 的功能，即可以保证每次需要执行定时任务的时候 CPU 都能正常工作。 需要注意， 这里唤醒 CPU 和唤醒屏幕完全不是同一个概念，千万不要产生混淆。
首先看一下Alarm机制的用法，比如我们要设置一个任务在10s后执行。

// 获取一个AlarmManager的实例
AlarmManager manager = (AlarmManager)getSystemService(ALARM_SERVICE);
//设置定时
long triggerAtMillis = SystemClock.elapsedRealtime() + 10 * 1000;
Intent i = new Intent(this, AlarmReciver.class);
PendingIntent operation = PendingIntent.getBroadcast(this, 0, i, 0);
manager.set(AlarmManager.ELAPSED_REALTIME_WAKEUP,triggerAtMillis,operation);

set()需要三个参数。第一个参数是一个整型参数，用于指定 AlarmManager的工作类型，有四种值可选，分别是 ELAPSED_REALTIME、ELAPSED_REALTIME_WAKEUP、RTC 和 RTC_WAKEUP。其中 ELAPSED_REALTIME 表示让定时任务的触发时间从系统开机开始算起，但不会唤CPU。ELAPSED_REALTIME_WAKEUP 同样表示让定时任务的触发时间从系统开机开始算起，但会唤醒 CPU。RTC 表示让定时任务的触发时间从 1970 年 1月 1 日 0 点开始算起，但不会唤醒 CPU。RTC_WAKEUP 同样表示让定时任务的触发时间从1970 年 1 月 1 日 0 点开始算起，但会唤醒 CPU。使用 SystemClock.elapsedRealtime()方法可以获取到系统开机至今所经历时间的毫秒数，使用 System.currentTimeMillis()方法可以获取到 1970 年 1 月 1 日 0 点至今所经历时间的毫秒数。
然后看一下第二个参数，这个参数就好理解多了，就是定时任务触发的时间，以毫秒为单位。如果第一个参数使用的是 ELAPSED_REALTIME或 ELAPSED_REALTIME_WAKEUP，则这里传入开机至今的时间再加上延迟执行的时间。如果第一个参数使用的是RTC或RTC_WAKEUP，则这里传入 1970 年 1 月 1 日 0 点至今的时间再加上延迟执行的时间。
第三个参数是一个 PendingIntent。这里我们一般会调用 getBroadcast()方法来获取一个能够执行广播的 PendingIntent。 这样当定时任务被触发的时候，广播接收器的 onReceive()方法就可以得到执行。

public class AlarmReciver extends BroadcastReceiver {

    @Override
    public void onReceive(Context context, Intent intent) {
        Intent i = new Intent(context, LongRunningService.class);
        context.startService(i);
    }

}

这样就形成了一个死循环。