第一行代码-9.6 服务的最佳实践--后台执行的定时任务

　　首先说明一下Android实现定时任务的方法，这里用第一行代码的原话来讲。
　　Android 中的定时任务一般有两种实现方式，一种是使用Java API 里提供的Timer 类，一种是使用Android 的Alarm 机制。这两种方式在多数情况下都能实现类似的效果，但Timer有一个明显的短板，它并不太适用于那些需要长期在后台运行的定时任务。我们都知道，为了能让电池更加耐用，每种手机都会有自己的休眠策略，Android 手机就会在长时间不操作的情况下自动让CPU 进入到睡眠状态，这就有可能导致Timer 中的定时任务无法正常运行。而Alarm 机制则不存在这种情况，它具有唤醒CPU 的功能，即可以保证每次需要执行定时任务的时候CPU 都能正常工作。需要注意，这里唤醒CPU 和唤醒屏幕完全不是同一个概念，千万不要产生混淆。
　　那么首先我们来看一下Alarm 机制的用法吧，其实并不复杂，主要就是借助了AlarmManager 类来实现的。这个类和NotificationManager 有点类似，都是通过调用Context 的getSystemService()方法来获取实例的，只是这里需要传入的参数是Context.ALARM_SERVICE。因此，获取一个AlarmManager 的实例就可以写成：

AlarmManager manager = (AlarmManager)getSystemService(Context.ALARM_SERVICE);

　　接下来调用AlarmManager 的set()方法就可以设置一个定时任务了，比如说想要设定一个任务在10 秒钟后执行，就可以写成：

long triggerAtTime = SystemClock.elapsedRealtime() + 10 * 1000;manager.set(AlarmManager.ELAPSED_REALTIME_WAKEUP, triggerAtTime, pendingIntent);

　　上面的两行代码你不一定能看得明白，因为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()方法就可以得到执行。
　　了解了set()方法的每个参数之后，你应该能想到，设定一个任务在10 秒钟后执行还可以写成：

long triggerAtTime = System.currentTimeMillis() + 10 * 1000;manager.set(AlarmManager.RTC_WAKEUP, triggerAtTime, pendingIntent);

　　所以如果要设置一个定时的任务，比如每10s执行一次的服务，就可以设置在服务中过10s发送一次广播，然后在广播接收器中再开启服务就可以了。
　　创建工程ServiceBestPractice，然后创建服务：

// LongRunningService.javapublic class LongRunningService extends Service{    @Override    public IBinder onBind(Intent arg0) {        return null;    }    @Override    public int onStartCommand(Intent intent, int flags, int startId) {        new Thread(new Runnable() {            @Override            public void run() {                // 这里执行一些耗时的操作，简单起见没有举例，只是输出了当前的时间                Log.d("LongRunningService", "运行于"+new Date().toString());            }        }).start();        // 设置Alarm，10秒之后发送一条广播        AlarmManager manager = (AlarmManager) getSystemService(ALARM_SERVICE);        int anHour = 60*60*1000; // 一小时的毫秒数        long triggerAtTime = SystemClock.elapsedRealtime() + anHour;        Intent i = new Intent(this, AlarmReceiver.class);        PendingIntent pi = PendingIntent.getBroadcast(this, 0, i, 0);        manager.set(AlarmManager.ELAPSED_REALTIME_WAKEUP, triggerAtTime, pi);        return super.onStartCommand(intent, flags, startId);    }   }

　　然后创建广播接收器，并在其中再次开启服务：

// AlarmReceiver.javapublic class AlarmReceiver extends BroadcastReceiver{    @Override    public void onReceive(Context context, Intent intent) {        // 开启服务        Intent i = new Intent(context, LongRunningService.class);        context.startService(i);    }}

　　然后在MainActivity中启动服务：

// MainActivity.java - onCreate()Intent intent = new Intent(this, LongRunningService.class);startService(intent);

　　最后别忘了，广播接收器和服务都要注册：

<service android:name="com.example.servicebestpractice.LongRunningService">service><receiver android:name="com.example.servicebestpractice.AlarmReceiver">receiver>

　　但是一个小时太长了，现在我改成10秒后发送一条广播，最终效果如下：
第一行代码-9.6 服务的最佳实践--后台执行的定时任务_第1张图片
　　另外需要注意的是，从Android 4.4 版本开始，Alarm 任务的触发时间将会变得不准确，有可能会延迟一段时间后任务才能得到执行。这并不是个bug，而是系统在耗电性方面进行的优化。系统会自动检测目前有多少Alarm 任务存在，然后将触发时间将近的几个任务放在一起执行，这就可以大幅度地减少CPU 被唤醒的次数，从而有效延长电池的使用时间。
　　当然，如果你要求Alarm 任务的执行时间必须准备无误，Android 仍然提供了解决方案。使用AlarmManager 的setExact()方法来替代set()方法，就可以保证任务准时执行了。

更多相关文章

随机推荐