關於Android Service真正的完全詳解，你需要知道的一切

轉載請註明出處（萬分感謝！）：
http://blog.csdn.net/javazejian/article/details/52709857
出自【zejian的博客】

Service全部內容基本會在本篇涉及到，我們將圍繞以下主要知識點進行分析：

Service簡單概述
Service在清單文件中的聲明
Service啓動服務實現方式及其詳解
Service綁定服務的三種實現方式
關於啓動服務與綁定服務間的轉換問題
前臺服務以及通知發送
服務Service與線程Thread的區別
管理服務生命週期的要點
Android 5.0以上的隱式啓動問題及其解決方案
保證服務不被殺死的實現思路

1.Service簡單概述

Service(服務)是一個一種可以在後臺執行長時間運行操作而沒有用戶界面的應用組件。服務可由其他應用組件啓動（如Activity），服務一旦被啓動將在後臺一直運行，即使啓動服務的組件（Activity）已銷燬也不受影響。此外，組件可以綁定到服務，以與之進行交互，甚至是執行進程間通信 (IPC)。例如，服務可以處理網絡事務、播放音樂，執行文件 I/O 或與內容提供程序交互，而所有這一切均可在後臺進行，Service基本上分爲兩種形式：

啓動狀態

當應用組件（如 Activity）通過調用 startService() 啓動服務時，服務即處於“啓動”狀態。一旦啓動，服務即可在後臺無限期運行，即使啓動服務的組件已被銷燬也不受影響，除非手動調用才能停止服務，已啓動的服務通常是執行單一操作，而且不會將結果返回給調用方。

綁定狀態

當應用組件通過調用 bindService() 綁定到服務時，服務即處於“綁定”狀態。綁定服務提供了一個客戶端-服務器接口，允許組件與服務進行交互、發送請求、獲取結果，甚至是利用進程間通信 (IPC) 跨進程執行這些操作。僅當與另一個應用組件綁定時，綁定服務纔會運行。多個組件可以同時綁定到該服務，但全部取消綁定後，該服務即會被銷燬。

2.Service在清單文件中的聲明

前面說過Service分爲啓動狀態和綁定狀態兩種，但無論哪種具體的Service啓動類型，都是通過繼承Service基類自定義而來，也都需要在AndroidManifest.xml中聲明，那麼在分析這兩種狀態之前，我們先來了解一下Service在AndroidManifest.xml中的聲明語法，其格式如下：

<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:exported：代表是否能被其他應用隱式調用，其默認值是由service中有無intent-filter決定的，如果有intent-filter，默認值爲true，否則爲false。爲false的情況下，即使有intent-filter匹配，也無法打開，即無法被其他應用隱式調用。
android:name：對應Service類名
android:permission：是權限聲明
android:process：是否需要在單獨的進程中運行,當設置爲android:process=”:remote”時，代表Service在單獨的進程中運行。注意“：”很重要，它的意思是指要在當前進程名稱前面附加上當前的包名，所以“remote”和”:remote”不是同一個意思，前者的進程名稱爲：remote，而後者的進程名稱爲：App-packageName:remote。
android:isolatedProcess ：設置 true 意味着，服務會在一個特殊的進程下運行，這個進程與系統其他進程分開且沒有自己的權限。與其通信的唯一途徑是通過服務的API(bind and start)。
android:enabled：是否可以被系統實例化，默認爲 true因爲父標籤也有 enable 屬性，所以必須兩個都爲默認值 true 的情況下服務纔會被激活，否則不會激活。
ok~，關於Service在清單文件的聲明我們先了解這些就行，接下來分別針對Service啓動服務和綁定服務進行詳細分析

3.Service啓動服務

首先要創建服務，必須創建 Service 的子類（或使用它的一個現有子類如IntentService）。在實現中，我們需要重寫一些回調方法，以處理服務生命週期的某些關鍵過程，下面我們通過簡單案例來分析需要重寫的回調方法有哪些？

package com.zejian.ipctest.service;

import android.app.Service;
import android.content.Intent;
import android.os.IBinder;
import android.support.annotation.Nullable;

/**
 * Created by zejian
 * Time 2016/9/29.
 * Description:service simple demo
 */
public class SimpleService extends Service {

    /**
     * 綁定服務時纔會調用
     * 必須要實現的方法  
     * @param intent
     * @return
     */
    @Nullable
    @Override
    public IBinder onBind(Intent intent) {
        return null;
    }

    /**
     * 首次創建服務時，系統將調用此方法來執行一次性設置程序（在調用 onStartCommand() 或 onBind() 之前）。
     * 如果服務已在運行，則不會調用此方法。該方法只被調用一次
     */
    @Override
    public void onCreate() {
        System.out.println("onCreate invoke");
        super.onCreate();
    }

    /**
     * 每次通過startService()方法啓動Service時都會被回調。
     * @param intent
     * @param flags
     * @param startId
     * @return
     */
    @Override
    public int onStartCommand(Intent intent, int flags, int startId) {
        System.out.println("onStartCommand invoke");
        return super.onStartCommand(intent, flags, startId);
    }

    /**
     * 服務銷燬時的回調
     */
    @Override
    public void onDestroy() {
        System.out.println("onDestroy invoke");
        super.onDestroy();
    }
}

從上面的代碼我們可以看出SimpleService繼承了Service類，並重寫了onBind方法，該方法是必須重寫的，但是由於此時是啓動狀態的服務，則該方法無須實現，返回null即可，只有在綁定狀態的情況下才需要實現該方法並返回一個IBinder的實現類（這個後面會詳細說），接着重寫了onCreate、onStartCommand、onDestroy三個主要的生命週期方法，關於這幾個方法說明如下:

onBind()

當另一個組件想通過調用 bindService() 與服務綁定（例如執行 RPC）時，系統將調用此方法。在此方法的實現中，必須返回一個IBinder 接口的實現類，供客戶端用來與服務進行通信。無論是啓動狀態還是綁定狀態，此方法必須重寫，但在啓動狀態的情況下直接返回 null。

onCreate()

首次創建服務時，系統將調用此方法來執行一次性設置程序（在調用 onStartCommand() 或onBind() 之前）。如果服務已在運行，則不會調用此方法，該方法只調用一次

onStartCommand()

當另一個組件（如 Activity）通過調用 startService() 請求啓動服務時，系統將調用此方法。一旦執行此方法，服務即會啓動並可在後臺無限期運行。如果自己實現此方法，則需要在服務工作完成後，通過調用 stopSelf() 或 stopService() 來停止服務。（在綁定狀態下，無需實現此方法。）

onDestroy()

當服務不再使用且將被銷燬時，系統將調用此方法。服務應該實現此方法來清理所有資源，如線程、註冊的偵聽器、接收器等，這是服務接收的最後一個調用。

我們通過Demo測試一下Service啓動狀態方法的調用順序，MainActivity代碼如下：

package com.zejian.ipctest;

import android.content.Intent;
import android.os.Bundle;
import android.support.v7.app.AppCompatActivity;
import android.view.View;
import android.widget.Button;

import com.zejian.ipctest.service.SimpleService;

public class MainActivity extends AppCompatActivity implements View.OnClickListener {

    private Button startBtn;
    private Button stopBtn;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        startBtn= (Button) findViewById(R.id.startService);
        stopBtn= (Button) findViewById(R.id.stopService);
        startBtn.setOnClickListener(this);
        assert stopBtn != null;
        stopBtn.setOnClickListener(this);
    }

    @Override
    public void onClick(View v) {
        Intent it=new Intent(this, SimpleService.class);
        switch (v.getId()){
            case R.id.startService:
                startService(it);
                break;
            case R.id.stopService:
                stopService(it);
                break;
        }
    }
}

記得在清單配置文件中聲明Service(聲明方式跟Activity相似)：

<manifest ... >
  ...
  <application ... >
      <service android:name=".service.SimpleService" />
      ...
  </application>
</manifest>

從代碼看出，啓動服務使用startService(Intent intent)方法，僅需要傳遞一個Intent對象即可，在Intent對象中指定需要啓動的服務。而使用startService()方法啓動的服務，在服務的外部，必須使用stopService()方法停止，在服務的內部可以調用stopSelf()方法停止當前服務。如果使用startService()或者stopSelf()方法請求停止服務，系統會就會盡快銷燬這個服務。值得注意的是對於啓動服務，一旦啓動將與訪問它的組件無任何關聯，即使訪問它的組件被銷燬了，這個服務也一直運行下去，直到手動調用停止服務才被銷燬，至於onBind方法，只有在綁定服務時纔會起作用，在啓動狀態下，無需關注此方法，ok~，我們運行程序並多次調用startService方法，最後調用stopService方法。Log截圖如下：

從Log可以看出，第一次調用startService方法時，onCreate方法、onStartCommand方法將依次被調用，而多次調用startService時，只有onStartCommand方法被調用，最後我們調用stopService方法停止服務時onDestory方法被回調，這就是啓動狀態下Service的執行週期。接着我們重新回過頭來進一步分析onStartCommand（Intent intent, int flags, int startId），這個方法有3個傳入參數，它們的含義如下：

onStartCommand（Intent intent, int flags, int startId）

intent ：啓動時，啓動組件傳遞過來的Intent，如Activity可利用Intent封裝所需要的參數並傳遞給Service
flags：表示啓動請求時是否有額外數據，可選值有 0，START_FLAG_REDELIVERY，START_FLAG_RETRY，0代表沒有，它們具體含義如下：
- START_FLAG_REDELIVERY
  這個值代表了onStartCommand方法的返回值爲
  START_REDELIVER_INTENT，而且在上一次服務被殺死前會去調用stopSelf方法停止服務。其中START_REDELIVER_INTENT意味着當Service因內存不足而被系統kill後，則會重建服務，並通過傳遞給服務的最後一個 Intent 調用 onStartCommand()，此時Intent時有值的。
- START_FLAG_RETRY
  該flag代表當onStartCommand調用後一直沒有返回值時，會嘗試重新去調用onStartCommand()。
startId ：指明當前服務的唯一ID，與stopSelfResult (int startId)配合使用，stopSelfResult 可以更安全地根據ID停止服務。

實際上onStartCommand的返回值int類型纔是最最值得注意的，它有三種可選值， START_STICKY，START_NOT_STICKY，START_REDELIVER_INTENT，它們具體含義如下：

START_STICKY
當Service因內存不足而被系統kill後，一段時間後內存再次空閒時，系統將會嘗試重新創建此Service，一旦創建成功後將回調onStartCommand方法，但其中的Intent將是null，除非有掛起的Intent，如pendingintent，這個狀態下比較適用於不執行命令、但無限期運行並等待作業的媒體播放器或類似服務。
START_NOT_STICKY
當Service因內存不足而被系統kill後，即使系統內存再次空閒時，系統也不會嘗試重新創建此Service。除非程序中再次調用startService啓動此Service，這是最安全的選項，可以避免在不必要時以及應用能夠輕鬆重啓所有未完成的作業時運行服務。
START_REDELIVER_INTENT
當Service因內存不足而被系統kill後，則會重建服務，並通過傳遞給服務的最後一個 Intent 調用 onStartCommand()，任何掛起 Intent均依次傳遞。與START_STICKY不同的是，其中的傳遞的Intent將是非空，是最後一次調用startService中的intent。這個值適用於主動執行應該立即恢復的作業（例如下載文件）的服務。

由於每次啓動服務（調用startService）時，onStartCommand方法都會被調用，因此我們可以通過該方法使用Intent給Service傳遞所需要的參數，然後在onStartCommand方法中處理的事件，最後根據需求選擇不同的Flag返回值，以達到對程序更友好的控制。好~，以上便是Service在啓動狀態下的分析，接着我們在來看看綁定狀態的Service又是如何處理的？

4.Service綁定服務

綁定服務是Service的另一種變形，當Service處於綁定狀態時，其代表着客戶端-服務器接口中的服務器。當其他組件（如 Activity）綁定到服務時（有時我們可能需要從Activity組建中去調用Service中的方法，此時Activity以綁定的方式掛靠到Service後，我們就可以輕鬆地方法到Service中的指定方法），組件（如Activity）可以向Service（也就是服務端）發送請求，或者調用Service（服務端）的方法，此時被綁定的Service（服務端）會接收信息並響應，甚至可以通過綁定服務進行執行進程間通信 (即IPC，這個後面再單獨分析)。與啓動服務不同的是綁定服務的生命週期通常只在爲其他應用組件(如Activity)服務時處於活動狀態，不會無限期在後臺運行，也就是說宿主(如Activity)解除綁定後，綁定服務就會被銷燬。那麼在提供綁定的服務時，該如何實現呢？實際上我們必須提供一個 IBinder接口的實現類，該類用以提供客戶端用來與服務進行交互的編程接口，該接口可以通過三種方法定義接口：

擴展 Binder 類
如果服務是提供給自有應用專用的，並且Service(服務端)與客戶端相同的進程中運行（常見情況），則應通過擴展 Binder 類並從 onBind() 返回它的一個實例來創建接口。客戶端收到 Binder 後，可利用它直接訪問 Binder 實現中以及Service 中可用的公共方法。如果我們的服務只是自有應用的後臺工作線程，則優先採用這種方法。不採用該方式創建接口的唯一原因是，服務被其他應用或不同的進程調用。
使用 Messenger
Messenger可以翻譯爲信使，通過它可以在不同的進程中共傳遞Message對象(Handler中的Messager，因此 Handler 是 Messenger 的基礎)，在Message中可以存放我們需要傳遞的數據，然後在進程間傳遞。如果需要讓接口跨不同的進程工作，則可使用 Messenger 爲服務創建接口，客戶端就可利用 Message 對象向服務發送命令。同時客戶端也可定義自有 Messenger，以便服務回傳消息。這是執行進程間通信 (IPC) 的最簡單方法，因爲 Messenger 會在單一線程中創建包含所有請求的隊列，也就是說Messenger是以串行的方式處理客戶端發來的消息，這樣我們就不必對服務進行線程安全設計了。
使用 AIDL
由於Messenger是以串行的方式處理客戶端發來的消息，如果當前有大量消息同時發送到Service(服務端)，Service仍然只能一個個處理，這也就是Messenger跨進程通信的缺點了，因此如果有大量併發請求，Messenger就會顯得力不從心了，這時AIDL（Android 接口定義語言）就派上用場了，但實際上Messenger 的跨進程方式其底層實現就是AIDL，只不過android系統幫我們封裝成透明的Messenger罷了。因此，如果我們想讓服務同時處理多個請求，則應該使用 AIDL。在此情況下，服務必須具備多線程處理能力，並採用線程安全式設計。使用AIDL必須創建一個定義編程接口的 .aidl 文件。Android SDK 工具利用該文件生成一個實現接口並處理 IPC 的抽象類，隨後可在服務內對其進行擴展。

以上3種實現方式，我們可以根據需求自由的選擇，但需要注意的是大多數應用“都不會”使用 AIDL 來創建綁定服務，因爲它可能要求具備多線程處理能力，並可能導致實現的複雜性增加。因此，AIDL 並不適合大多數應用，本篇中也不打算闡述如何使用AIDL（後面會另開一篇分析AIDL），接下來我們分別針對擴展 Binder 類和Messenger的使用進行分析。

4.1 擴展 Binder 類

前面描述過，如果我們的服務僅供本地應用使用，不需要跨進程工作，則可以實現自有 Binder 類，讓客戶端通過該類直接訪問服務中的公共方法。其使用開發步驟如下

1.創建BindService服務端，繼承自Service並在類中，創建一個實現IBinder 接口的實例對象並提供公共方法給客戶端調用
2.從 onBind() 回調方法返回此 Binder 實例。
3.在客戶端中，從 onServiceConnected() 回調方法接收 Binder，並使用提供的方法調用綁定服務。

注意：此方式只有在客戶端和服務位於同一應用和進程內纔有效，如對於需要將 Activity 綁定到在後臺播放音樂的自有服務的音樂應用，此方式非常有效。另一點之所以要求服務和客戶端必須在同一應用內，是爲了便於客戶端轉換返回的對象和正確調用其 API。服務和客戶端還必須在同一進程內，因爲此方式不執行任何跨進程編組。
以下是一個擴展 Binder 類的實例，先看看Service端的實現BindService.java

package com.zejian.ipctest.service;

import android.app.Service;
import android.content.Intent;
import android.os.Binder;
import android.os.IBinder;
import android.support.annotation.Nullable;
import android.util.Log;

/**
 * Created by zejian
 * Time 2016/10/2.
 * Description:綁定服務簡單實例--服務端
 */
public class LocalService extends Service{
    private final static String TAG = "wzj";
    private int count;
    private boolean quit;
    private Thread thread;
    private LocalBinder binder = new LocalBinder();

    /**
     * 創建Binder對象，返回給客戶端即Activity使用，提供數據交換的接口
     */
    public class LocalBinder extends Binder {
        // 聲明一個方法，getService。（提供給客戶端調用）
        LocalService getService() {
            // 返回當前對象LocalService,這樣我們就可在客戶端端調用Service的公共方法了
            return LocalService.this;
        }
    }

    /**
     * 把Binder類返回給客戶端
     */
    @Nullable
    @Override
    public IBinder onBind(Intent intent) {
        return binder;
    }


    @Override
    public void onCreate() {
        super.onCreate();
        Log.i(TAG, "Service is invoke Created");
        thread = new Thread(new Runnable() {
            @Override
            public void run() {
                // 每間隔一秒count加1 ，直到quit爲true。
                while (!quit) {
                    try {
                        Thread.sleep(1000);
                    } catch (InterruptedException e) {
                        e.printStackTrace();
                    }
                    count++;
                }
            }
        });
        thread.start();
    }

    /**
     * 公共方法
     * @return
     */
    public int getCount(){
        return count;
    }
    /**
     * 解除綁定時調用
     * @return
     */
     @Override
    public boolean onUnbind(Intent intent) {
        Log.i(TAG, "Service is invoke onUnbind");
        return super.onUnbind(intent);
    }

    @Override
    public void onDestroy() {
        Log.i(TAG, "Service is invoke Destroyed");
        this.quit = true;
        super.onDestroy();
    }
}

BindService類繼承自Service，在該類中創建了一個LocalBinder繼承自Binder類，LocalBinder中聲明瞭一個getService方法，客戶端可訪問該方法獲取LocalService對象的實例，只要客戶端獲取到LocalService對象的實例就可調用LocalService服務端的公共方法，如getCount方法，值得注意的是，我們在onBind方法中返回了binder對象，該對象便是LocalBinder的具體實例，而binder對象最終會返回給客戶端，客戶端通過返回的binder對象便可以與服務端實現交互。接着看看客戶端BindActivity的實現：

package com.zejian.ipctest.service;

import android.app.Activity;
import android.app.Service;
import android.content.ComponentName;
import android.content.Intent;
import android.content.ServiceConnection;
import android.os.Bundle;
import android.os.IBinder;
import android.util.Log;
import android.view.View;
import android.widget.Button;

import com.zejian.ipctest.R;

/**
 * Created by zejian
 * Time 2016/10/2.
 * Description:綁定服務實例--客戶端
 */
public class BindActivity extends Activity {
    protected static final String TAG = "wzj";
    Button btnBind;
    Button btnUnBind;
    Button btnGetDatas;
    /**
     * ServiceConnection代表與服務的連接，它只有兩個方法，
     * onServiceConnected和onServiceDisconnected，
     * 前者是在操作者在連接一個服務成功時被調用，而後者是在服務崩潰或被殺死導致的連接中斷時被調用
     */
    private ServiceConnection conn;
    private LocalService mService;
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_bind);
        btnBind = (Button) findViewById(R.id.BindService);
        btnUnBind = (Button) findViewById(R.id.unBindService);
        btnGetDatas = (Button) findViewById(R.id.getServiceDatas);
        //創建綁定對象
        final Intent intent = new Intent(this, LocalService.class);

        // 開啓綁定
        btnBind.setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {
                Log.d(TAG, "綁定調用：bindService");
                //調用綁定方法
                bindService(intent, conn, Service.BIND_AUTO_CREATE);
            }
        });
        // 解除綁定
        btnUnBind.setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {
                Log.d(TAG, "解除綁定調用：unbindService");
                // 解除綁定
                if(mService!=null) {
                    mService = null;
                    unbindService(conn);
                }
            }
        });

        // 獲取數據
        btnGetDatas.setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {
                if (mService != null) {
                    // 通過綁定服務傳遞的Binder對象，獲取Service暴露出來的數據

                    Log.d(TAG, "從服務端獲取數據：" + mService.getCount());
                } else {

                    Log.d(TAG, "還沒綁定呢，先綁定,無法從服務端獲取數據");
                }
            }
        });


        conn = new ServiceConnection() {
            /**
             * 與服務器端交互的接口方法 綁定服務的時候被回調，在這個方法獲取綁定Service傳遞過來的IBinder對象，
             * 通過這個IBinder對象，實現宿主和Service的交互。
             */
            @Override
            public void onServiceConnected(ComponentName name, IBinder service) {
                Log.d(TAG, "綁定成功調用：onServiceConnected");
                // 獲取Binder
                LocalService.LocalBinder binder = (LocalService.LocalBinder) service;
                mService = binder.getService();
            }
            /**
             * 當取消綁定的時候被回調。但正常情況下是不被調用的，它的調用時機是當Service服務被意外銷燬時，
             * 例如內存的資源不足時這個方法才被自動調用。
             */
            @Override
            public void onServiceDisconnected(ComponentName name) {
                mService=null;
            }
        };
    }
}

在客戶端中我們創建了一個ServiceConnection對象，該代表與服務的連接，它只有兩個方法， onServiceConnected和onServiceDisconnected，其含義如下：

onServiceConnected(ComponentName name, IBinder service)
系統會調用該方法以傳遞服務的　onBind() 方法返回的 IBinder。其中service便是服務端返回的IBinder實現類對象，通過該對象我們便可以調用獲取LocalService實例對象，進而調用服務端的公共方法。而ComponentName是一個封裝了組件(Activity, Service, BroadcastReceiver, or ContentProvider)信息的類，如包名，組件描述等信息，較少使用該參數。
onServiceDisconnected(ComponentName name)
Android 系統會在與服務的連接意外中斷時（例如當服務崩潰或被終止時）調用該方法。注意:當客戶端取消綁定時，系統“絕對不會”調用該方法。

conn = new ServiceConnection() {

            @Override
            public void onServiceConnected(ComponentName name, IBinder service) {
                Log.d(TAG, "綁定成功調用：onServiceConnected");
                // 獲取Binder
                LocalService.LocalBinder binder = (LocalService.LocalBinder) service;
                mService = binder.getService();
            }

            @Override
            public void onServiceDisconnected(ComponentName name) {
                mService=null;
            }
        };

在onServiceConnected()被回調前，我們還需先把當前Activity綁定到服務LocalService上，綁定服務是通過通過bindService()方法，解綁服務則使用unbindService()方法，這兩個方法解析如下：

bindService(Intent service, ServiceConnection conn, int flags)
該方法執行綁定服務操作，其中Intent是我們要綁定的服務(也就是LocalService)的意圖，而ServiceConnection代表與服務的連接，它只有兩個方法，前面已分析過，flags則是指定綁定時是否自動創建Service。0代表不自動創建、BIND_AUTO_CREATE則代表自動創建。
unbindService(ServiceConnection conn)
該方法執行解除綁定的操作，其中ServiceConnection代表與服務的連接，它只有兩個方法，前面已分析過。

Activity通過bindService()綁定到LocalService後，ServiceConnection#onServiceConnected()便會被回調並可以獲取到LocalService實例對象mService，之後我們就可以調用LocalService服務端的公共方法了，最後還需要在清單文件中聲明該Service。而客戶端佈局文件實現如下：

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:orientation="vertical" android:layout_width="match_parent"
    android:layout_height="match_parent">

    <Button
        android:id="@+id/BindService"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:text="綁定服務器"
        />

    <Button
        android:id="@+id/unBindService"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:text="解除綁定"
        />

    <Button
        android:id="@+id/getServiceDatas"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:text="獲取服務方數據"
        />
</LinearLayout>

我們運行程序，點擊綁定服務並多次點擊綁定服務接着多次調用LocalService中的getCount()獲取數據，最後調用解除綁定的方法移除服務，其結果如下：

通過Log可知，當我們第一次點擊綁定服務時，LocalService服務端的onCreate()、onBind方法會依次被調用，此時客戶端的ServiceConnection#onServiceConnected()被調用並返回LocalBinder對象，接着調用LocalBinder#getService方法返回LocalService實例對象，此時客戶端便持有了LocalService的實例對象，也就可以任意調用LocalService類中的聲明公共方法了。更值得注意的是，我們多次調用bindService方法綁定LocalService服務端，而LocalService得onBind方法只調用了一次，那就是在第一次調用bindService時纔會回調onBind方法。接着我們點擊獲取服務端的數據，從Log中看出我們點擊了3次通過getCount()獲取了服務端的3個不同數據，最後點擊解除綁定，此時LocalService的onUnBind、onDestroy方法依次被回調，並且多次綁定只需一次解綁即可。此情景也就說明了綁定狀態下的Service生命週期方法的調用依次爲onCreate()、onBind、onUnBind、onDestroy。ok~，以上便是同一應用同一進程中客戶端與服務端的綁定回調方式。

4.2 使用Messenger

前面瞭解瞭如何使用IBinder應用內同一進程的通信後，我們接着來了解服務與遠程進程（即不同進程間）通信，而不同進程間的通信，最簡單的方式就是使用 Messenger 服務提供通信接口，利用此方式，我們無需使用 AIDL 便可執行進程間通信 (IPC)。以下是 Messenger 使用的主要步驟：

1.服務實現一個 Handler，由其接收來自客戶端的每個調用的回調
2.Handler 用於創建 Messenger 對象（對 Handler 的引用）
3.Messenger 創建一個 IBinder，服務通過 onBind() 使其返回客戶端
4.客戶端使用 IBinder 將 Messenger（引用服務的 Handler）實例化，然後使用Messenger將 Message 對象發送給服務
5.服務在其 Handler 中（在 handleMessage() 方法中）接收每個 Message

以下是一個使用 Messenger 接口的簡單服務示例，服務端進程實現如下：

package com.zejian.ipctest.messenger;

import android.app.Service;
import android.content.Intent;
import android.os.Handler;
import android.os.IBinder;
import android.os.Message;
import android.os.Messenger;
import android.util.Log;

/**
 * Created by zejian
 * Time 2016/10/3.
 * Description:Messenger服務端簡單實例,服務端進程
 */
public class MessengerService extends Service {

    /** Command to the service to display a message */
    static final int MSG_SAY_HELLO = 1;
    private static final String TAG ="wzj" ;

    /**
     * 用於接收從客戶端傳遞過來的數據
     */
    class IncomingHandler extends Handler {
        @Override
        public void handleMessage(Message msg) {
            switch (msg.what) {
                case MSG_SAY_HELLO:
                    Log.i(TAG, "thanks,Service had receiver message from client!");
                    break;
                default:
                    super.handleMessage(msg);
            }
        }
    }

    /**
     * 創建Messenger並傳入Handler實例對象
     */
    final Messenger mMessenger = new Messenger(new IncomingHandler());

    /**
     * 當綁定Service時,該方法被調用,將通過mMessenger返回一個實現
     * IBinder接口的實例對象
     */
    @Override
    public IBinder onBind(Intent intent) {
        Log.i(TAG, "Service is invoke onBind");
        return mMessenger.getBinder();
    }
}

首先我們同樣需要創建一個服務類MessengerService繼承自Service，同時創建一個繼承自Handler的IncomingHandler對象來接收客戶端進程發送過來的消息並通過其handleMessage(Message msg)進行消息處理。接着通過IncomingHandler對象創建一個Messenger對象，該對象是與客戶端交互的特殊對象，然後在Service的onBind中返回這個Messenger對象的底層Binder即可。下面看看客戶端進程的實現：

package com.zejian.ipctest.messenger;

import android.app.Activity;
import android.content.ComponentName;
import android.content.Context;
import android.content.Intent;
import android.content.ServiceConnection;
import android.os.Bundle;
import android.os.IBinder;
import android.os.Message;
import android.os.Messenger;
import android.os.RemoteException;
import android.util.Log;
import android.view.View;
import android.widget.Button;

import com.zejian.ipctest.R;

/**
 * Created by zejian
 * Time 2016/10/3.
 * Description: 與服務器交互的客戶端
 */
public class ActivityMessenger extends Activity {
    /**
     * 與服務端交互的Messenger
     */
    Messenger mService = null;

    /** Flag indicating whether we have called bind on the service. */
    boolean mBound;

    /**
     * 實現與服務端鏈接的對象
     */
    private ServiceConnection mConnection = new ServiceConnection() {
        public void onServiceConnected(ComponentName className, IBinder service) {
            /**
             * 通過服務端傳遞的IBinder對象,創建相應的Messenger
             * 通過該Messenger對象與服務端進行交互
             */
            mService = new Messenger(service);
            mBound = true;
        }

        public void onServiceDisconnected(ComponentName className) {
            // This is called when the connection with the service has been
            // unexpectedly disconnected -- that is, its process crashed.
            mService = null;
            mBound = false;
        }
    };

    public void sayHello(View v) {
        if (!mBound) return;
        // 創建與服務交互的消息實體Message
        Message msg = Message.obtain(null, MessengerService.MSG_SAY_HELLO, 0, 0);
        try {
            //發送消息
            mService.send(msg);
        } catch (RemoteException e) {
            e.printStackTrace();
        }
    }

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_messenager);
        Button bindService= (Button) findViewById(R.id.bindService);
        Button unbindService= (Button) findViewById(R.id.unbindService);
        Button sendMsg= (Button) findViewById(R.id.sendMsgToService);

        bindService.setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {
                Log.d("zj","onClick-->bindService");
                //當前Activity綁定服務端
                bindService(new Intent(ActivityMessenger.this, MessengerService.class), mConnection,
                        Context.BIND_AUTO_CREATE);
            }
        });

        //發送消息給服務端
        sendMsg.setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {
                sayHello(v);
            }
        });


        unbindService.setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {
                // Unbind from the service
                if (mBound) {
                    Log.d("zj","onClick-->unbindService");
                    unbindService(mConnection);
                    mBound = false;
                }
            }
        });
    }

}

在客戶端進程中，我們需要創建一個ServiceConnection對象，該對象代表與服務端的鏈接，當調用bindService方法將當前Activity綁定到MessengerService時，onServiceConnected方法被調用，利用服務端傳遞給來的底層Binder對象構造出與服務端交互的Messenger對象，接着創建與服務交互的消息實體Message，將要發生的信息封裝在Message中並通過Messenger實例對象發送給服務端。關於ServiceConnection、bindService方法、unbindService方法，前面已分析過，這裏就不重複了，最後我們需要在清單文件聲明Service和Activity，由於要測試不同進程的交互，則需要將Service放在單獨的進程中，因此Service聲明如下：

<service android:name=".messenger.MessengerService"
         android:process=":remote"
        />

其中android:process=":remote"代表該Service在單獨的進程中創建，最後我們運行程序，結果如下：

接着多次點擊綁定服務，然後發送信息給服務端，最後解除綁定，Log打印如下：

通過上述例子可知Service服務端確實收到了客戶端發送的信息，而且在Messenger中進行數據傳遞必須將數據封裝到Message中，因爲Message和Messenger都實現了Parcelable接口，可以輕鬆跨進程傳遞數據（關於Parcelable接口可以看博主的另一篇文章：序列化與反序列化之Parcelable和Serializable淺析），而Message可以傳遞的信息載體有，what,arg1,arg2,Bundle以及replyTo，至於object字段，對於同一進程中的數據傳遞確實很實用，但對於進程間的通信，則顯得相當尷尬，在android2.2前，object不支持跨進程傳輸，但即便是android2.2之後也只能傳遞android系統提供的實現了Parcelable接口的對象，也就是說我們通過自定義實現Parcelable接口的對象無法通過object字段來傳遞，因此object字段的實用性在跨進程中也變得相當低了。不過所幸我們還有Bundle對象，Bundle可以支持大量的數據類型。接着從Log我們也看出無論是使用拓展Binder類的實現方式還是使用Messenger的實現方式，它們的生命週期方法的調用順序基本是一樣的，即onCreate()、onBind、onUnBind、onDestroy，而且多次綁定中也只有第一次時才調用onBind()。好~，以上的例子演示瞭如何在服務端解釋客戶端發送的消息，但有時候我們可能還需要服務端能迴應客戶端，這時便需要提供雙向消息傳遞了，下面就來實現一個簡單服務端與客戶端雙向消息傳遞的簡單例子。
先來看看服務端的修改，在服務端，我們只需修改IncomingHandler，收到消息後，給客戶端回覆一條信息。

  /**
     * 用於接收從客戶端傳遞過來的數據
     */
    class IncomingHandler extends Handler {
        @Override
        public void handleMessage(Message msg) {
            switch (msg.what) {
                case MSG_SAY_HELLO:
                    Log.i(TAG, "thanks,Service had receiver message from client!");
                    //回覆客戶端信息,該對象由客戶端傳遞過來
                    Messenger client=msg.replyTo;
                    //獲取回覆信息的消息實體
                    Message replyMsg=Message.obtain(null,MessengerService.MSG_SAY_HELLO);
                    Bundle bundle=new Bundle();
                    bundle.putString("reply","ok~,I had receiver message from you! ");
                    replyMsg.setData(bundle);
                    //向客戶端發送消息
                    try {
                        client.send(replyMsg);
                    } catch (RemoteException e) {
                        e.printStackTrace();
                    }

                    break;
                default:
                    super.handleMessage(msg);
            }
        }
    }

接着修改客戶端，爲了接收服務端的回覆，客戶端也需要一個接收消息的Messenger和Handler，其實現如下：

  /**
     * 用於接收服務器返回的信息
     */
    private Messenger mRecevierReplyMsg= new Messenger(new ReceiverReplyMsgHandler());


    private static class ReceiverReplyMsgHandler extends Handler{
        private static final String TAG = "zj";

        @Override
        public void handleMessage(Message msg) {
            switch (msg.what) {
                //接收服務端回覆
                case MessengerService.MSG_SAY_HELLO:
                    Log.i(TAG, "receiver message from service:"+msg.getData().getString("reply"));
                    break;
                default:
                    super.handleMessage(msg);
            }
        }
    }

除了添加以上代碼，還需要在發送信息時把接收服務器端的回覆的Messenger通過Message的replyTo參數傳遞給服務端，以便作爲同學橋樑，代碼如下：

 public void sayHello(View v) {
        if (!mBound) return;
        // 創建與服務交互的消息實體Message
        Message msg = Message.obtain(null, MessengerService.MSG_SAY_HELLO, 0, 0);
        //把接收服務器端的回覆的Messenger通過Message的replyTo參數傳遞給服務端
        msg.replyTo=mRecevierReplyMsg;
        try {
            //發送消息
            mService.send(msg);
        } catch (RemoteException e) {
            e.printStackTrace();
        }
    }

ok~，到此服務端與客戶端雙向消息傳遞的簡單例子修改完成，我們運行一下代碼，看看Log打印，如下：

由Log可知，服務端和客戶端確實各自收到了信息，到此我們就把採用Messenge進行跨進程通信的方式分析完了，最後爲了輔助大家理解，這裏提供一張通過Messenge方式進行進程間通信的原理圖：

4.3 關於綁定服務的注意點

1.多個客戶端可同時連接到一個服務。不過，只有在第一個客戶端綁定時，系統纔會調用服務的 onBind() 方法來檢索 IBinder。系統隨後無需再次調用 onBind()，便可將同一 IBinder 傳遞至任何其他綁定的客戶端。當最後一個客戶端取消與服務的綁定時，系統會將服務銷燬（除非 startService() 也啓動了該服務）。

2.通常情況下我們應該在客戶端生命週期（如Activity的生命週期）的引入 (bring-up) 和退出 (tear-down) 時刻設置綁定和取消綁定操作，以便控制綁定狀態下的Service，一般有以下兩種情況：

如果只需要在 Activity 可見時與服務交互，則應在 onStart() 期間綁定，在 onStop() 期間取消綁定。
如果希望 Activity 在後臺停止運行狀態下仍可接收響應，則可在 onCreate() 期間綁定，在 onDestroy() 期間取消綁定。需要注意的是，這意味着 Activity 在其整個運行過程中（甚至包括後臺運行期間）都需要使用服務，因此如果服務位於其他進程內，那麼當提高該進程的權重時，系統很可能會終止該進程。

3.通常情況下(注意)，切勿在 Activity 的 onResume() 和 onPause() 期間綁定和取消綁定，因爲每一次生命週期轉換都會發生這些回調，這樣反覆綁定與解綁是不合理的。此外，如果應用內的多個 Activity 綁定到同一服務，並且其中兩個 Activity 之間發生了轉換，則如果當前 Activity 在下一次綁定（恢復期間）之前取消綁定（暫停期間），系統可能會銷燬服務並重建服務，因此服務的綁定不應該發生在 Activity 的 onResume() 和 onPause()中。

4.我們應該始終捕獲 DeadObjectException DeadObjectException 異常，該異常是在連接中斷時引發的，表示調用的對象已死亡，也就是Service對象已銷燬，這是遠程方法引發的唯一異常，DeadObjectException繼承自RemoteException，因此我們也可以捕獲RemoteException異常。

5.應用組件（客戶端）可通過調用 bindService() 綁定到服務,Android 系統隨後調用服務的 onBind() 方法，該方法返回用於與服務交互的 IBinder，而該綁定是異步執行的。

5.關於啓動服務與綁定服務間的轉換問題

通過前面對兩種服務狀態的分析，相信大家已對Service的兩種狀態有了比較清晰的瞭解，那麼現在我們就來分析一下當啓動狀態和綁定狀態同時存在時，又會是怎麼的場景？
雖然服務的狀態有啓動和綁定兩種，但實際上一個服務可以同時是這兩種狀態，也就是說，它既可以是啓動服務（以無限期運行），也可以是綁定服務。有點需要注意的是Android系統僅會爲一個Service創建一個實例對象，所以不管是啓動服務還是綁定服務，操作的是同一個Service實例，而且由於綁定服務或者啓動服務執行順序問題將會出現以下兩種情況：

先綁定服務後啓動服務

如果當前Service實例先以綁定狀態運行，然後再以啓動狀態運行，那麼綁定服務將會轉爲啓動服務運行，這時如果之前綁定的宿主（Activity）被銷燬了，也不會影響服務的運行，服務還是會一直運行下去，指定收到調用停止服務或者內存不足時纔會銷燬該服務。
先啓動服務後綁定服務

如果當前Service實例先以啓動狀態運行，然後再以綁定狀態運行，當前啓動服務並不會轉爲綁定服務，但是還是會與宿主綁定，只是即使宿主解除綁定後，服務依然按啓動服務的生命週期在後臺運行，直到有Context調用了stopService()或是服務本身調用了stopSelf()方法抑或內存不足時纔會銷燬服務。

以上兩種情況顯示出啓動服務的優先級確實比綁定服務高一些。不過無論Service是處於啓動狀態還是綁定狀態，或處於啓動並且綁定狀態，我們都可以像使用Activity那樣通過調用 Intent 來使用服務(即使此服務來自另一應用)。當然，我們也可以通過清單文件將服務聲明爲私有服務，阻止其他應用訪問。最後這裏有點需要特殊說明一下的，由於服務在其託管進程的主線程中運行（UI線程），它既不創建自己的線程，也不在單獨的進程中運行（除非另行指定）。這意味着，如果服務將執行任何耗時事件或阻止性操作（例如 MP3 播放或聯網）時，則應在服務內創建新線程來完成這項工作，簡而言之，耗時操作應該另起線程執行。只有通過使用單獨的線程，纔可以降低發生“應用無響應”(ANR) 錯誤的風險，這樣應用的主線程才能專注於用戶與 Activity 之間的交互，以達到更好的用戶體驗。

6.前臺服務以及通知發送

前臺服務被認爲是用戶主動意識到的一種服務，因此在內存不足時，系統也不會考慮將其終止。前臺服務必須爲狀態欄提供通知，狀態欄位於“正在進行”標題下方，這意味着除非服務停止或從前臺刪除，否則不能清除通知。例如將從服務播放音樂的音樂播放器設置爲在前臺運行，這是因爲用戶明確意識到其操作。狀態欄中的通知可能表示正在播放的歌曲，並允許用戶啓動 Activity 來與音樂播放器進行交互。如果需要設置服務運行於前臺，我們該如何才能實現呢？Android官方給我們提供了兩個方法，分別是startForeground()和stopForeground()，這兩個方式解析如下：

startForeground(int id, Notification notification)
該方法的作用是把當前服務設置爲前臺服務，其中id參數代表唯一標識通知的整型數，需要注意的是提供給 startForeground() 的整型 ID 不得爲 0，而notification是一個狀態欄的通知。
stopForeground(boolean removeNotification)
該方法是用來從前臺刪除服務，此方法傳入一個布爾值，指示是否也刪除狀態欄通知，true爲刪除。注意該方法並不會停止服務。但是，如果在服務正在前臺運行時將其停止，則通知也會被刪除。

下面我們結合一個簡單案例來使用以上兩個方法，ForegroundService代碼如下：

package com.zejian.ipctest.foregroundService;

import android.app.Notification;
import android.app.Service;
import android.content.Intent;
import android.graphics.BitmapFactory;
import android.os.IBinder;
import android.support.annotation.Nullable;
import android.support.v4.app.NotificationCompat;

import com.zejian.ipctest.R;

/**
 * Created by zejian
 * Time 2016/10/4.
 * Description:啓動前臺服務Demo
 */
public class ForegroundService extends Service {

    /**
     * id不可設置爲0,否則不能設置爲前臺service
     */
    private static final int NOTIFICATION_DOWNLOAD_PROGRESS_ID = 0x0001;

    private boolean isRemove=false;//是否需要移除

    /**
     * Notification
     */
    public void createNotification(){
        //使用兼容版本
        NotificationCompat.Builder builder=new NotificationCompat.Builder(this);
        //設置狀態欄的通知圖標
        builder.setSmallIcon(R.mipmap.ic_launcher);
        //設置通知欄橫條的圖標
        builder.setLargeIcon(BitmapFactory.decodeResource(getResources(),R.drawable.screenflash_logo));
        //禁止用戶點擊刪除按鈕刪除
        builder.setAutoCancel(false);
        //禁止滑動刪除
        builder.setOngoing(true);
        //右上角的時間顯示
        builder.setShowWhen(true);
        //設置通知欄的標題內容
        builder.setContentTitle("I am Foreground Service!!!");
        //創建通知
        Notification notification = builder.build();
        //設置爲前臺服務
        startForeground(NOTIFICATION_DOWNLOAD_PROGRESS_ID,notification);
    }


    @Override
    public int onStartCommand(Intent intent, int flags, int startId) {
        int i=intent.getExtras().getInt("cmd");
        if(i==0){
            if(!isRemove) {
                createNotification();
            }
            isRemove=true;
        }else {
            //移除前臺服務
            if (isRemove) {
                stopForeground(true);
            }
            isRemove=false;
        }

        return super.onStartCommand(intent, flags, startId);
    }

    @Override
    public void onDestroy() {
        //移除前臺服務
        if (isRemove) {
            stopForeground(true);
        }
        isRemove=false;
        super.onDestroy();
    }

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

在ForegroundService類中，創建了一個notification的通知，並通過啓動Service時傳遞過來的參數判斷是啓動前臺服務還是關閉前臺服務，最後在onDestroy方法被調用時，也應該移除前臺服務。以下是ForegroundActivity的實現：

package com.zejian.ipctest.foregroundService;

import android.app.Activity;
import android.content.Intent;
import android.os.Bundle;
import android.view.View;
import android.widget.Button;

import com.zejian.ipctest.R;

/**
 * Created by zejian
 * Time 2016/10/4.
 * Description:
 */
public class ForegroundActivity extends Activity {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_foreground);
        Button btnStart= (Button) findViewById(R.id.startForeground);
        Button btnStop= (Button) findViewById(R.id.stopForeground);
        final Intent intent = new Intent(this,ForegroundService.class);


        btnStart.setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {
                intent.putExtra("cmd",0);//0,開啓前臺服務,1,關閉前臺服務
                startService(intent);
            }
        });


        btnStop.setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {
                intent.putExtra("cmd",1);//0,開啓前臺服務,1,關閉前臺服務
                startService(intent);
            }
        });
    }
}

代碼比較簡單，我們直接運行程序看看結果：

ok~，以上便是有關於Service前臺服務的內容，接下來再聊聊服務與線程的區別

7.服務Service與線程Thread的區別

兩者概念的迥異
- Thread 是程序執行的最小單元，它是分配CPU的基本單位，android系統中UI線程也是線程的一種，當然Thread還可以用於執行一些耗時異步的操作。
- Service是Android的一種機制，服務是運行在主線程上的，它是由系統進程託管。它與其他組件之間的通信類似於client和server，是一種輕量級的IPC通信，這種通信的載體是binder，它是在linux層交換信息的一種IPC，而所謂的Service後臺任務只不過是指沒有UI的組件罷了。
兩者的執行任務迥異
- 在android系統中，線程一般指的是工作線程(即後臺線程)，而主線程是一種特殊的工作線程，它負責將事件分派給相應的用戶界面小工具，如繪圖事件及事件響應，因此爲了保證應用 UI 的響應能力主線程上不可執行耗時操作。如果執行的操作不能很快完成，則應確保它們在單獨的工作線程執行。
- Service 則是android系統中的組件，一般情況下它運行於主線程中，因此在Service中是不可以執行耗時操作的，否則系統會報ANR異常，之所以稱Service爲後臺服務，大部分原因是它本身沒有UI，用戶無法感知(當然也可以利用某些手段讓用戶知道)，但如果需要讓Service執行耗時任務，可在Service中開啓單獨線程去執行。
兩者使用場景
- 當要執行耗時的網絡或者數據庫查詢以及其他阻塞UI線程或密集使用CPU的任務時，都應該使用工作線程(Thread)，這樣才能保證UI線程不被佔用而影響用戶體驗。
- 在應用程序中，如果需要長時間的在後臺運行，而且不需要交互的情況下，使用服務。比如播放音樂，通過Service+Notification方式在後臺執行同時在通知欄顯示着。
兩者的最佳使用方式

在大部分情況下，Thread和Service都會結合着使用，比如下載文件，一般會通過Service在後臺執行+Notification在通知欄顯示+Thread異步下載，再如應用程序會維持一個Service來從網絡中獲取推送服務。在Android官方看來也是如此，所以官網提供了一個Thread與Service的結合來方便我們執行後臺耗時任務，它就是IntentService，(如果想更深入瞭解IntentService，可以看博主的另一篇文章：Android 多線程之IntentService 完全詳解)，當然 IntentService並不適用於所有的場景，但它的優點是使用方便、代碼簡潔，不需要我們創建Service實例並同時也創建線程，某些場景下還是非常讚的！由於IntentService是單個worker thread，所以任務需要排隊，因此不適合大多數的多任務情況。
兩者的真正關係
- 兩者沒有半毛錢關係。

8.管理服務生命週期

關於Service生命週期方法的執行順序，前面我們已分析得差不多了，這裏重新給出一張執行的流程圖（出自Android官網）

其中左圖顯示了使用 startService() 所創建的服務的生命週期，右圖顯示了使用 bindService() 所創建的服務的生命週期。通過圖中的生命週期方法，我們可以監控Service的整體執行過程，包括創建，運行，銷燬，關於Service不同狀態下的方法回調在前面的分析中已描述得很清楚，這裏就不重複了，下面給出官網對生命週期的原文描述：

服務的整個生命週期從調用 onCreate() 開始起，到 onDestroy() 返回時結束。與 Activity 類似，服務也在 onCreate() 中完成初始設置，並在 onDestroy() 中釋放所有剩餘資源。例如，音樂播放服務可以在 onCreate() 中創建用於播放音樂的線程，然後在 onDestroy() 中停止該線程。
無論服務是通過 startService() 還是 bindService() 創建，都會爲所有服務調用 onCreate() 和 onDestroy() 方法。
服務的有效生命週期從調用 onStartCommand() 或 onBind() 方法開始。每種方法均有 Intent 對象，該對象分別傳遞到 startService() 或 bindService()。
對於啓動服務，有效生命週期與整個生命週期同時結束（即便是在 onStartCommand() 返回之後，服務仍然處於活動狀態）。對於綁定服務，有效生命週期在 onUnbind() 返回時結束。

從執行流程圖來看，服務的生命週期比 Activity 的生命週期要簡單得多。但是，我們必須密切關注如何創建和銷燬服務，因爲服務可以在用戶沒有意識到的情況下運行於後臺。管理服務的生命週期（從創建到銷燬）有以下兩種情況：

啓動服務
該服務在其他組件調用 startService() 時創建，然後無限期運行，且必須通過調用 stopSelf() 來自行停止運行。此外，其他組件也可以通過調用 stopService() 來停止服務。服務停止後，系統會將其銷燬。
綁定服務
該服務在另一個組件（客戶端）調用 bindService() 時創建。然後，客戶端通過 IBinder 接口與服務進行通信。客戶端可以通過調用 unbindService() 關閉連接。多個客戶端可以綁定到相同服務，而且當所有綁定全部取消後，系統即會銷燬該服務。（服務不必自行停止運行）

雖然可以通過以上兩種情況管理服務的生命週期，但是我們還必須考慮另外一種情況，也就是啓動服務與綁定服務的結合體，也就是說，我們可以綁定到已經使用 startService() 啓動的服務。例如，可以通過使用 Intent（標識要播放的音樂）調用 startService() 來啓動後臺音樂服務。隨後，可能在用戶需要稍加控制播放器或獲取有關當前播放歌曲的信息時，Activity 可以通過調用 bindService() 綁定到服務。在這種情況下，除非所有客戶端均取消綁定，否則 stopService() 或 stopSelf() 不會真正停止服務。因此在這種情況下我們需要特別注意。

9.Android 5.0以上的隱式啓動問題

既然有隱式啓動，那麼就會有顯示啓動，那就先來了解一下什麼是隱式啓動和顯示啓動。

顯示啓動
直接上代碼一目瞭然，不解釋了。

//顯示啓動
Intent intent = new Intent(this,ForegroundService.class);
startService(intent);

隱式啓動
需要設置一個Action，我們可以把Action的名字設置成Service的全路徑名字，在這種情況下android:exported默認爲true。

final Intent serviceIntent=new Intent(); serviceIntent.setAction("com.android.ForegroundService");
startService(serviceIntent);

存在的意義
如果在同一個應用中，兩者都可以用。在不同應用時，只能用隱式啓動。
Android 5.0以上的隱式啓動問題
Android 5.0之後google出於安全的角度禁止了隱式聲明Intent來啓動Service。如果使用隱式啓動Service，會出沒有指明Intent的錯誤，如下：

主要原因我們可以從源碼中找到，這裏看看Android 4.4的ContextImpl源碼中的validateServiceIntent(Intent service),可知如果啓動service的intent的component和package都爲空並且版本大於KITKAT的時候只是報出一個警報,告訴開發者隱式聲明intent去啓動Service是不安全的.

而在android5.0之後呢？我們這裏看的是android6.0的源碼如下（sublime text查android各個版本源碼就是爽呀！！）：

從源碼可以看出如果啓動service的intent的component和package都爲空並且版本大於LOLLIPOP(5.0)的時候,直接拋出異常，該異常與之前隱式啓動所報的異常時一致的。那麼該如何解決呢？

解決方式

設置Action和packageName

final Intent serviceIntent=new Intent(); serviceIntent.setAction("com.android.ForegroundService");
serviceIntent.setPackage(getPackageName());//設置應用的包名
startService(serviceIntent);

將隱式啓動轉換爲顯示啓動

public static Intent getExplicitIntent(Context context, Intent implicitIntent) {
    // Retrieve all services that can match the given intent
     PackageManager pm = context.getPackageManager();
     List<ResolveInfo> resolveInfo = pm.queryIntentServices(implicitIntent, 0);
     // Make sure only one match was found
     if (resolveInfo == null || resolveInfo.size() != 1) {
         return null;
     }
     // Get component info and create ComponentName
     ResolveInfo serviceInfo = resolveInfo.get(0);
     String packageName = serviceInfo.serviceInfo.packageName;
     String className = serviceInfo.serviceInfo.name;
     ComponentName component = new ComponentName(packageName, className);
     // Create a new intent. Use the old one for extras and such reuse
     Intent explicitIntent = new Intent(implicitIntent);
     // Set the component to be explicit
     explicitIntent.setComponent(component);
     return explicitIntent;
    }

調用方式如下：

Intent mIntent=new Intent();//輔助Intent
mIntent.setAction("com.android.ForegroundService");
final Intent serviceIntent=new Intent(getExplicitIntent(this,mIntent));
startService(serviceIntent);

到此問題完美解決。

10.如何保證服務不被殺死

實際上這種做法並不推薦，但是既然談到了，我們這裏就給出一些實現思路吧。主要分以下3種情況

因內存資源不足而殺死Service
這種情況比較容易處理，可將onStartCommand() 方法的返回值設爲 START_STICKY或START_REDELIVER_INTENT ，該值表示服務在內存資源緊張時被殺死後，在內存資源足夠時再恢復。也可將Service設置爲前臺服務，這樣就有比較高的優先級，在內存資源緊張時也不會被殺掉。這兩點的實現，我們在前面已分析過和實現過這裏就不重複。簡單代碼如下：

/**
     * 返回 START_STICKY或START_REDELIVER_INTENT
     * @param intent
     * @param flags
     * @param startId
     * @return
     */
    @Override
    public int onStartCommand(Intent intent, int flags, int startId) {
//        return super.onStartCommand(intent, flags, startId);
        return START_STICKY;
    }

用戶通過 settings -> Apps -> Running -> Stop 方式殺死Service
這種情況是用戶手動干預的，不過幸運的是這個過程會執行Service的生命週期，也就是onDestory方法會被調用，這時便可以在 onDestory() 中發送廣播重新啓動。這樣殺死服務後會立即啓動。這種方案是行得通的，但爲程序更健全，我們可開啓兩個服務，相互監聽，相互啓動。服務A監聽B的廣播來啓動B，服務B監聽A的廣播來啓動A。這裏給出第一種方式的代碼實現如下：

package com.zejian.ipctest.neverKilledService;

import android.app.Service;
import android.content.BroadcastReceiver;
import android.content.Context;
import android.content.Intent;
import android.content.IntentFilter;
import android.os.IBinder;
import android.support.annotation.Nullable;

/**
 * Created by zejian
 * Time 2016/10/4.
 * Description:用戶通過 settings -> Apps -> Running -> Stop 方式殺死Service
 */
public class ServiceKilledByAppStop extends Service{

    private BroadcastReceiver mReceiver;
    private IntentFilter mIF;

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

    @Override
    public void onCreate() {
        super.onCreate();
        mReceiver = new BroadcastReceiver() {
            @Override
            public void onReceive(Context context, Intent intent) {
                Intent a = new Intent(ServiceKilledByAppStop.this, ServiceKilledByAppStop.class);
                startService(a);
            }
        };
        mIF = new IntentFilter();
        //自定義action
        mIF.addAction("com.restart.service");
        //註冊廣播接者
        registerReceiver(mReceiver, mIF);
    }

    @Override
    public void onDestroy() {
        super.onDestroy();

        Intent intent = new Intent();
        intent.setAction("com.restart.service");
        //發送廣播
        sendBroadcast(intent);

        unregisterReceiver(mReceiver);
    }
}

用戶通過 settings -> Apps -> Downloaded -> Force Stop 方式強制性殺死Service
這種方式就比較悲劇了，因爲是直接kill運行程序的，不會走生命週期的過程,前面兩種情況只要是執行Force Stop ，也就廢了。也就是說這種情況下無法讓服務重啓，或者只能去設置Force Stop 無法操作了，不過也就沒必要了，太流氓了。。。。

ok~，以上便是保證服務在一定場景下不被殺死的解決思路，關於第3種情況，如果有解決方案，請留言哈。好，關於Service的全部介紹就此完結。

主要參考資料：
https://developer.android.com/guide/components/services.html#Notifications
https://developer.android.com/guide/components/processes-and-threads.html
https://developer.android.com/guide/components/bound-services.html#Lifecycle
http://blog.csdn.net/vrix/article/details/45289207
android 開發藝術探索

zejian_ 博客專家

發佈了65 篇原創文章 · 獲贊 3504 · 訪問量 230萬+

他的留言板關注

關於Android Service真正的完全詳解，你需要知道的一切

1.Service簡單概述

2.Service在清單文件中的聲明

3.Service啓動服務

4.Service綁定服務

4.1 擴展 Binder 類

4.2 使用Messenger

4.3 關於綁定服務的注意點

5.關於啓動服務與綁定服務間的轉換問題

6.前臺服務以及通知發送

7.服務Service與線程Thread的區別

8.管理服務生命週期

9.Android 5.0以上的隱式啓動問題

10.如何保證服務不被殺死

ziw2pdf

apisix~helm方式的部署到k8s

firmeye - IoT固件漏洞挖掘工具

走進絢爛多彩的屬性動畫-Property Animation（上篇）

走進絢爛多彩的屬性動畫-Property Animation之TimeInterpolator和TypeEvaluator（下篇）

java數據結構與算法之改良順序表與雙鏈表類似ArrayList和LinkedList（帶Iterator迭代器與fast-fail機制）...

Android佈局動畫之animateLayoutChanges與LayoutTransition

關於Android Service真正的完全詳解，你需要知道的一切

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結