一、Service是什麼

Service是可執行程式，一直執行在後臺，沒有使用者介面，有自己的生命週期；主要有兩個應用場景：後臺執行和跨程式訪問，需要注意的是，Service是在主執行緒裡執行操作的，可能會因為執行耗時操作而導致ANR，如果需要處理耗時任務，則在Service中啟動另外一條新的子執行緒來處理耗時任務

二、 Service和執行緒的區別

• Thread：Thread 是程式執行的最小單元，可以用 Thread 來執行一些非同步的操作
• Service：Service 是android的一種機制，當它執行的時候如果是Local Service，那麼對應的 Service 是執行在主程式的 main 執行緒上的。如果是Remote Service，那麼對應的 Service 則是執行在獨立程式的 main 執行緒上。
• 解析：
  Thread 的執行是獨立的，也就是說當一個 Activity 被 finish 之後，如果沒有主動停止 Thread 或者 Thread 裡的 run 方法沒有執行完畢的話，Thread 也會一直執行。因此這裡會出現一個問題：當 Activity 被 finish 之後，不再持有該 Thread 的引用，也就是不能再控制該Thread。另一方面，沒有辦法在不同的 Activity 中對同一 Thread 進行控制。

例如：如果 一個Thread 需要每隔一段時間連線伺服器校驗資料，該Thread需要在後臺一直執行。這時候如果建立該Thread的Activity被結束了而該Thread沒有停止，那麼將沒有辦法再控制該Thread，除非kill掉該程式的程式。這時候如果建立並啟動一個 Service ，在 Service 裡面建立、執行並控制該 Thread，這樣便解決了該問題(因為任何 Activity 都可以控制同一個Service，而系統也只會建立一個對應 Service 的例項)。因此可以把 Service 想象成一種訊息服務，可以在任何有 Context 的地方呼叫 Context.startService Context.stopService、Context.bindService、Context.unbindService來控制它，也可以在 Service 裡註冊 BroadcastReceiver，通過傳送 broadcast 來達到控制的目的，這些都是 Thread 做不到的。

不少Android初學者都可能會有這樣的疑惑，Service和Thread到底有什麼關係呢？什麼時候應該用Service，什麼時候又應該用Thread？答案可能會有點讓你吃驚，因為Service和Thread之間沒有任何關係！之所以有不少人會把它們聯絡起來，主要就是因為Service的後臺概念。Thread我們大家都知道，是用於開啟一個子執行緒，在這裡去執行一些耗時操作就不會阻塞主執行緒的執行。而Service我們最初理解的時候，總會覺得它是用來處理一些後臺任務的，一些比較耗時的操作也可以放在這裡執行，這就會讓人產生混淆了

Android的後臺就是指，它的執行是完全不依賴UI的。即使Activity被銷燬，或者程式被關閉，只要程式還在，Service就可以繼續執行。比如說一些應用程式，始終需要與伺服器之間始終保持著心跳連線，就可以使用Service來實現。你可能又會問，前面不是剛剛驗證過Service是執行在主執行緒裡的麼？在這裡一直執行著心跳連線，難道就不會阻塞主執行緒的執行嗎？當然會，但是我們可以在Service中再建立一個子執行緒，然後在這裡去處理耗時邏輯就沒問題了。額，既然在Service裡也要建立一個子執行緒，那為什麼不直接在Activity裡建立呢？這是因為Activity很難對Thread進行控制，當Activity被銷燬之後，就沒有任何其它的辦法可以再重新獲取到之前建立的子執行緒的例項。而且在一個Activity中建立的子執行緒，另一個Activity無法對其進行操作。但是Service就不同了，所有的Activity都可以與Service進行關聯，然後可以很方便地操作其中的方法，即使Activity被銷燬了，之後只要重新與Service建立關聯，就又能夠獲取到原有的Service中Binder的例項。因此，使用Service來處理後臺任務，Activity就可以放心地finish，完全不需要擔心無法對後臺任務進行控制的情況。

三、Service的生命週期

1334628702_9553.png

Activity呼叫bindService()繫結一個已經有startService()的服務時，Service只是把內部的IBinder傳給Activity,並沒有把整個生命週期繫結到Activity，因此ActivityunBindService()取消繫結時，只是切斷Activity與Service之間的聯絡。

四、 onStartCommand()和onStart()區別

• 啟動service的時候，onCreate方法只有第一次會呼叫，onStartCommand和onStart每次都被呼叫
• onstart()方法是在android2.0一下的版本中使用。而在android2.0以上則使用onstartCommand()方法
• onStartComand使用時，返回的是一個(int)整形。
  這個整形可以有四個返回值：start_sticky、start_no_sticky、START_REDELIVER_INTENT、START_STICKY_COMPATIBILITY。
  它們的含義分別是：
  1、START_STICKY：如果service程式被kill掉，保留service的狀態為開始狀態，但不保留遞送的intent物件。隨後系統會嘗試重新建立service，由於服務狀態為開始狀態，所以建立服務後一定會呼叫onStartCommand(Intent,int,int)方法。如果在此期間沒有任何啟動命令被傳遞到service，那麼引數Intent將為null。
  2、START_NOT_STICKY：“非粘性的”。使用這個返回值時，如果在執行完onStartCommand後，服務被異常kill掉，系統不會自動重啟該服務
  3、START_REDELIVER_INTENT：重傳Intent。使用這個返回值時，如果在執行完onStartCommand後，服務被異常kill掉，系統會自動重啟該服務，並將Intent的值傳入。
  4、START_STICKY_COMPATIBILITY：START_STICKY的相容版本，但不保證服務被kill後一定能重啟。

五、Service使用場景

• Service的優點：使用方便；建立程式方便；可以提供給系統內其他App使用；優先順序高，當App退到後臺後不宜被殺死。缺點是由於啟動Service涉及到多次IPC，執行效率不高，而且受限於系統介面，使用不夠靈活。
• 執行緒池的優點：是執行效率高，配置和使用靈活。缺點是多程式實現不方便， 由於Android實現了一套程式託管機制，我們不能直接建立一個新的程式，而只能通過四大元件的形式建立新的程式

一般普通的非同步任務，比如網路請求，資料庫或者檔案相關操作，我們都會使用執行緒池的方式來做，因為這樣使用的系統開銷小，執行效率高，而且隨著業務邏輯的複雜度增加，擴充套件性也更強。
對於一些特殊場景，比如程式保活，使用第三方SDK服務比如地圖，IM等，就需要使用Service來實現，因為這些服務一般與App主程式隔離開，需要執行在新程式中以防止App主程式發生異常崩潰時;