1、什么是service
一個可以在后臺執行長時間操作而不需要用戶界面的應用組件。
需要注意的是：
- 服務并不是運行在一個獨立的進程中，而是依賴于創建服務時所在的應用程序進程。也就是運行在主線程中。
- 服務并不會自動開啟線程，所有的代碼都默認運行在主線程中。也就是說我們需要在服務的內部手動創建子線程，并在這里執行具體的任務，否則就可能出現主線程被阻塞的情況。
2、如何創建service
- 定義一個類繼承Sevice，或者其子類IntentService（區別在后面講到），重寫里面一寫關鍵的回調方法。
- 并在清單文件中申明，并根據需要配置一些其他屬性。
~~~
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" >
~~~
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的名字。如果不設置，將會默認使用的label屬性。
android:name : 這個service的路徑名，例如“com.lypeer.demo.MyService”。這個屬性是唯一一個必須填的屬性。
android:permission : 其他組件必須具有所填的權限才能啟動這個service。
android:process : service運行的進程的name。默認啟動的service是運行在主進程中的。
3、如何啟動service
startService()方式
組件如activity通過調用startStartService()方法，就可以啟動一個特定的service，在方法中傳遞一個intent參數，通關intent參數獲取數據。一旦啟動后，service就會獨立運行在后臺，即使調用的組件以及銷毀，service還可以繼續在后臺運行。當操作完成后service自行調用stopService()或者有組件調用針對它的stopService()來結束運行。應用被強制清理，service也會被殺死。
bindService()方式
比startService()方式復雜，同時使用這種方式啟動的service也能完成更多的事情，比如其他組件可向其發送請求，接受來自它的響應，甚至通過它來進行IPC等等。我們通常將綁定它的組件成為客戶端，而稱它為服務器。
如果要創建一個支持綁定的service，我們必須要重寫它的onBind()方法。這個方法會返回一個IBinder對象，它是客戶端用來和服務器進行交互的接口。而要得到IBinder接口，我們通常有三種方式：繼承Binder類，使用Messenger類，使用AIDL。
并且多個組件可以同時對一個 Service 進行綁定，只有在所有進行了綁定的組件都解綁的時候，Service 才會銷毀。
service和 ?IntentService
如果是擴建Service類的話，通常情況下我們需要新建一個用于執行工作的新線程，因為默認情況下service將工作于應用的主線程，而這將會降低所有正在運行的Activity的性能。而IntentService就不同了。它是Service的子類，它使用工作線程來處理所有的startService請求。如果你不要求這個service要同時處理多個請求，那么繼承這個類顯然要比直接繼承Service好
IntentService已經做了這些事：
- 創建默認的工作線程，用于在應用的主線程外執行傳遞給 onStartCommand() 的所有 Intent
- 創建工作隊列，用于將一個 Intent 逐一傳遞給 onHandleIntent() 實現，這樣的話就永遠不必擔心多線程問題了
- 在處理完所有啟動請求后停止服務，從此媽媽再也不用擔心我忘記調用 stopSelf() 了
- 提供 onBind() 的默認實現（返回 null）
- 提供 onStartCommand() 的默認實現，可將 Intent 依次發送到工作隊列和 onHandleIntent() 實現
因此我們只需要實現onHandleIntent()方法來完成具體的功能邏輯就可以了。
要注意的是，如果需要重寫其他的方法，比如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的調用，它可以同時執行多個請求——雖然官方的栗子里沒有這樣做。但是如果你想這樣做，就可以為每一個請求創建一個線程，然后立即運行這些請求。
- START_NOT_STICKY : 如果系統在 onStartCommand() 返回后終止服務，則除非有掛起 Intent 要傳遞，否則系統不會重建服務。這是最安全的選項，可以避免在不必要時以及應用能夠輕松重啟所有未完成的作業時運行服務。
- START_STICKY : 如果系統在 onStartCommand() 返回后終止服務，則會重建服務并調用 onStartCommand()，但絕對不會重新傳遞最后一個 Intent。相反，除非有掛起 Intent 要啟動服務（在這種情況下，將傳遞這些 Intent ），否則系統會通過空 Intent 調用 onStartCommand()。這適用于不執行命令、但無限期運行并等待作業的媒體播放器（或類似服務）。
- START_REDELIVER_INTENT : 如果系統在 onStartCommand() 返回后終止服務，則會重建服務，并通過傳遞給服務的最后一個 Intent 調用 onStartCommand()。任何掛起 Intent 均依次傳遞。這適用于主動執行應該立即恢復的作業（例如下載文件）的服務。
原文：http://www.lxweimin.com/p/d46f20695cb7
原文：http://blog.csdn.net/luoyanglizi/article/details/51980630
