Android中（Service )服务的最佳实践——后台执行的定时任务

快来打我* 2022-08-04 04:23 293阅读 0赞

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);

好了，现在你已经掌握Alarm机制的基本用法，下面我们就来创建一个可以长期在后台执行定时任务的服务。创建一个ServiceBestPractice项目，然后新增一个LongRunningService类，代码如下所示：

public class LongRunningService extends Service {  
     @Override 
     public IBinder onBind(Intent intent) {
       return null;
      } 
      @Override 
     public int onStartCommand(Intent intent, int flags, int startId) {
       new Thread(new Runnable() {    
      @Override  
      public void run() {  
     Log.d("LongRunningService", "executed at " + new Date(). toString()); 
       }   }).start(); 
      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); 
     } 
     }

我们在onStartCommand()方法里开启了一个子线程，然后在子线程里就可以执行具体的逻辑操作了。这里简单起见，只是打印了一下当前的时间。   
创建线程之后的代码就是我们刚刚讲解的Alarm机制的用法了，先是获取到了AlarmManager的实例，然后定义任务的触发时间为一小时后，再使用PendingIntent指定处理定时任务的广播接收器为AlarmReceiver，最后调用set()方法完成设定。   
显然，AlarmReceiver目前还不存在呢，所以下一步就是要新建一个AlarmReceiver类，并让它继承自BroadcastReceiver，代码如下所示：

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

onReceive()方法里的代码非常简单，就是构建出了一个Intent对象，然后去启动LongRunningService这个服务。那么这里为什么要这样写呢？其实在不知不觉中，这就已经将一个长期在后台定时运行的服务完成了。因为一旦启动LongRunningService，就会在onStartCommand()方法里设定一个定时任务，这样一小时后AlarmReceiver的onReceive()方法就将得到执行，然后我们在这里再次启动LongRunningService，这样就形成了一个永久的循环，保证LongRunningService可以每隔一小时就会启动一次，一个长期在后台定时运行的服务自然也就完成了。

接下来的任务也很明确了，就是我们需要在打开程序的时候启动一次LongRunningService，之后LongRunningService就可以一直运行了。修改MainActivity中的代码，如下所示：

public class MainActivity extends Activity {  
     @Override 
     protected void onCreate(Bundle savedInstanceState) {  
     super.onCreate(savedInstanceState); 
      Intent intent = new Intent(this, LongRunningService.class);   
      startService(intent); 
     } 
     }

最后别忘了，我们所用到的服务和广播接收器都要在AndroidManifest.xml中注册才行，代码如下所示：

现在就可以来运行一下程序了。虽然你不会在界面上看到任何有用的信息，但实际上LongRunningService已经在后台悄悄地运行起来了。为了能够验证一下运行结果，我将手机闲置了几个小时，然后观察LogCat中的打印日志，。

longRuntimingService  extecuted at sat Nov 30 16:03:07  GTM+00:00 2014
        longRuntimingService  extecuted at sat Nov 30 17:03:07  GTM+00:00 2014
        longRuntimingService  extecuted at sat Nov 30 18:03:07  GTM+00:00 2014
       longRuntimingService  extecuted at sat Nov 30 19:03:07  GTM+00:00 2014

可以看到，LongRunningService果然如我们所愿地运行着，每隔一小时都会打印一条日志。这样，当你真正需要去执行某个定时任务的时候，只需要将打印日志替换成具体的任务逻辑就行了。   
另外需要注意的是，从Android 4.4版本开始，Alarm任务的触发时间将会变得不准确，有可能会延迟一段时间后任务才能得到执行。这并不是个bug，而是系统在耗电性方面进行的优化。系统会自动检测目前有多少Alarm任务存在，然后将触发时间将近的几个任务放在一起执行，这就可以大幅度地减少CPU被唤醒的次数，从而有效延长电池的使用时间。   
当然，如果你要求Alarm任务的执行时间必须准备无误，Android仍然提供了解决方案。使用AlarmManager的setExact()方法来替代set()方法，就可以保证任务准时执行了。   
好了，最佳实践部分到此结束。逻辑操作了。这里简单起见，只是打印了一下当前的时间。

Android中（Service )服务的最佳实践——后台执行的定时任务

发表评论取消回复

还没有评论，来说两句吧...

相关阅读