前言

這段時間在看一些IPC相關的東西，這裡面就不可避免的要涉及到service，程序執行緒這些知識點，而且在研究的過程中我驚覺自己對這些東西的記憶已經開始有些模糊了——這可要不得。於是我就乾脆花了點心思溫故了一下，就有了這篇博文。

非常感謝Google的官方文件——尤其是其中部分文章有中文版了之後。

正文

1，什麼是service?

Service是一個可以在後臺執行長時間操作而不使用使用者介面的應用元件。那麼問題來了，既然它不使用使用者介面，那麼它怎麼知道應該什麼時候開始執行什麼操作呢？答案是——它可以與其他的引用元件形成一些聯絡，從而可以根據其傳來的資訊在合適的時候執行合適的操作。

一般來講，這種聯絡分為兩種：startService()以及bindService()。這兩種聯絡都可以使得一個service開始執行，但是在其他方面有著諸多不同。

注：
1.表格中的“其他元件”不包括Broadcast receiver，其無法直接啟動或繫結service。
2.startService()與bindService()並不衝突，同一個service可能既有元件呼叫了startService()啟動它，又有元件與它進行了繫結。當同一個service與其他元件同時存在這兩種聯絡時，其生命週期會發生變化，必須從兩種方法的角度看service均停止才能真正停止。

ok，通過這個表格我們可以知道，這兩種啟動service的方式各有自己的特點，我們可以根據自己的專案需要選擇合適的方式。

2，如何建立一個service？

關於這個，每本Android入門的書籍基本上都會有所提及，基本上也正如它們所述：

• 建立一個類繼承自Service(或它的子類，如IntentService)，重寫裡面的一些關鍵的回撥方法，如onStartCommand()，onBind()等
• 在Manifests檔案裡面為其宣告，並根據需要配置一些其他屬性。

講道理，這一切跟新建一個Activity灰常的像，跟孿生兄弟一樣——包括其裡面的一些關鍵方法，都充斥著一種濃濃的基情。

• onCreate()
  在每個service的生命週期中這個方法會且僅會呼叫一次，並且它的呼叫在onStartCommand()以及onBond()之前，我們可以在這個方法中進行一些一次性的初始化工作。

• onStartCommand()
  當其他元件通過startService()方法啟動service時，此方法將會被呼叫。

• onBind()
  當其他元件通過bindService()方法與service相繫結之後，此方法將會被呼叫。這個方法有一個IBinder的返回值，這意味著在重寫它的時候必須返回一個IBinder物件，它是用來支撐其他元件與service之間的通訊的——另外，如果你不想讓這個service被其他元件所繫結，可以通過在這個方法返回一個null值來實現。

• onDestroy()
  這是service一生中呼叫的最後一個方法，當這個方法被呼叫之後，service就會被銷燬。所以我們應當在這個方法裡面進行一些資源的清理，比如註冊的一些監聽器什麼的。

在Manifests檔案裡進行宣告的時候，只有android:name屬性是必須要有的，其他的屬性都可以沒有。但是有的時候適當的配置可以讓我們的開發進行地更加順利，所以瞭解一下注冊一個service可以宣告哪些屬性也是很有必要的。

<service
    android:enabled=["true" | "false"]
    android:exported=["true" | "false"]
    android:icon="drawable resource"
    android:isolatedProcess=["true" | "false"]
    android:label="string resource"
    android:name="string"
    android:permission="string"
    android:process="string" >
</service>

• android:enabled : 如果為true，則這個service可以被系統例項化，如果為false，則不行。預設為true

• android:exported : 如果為true，則其他應用的元件也可以呼叫這個service並且可以與它進行互動，如果為false，則只有與service同一個應用或者相同user ID的應用可以開啟或繫結此service。它的預設值取決於service是否有intent filters。如果一個filter都沒有，就意味著只有指定了service的準確的類名才能呼叫，也就是說這個service只能應用內部使用——其他的應用不知道它的類名。這種情況下exported的預設值就為false。反之，只要有了一個filter，就意味著service是考慮到外界使用的情況的，這時exported的預設值就為true

• android:icon : 一個象徵著這個service的icon

• android:isolatedProcess : 如果設定為true，這個service將執行在一個從系統中其他部分分離出來的特殊程序中，我們只能通過Service API來與它進行交流。預設為false。

• android:label : 顯示給使用者的這個service的名字。如果不設定，將會預設使用<application>的label屬性。

• android:name : 這個service的路徑名，例如“com.lypeer.demo.MyService”。這個屬性是唯一一個必須填的屬性。

• android:permission : 其他元件必須具有所填的許可權才能啟動這個service。

• android:process : service執行的程序的name。預設啟動的service是執行在主程序中的。

下面是一個例子：

public class ServiceDemo extends Service {

    private static final String TAG = "ServiceDome";

    @Override
    public void onCreate() {
        super.onCreate();
        Log.d(TAG, "onCreate");
        //只在service建立的時候呼叫一次，可以在此進行一些一次性的初始化操作
    }

    @Override
    public int onStartCommand(Intent intent, int flags, int startId) {
        Log.d(TAG, "onStartCommand");
        //當其他元件呼叫startService()方法時，此方法將會被呼叫
        //在這裡進行這個service主要的操作
        return super.onStartCommand(intent, flags, startId);
    }

    @Nullable
    @Override
    public IBinder onBind(Intent intent) {
        Log.d(TAG, "onBind");
        //當其他元件呼叫bindService()方法時，此方法將會被呼叫
        //如果不想讓這個service被繫結，在此返回null即可
        return null;
    }

    @Override
    public void onDestroy() {
        Log.d(TAG, "onDestroy");
        //service呼叫的最後一個方法
        //在此進行資源的回收
        super.onDestroy();
    }
}

<!--in manifests -->
<service android:name=".ServiceDemo"/>

3，如何啟動service？

前面講了兩種啟動service的方式，但是都講的比較概括，這裡就詳細的講一下這兩種方式。

3.1，startService()

另一個元件通過呼叫startService()方法，就可以啟動一個特定的service，並且這將導致service中的onStartCommand()方法被呼叫。在呼叫startService()方法的時候，其他元件需要在方法中傳遞一個intent引數，然後service將會在onStartCommand()中接收這個intent，並獲取一些資料。比如此時某個Activity要將一些資料存入資料庫中，我就可以通過intent把資料傳入service，然後讓service去進行連線資料庫，儲存資料等操作，而此時使用者可以執行其他的任何操作——甚至包括銷燬那個Activity——這並不會影響service儲存資料這件事。

當一個service通過這種方式啟動之後，它的生命週期就已經不受啟動它的元件影響了，它可以在後臺無限期的執行下去，只要service自身沒有呼叫stopSelf()並且其他的元件沒有呼叫針對它的stopService()。

另外，如果確定了使用這種方式啟動service並且不希望這個service被繫結的話，那麼也許除了傳統的建立一個類繼承service之外我們有一個更好的選擇——繼承IntentService。

如果是擴建Service類的話，通常情況下我們需要新建一個用於執行工作的新執行緒，因為預設情況下service將工作於應用的主執行緒，而這將會降低所有正在執行的Activity的效能。而IntentService就不同了。它是Service的子類，它使用工作執行緒來注意的處理所有的startService請求。如果你不要求這個service要同時處理多個請求，那麼繼承這個類顯然要比直接繼承Service好到不知道哪裡去了——IntentService已經做了這些事：

• 建立預設的工作執行緒，用於在應用的主執行緒外執行傳遞給 onStartCommand() 的所有 Intent
• 建立工作佇列，用於將一個 Intent 逐一傳遞給 onHandleIntent() 實現，這樣的話就永遠不必擔心多執行緒問題了
• 在處理完所有啟動請求後停止服務，從此媽媽再也不用擔心我忘記呼叫 stopSelf() 了
• 提供 onBind() 的預設實現（返回 null）
• 提供 onStartCommand() 的預設實現，可將 Intent 依次傳送到工作佇列和 onHandleIntent() 實現

因此我們只需要實現onHandleIntent()方法來完成具體的功能邏輯就可以了。

6不6？必須6！下面是一個栗子：

//現在在一個Activity裡面
Intent intent = new Intent(MainActivity.this , IntentServiceDemo.class);
startService(intent);

public class IntentServiceDemo extends IntentService {

    public IntentServiceDemo(String name) {
        super(name);
        //構造方法
    }

    @Override
    protected void onHandleIntent(Intent intent) {
        //在這裡根據intent進行操作
    }
}

相比上面的繼承service實現，這個確實要簡單許多。但是要注意的是，如果需要重寫其他的方法，比如onDestroy()方法，一定不要刪掉它的超類實現！因為它的超類實現裡面也許包括了對工作執行緒還有工作佇列的初始化以及銷燬等操作，如果沒有了的話很容易出問題。

但是，如果你有讓service同時處理多個請求的需求，這個時候就只能去繼承Service了。這個時候就要自己去處理工作執行緒那些事。下面是一個官方的栗子：

public class HelloService extends Service {
  private Looper mServiceLooper;
  private ServiceHandler mServiceHandler;

  private final class ServiceHandler extends Handler {
      public ServiceHandler(Looper looper) {
          super(looper);
      }
      @Override
      public void handleMessage(Message msg) {
          long endTime = System.currentTimeMillis() + 5*1000;
          while (System.currentTimeMillis() < endTime) {
              synchronized (this) {
                  try {
                      wait(endTime - System.currentTimeMillis());
                  } catch (Exception e) {
                  }
              }
          }
          stopSelf(msg.arg1);
      }
  }

  @Override
  public void onCreate() {
    HandlerThread thread = new HandlerThread("ServiceStartArguments",
            Process.THREAD_PRIORITY_BACKGROUND);
    thread.start();
    mServiceLooper = thread.getLooper();
    mServiceHandler = new ServiceHandler(mServiceLooper);
  }

  @Override
  public int onStartCommand(Intent intent, int flags, int startId) {
      Toast.makeText(this, "service starting", Toast.LENGTH_SHORT).show();

      Message msg = mServiceHandler.obtainMessage();
      msg.arg1 = startId;
      mServiceHandler.sendMessage(msg);

      return START_STICKY;
  }

  @Override
  public IBinder onBind(Intent intent) {
      return null;
  }

  @Override
  public void onDestroy() {
    Toast.makeText(this, "service done", Toast.LENGTH_SHORT).show();
  }
}

比起IntentService來，顯然做的工作要多的多的多。但是，由於是自己處理的對onStartCommand的呼叫，它可以同時執行多個請求——雖然官方的栗子裡沒有這樣做。但是如果你想這樣做，就可以為每一個請求建立一個執行緒，然後立即執行這些請求。

另外，我們注意到onStartCommand()的返回值是一個很奇怪的值START_STICKY，這是個什麼呢？或者說這個方法的返回值是用來幹嘛的呢？事實上，它的返回值是用來指定系統對當前執行緒的行為的。它的返回值必須是以下常量之一：
- START_NOT_STICKY : 如果系統在 onStartCommand() 返回後終止服務，則除非有掛起 Intent 要傳遞，否則系統不會重建服務。這是最安全的選項，可以避免在不必要時以及應用能夠輕鬆重啟所有未完成的作業時執行服務。

• START_STICKY : 如果系統在 onStartCommand() 返回後終止服務，則會重建服務並呼叫 onStartCommand()，但絕對不會重新傳遞最後一個 Intent。相反，除非有掛起 Intent 要啟動服務（在這種情況下，將傳遞這些 Intent ），否則系統會通過空 Intent 呼叫 onStartCommand()。這適用於不執行命令、但無限期執行並等待作業的媒體播放器（或類似服務）。

• START_REDELIVER_INTENT : 如果系統在 onStartCommand() 返回後終止服務，則會重建服務，並通過傳遞給服務的最後一個 Intent 呼叫 onStartCommand()。任何掛起 Intent 均依次傳遞。這適用於主動執行應該立即恢復的作業（例如下載檔案）的服務。

除此之外，繼承service來實現的service，一定要記得，停止這個service。因為除非系統必須回收記憶體資源，否則系統不會停止或銷燬service。事實上，如果這個service是與可見元件繫結，其幾乎永遠不會被停止或銷燬。在這種情況下，如果你忘記了在其工作完成之後將其停止，勢必會造成系統資源的浪費以及電池電量的消耗，而這應當是我們要極力避免的。

3.2，bindService()

這是一種比startService更復雜的啟動方式，同時使用這種方式啟動的service也能完成更多的事情，比如其他元件可向其傳送請求，接受來自它的響應，甚至通過它來進行IPC等等。我們通常將繫結它的元件成為客戶端，而稱它為伺服器。

如果要建立一個支援繫結的service，我們必須要重寫它的onBind()方法。這個方法會返回一個IBinder物件，它是客戶端用來和伺服器進行互動的介面。而要得到IBinder介面，我們通常有三種方式：繼承Binder類，使用Messenger類，使用AIDL。

這三種方式也是各有各的好處以及缺點，更多的講解將放在下一篇部落格中進行。

結語

這篇部落格主要講了關於service的一些東西，包括什麼是service，如何建立service，如何啟動一個service等等，另外還有很多的東西沒有講，包括bindService()的細節，如何選用合適的方式啟動service，如何在前臺執行服務等等，這些內容將放在下一篇部落格中： Android中的Service：Binder，Messenger，AIDL（2）

總的來說，這篇部落格在很多方面研究的還非常的淺顯，比如IntentService內部是如何封裝的？從startService()到onStartCommand()中間進行了些什麼？IBinder()到底是個啥東西，為什麼要用它來進行互動？

——所以這只是一篇類似於科普文一樣的文章，請不要吐槽它的深度。

再次感謝Google。