Android中（Service )服務的最佳實踐——背景執行的定時任務

版權聲明：本文為部落客原創文章，未經部落客允許不得轉載。 https://blog.csdn.net/u010046908/article/details/47727367

            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中注冊才行，代碼如下所示：

<manifest xmlns:android="http://schemas.android.com/apk/res/android"     package="com.example.servicebestpractice"     android:versionCode="1" 
    android:versionName="1.0" >  „„ 
    <application 
        android:allowBackup="true" 
        android:icon="@drawable/ic_launcher"        
     android:label="@string/app_name"         
    android:theme="@style/AppTheme" > 
        <activity 
            android:name="com.example.servicebestpractice.MainActivity"            
 android:label="@string/app_name" >            
 <intent-filter> 
                <action android:name="android.intent.action.MAIN" /> 
                <category android:name="android.intent.category.LAUNCHER" />        
     </intent-filter>        
 </activity> 
        <service android:name=".LongRunningService" >   </service> 
        <receiver android:name=".AlarmReceiver" >   </receiver>   
 </application> 
</manifest>            

現在就可以來運作一下程式了。雖然你不會在界面上看到任何有用的資訊，但實際上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()方法，就可以保證任務準時執行了。 

好了，最佳實踐部分到此結束。邏輯操作了。這裡簡單起見，隻是列印了一下目前的時間。