Service和Thread的關係及如何啟用Service，如何停用Service，threadservice

Service和Thread的關係及如何啟用Service，如何停用Service，threadservice

Service和Thread的關係：

不少Android初學者都可能會有這樣的疑惑，Service和Thread到底有什麼關係呢？什麼時候應該用Service，什麼時候又應該用Thread？答案可能會有點讓你吃驚，因為Service和Thread之間沒有任何關係！ 之所以有不少人會把它們聯絡起來，主要就是因為Service的後台概念。Thread我們大家都知道，是用於開啟一個子線程，在這裡去執行一些耗時操作就不會阻塞主線程的運行。而Service我們最初理解的時候，總會覺得它是用來處理一些背景工作的，一些比較耗時的操作也可以放在這裡運行，這就會讓人產生混淆了。但是，如果我告訴你Service其實是運行在主線程裡的，你還會覺得它和Thread有什麼關係嗎？讓我們看一下這個殘酷的事實吧。 在MainActivity的onCreate()方法裡加入一行列印當前線程id的語句： [java] view plaincopyLog.d("MyService", "MainActivity thread id is " + Thread.currentThread().getId());  然後在MyService的onCreate()方法裡也加入一行列印當前線程id的語句：[java] view plaincopyLog.d("MyService", "MyService thread id is " + Thread.currentThread().getId());  現在重新運行一下程式，並點擊Start Service按鈕，會看到如下列印日誌：                                  可以看到，它們的線程id完全是一樣的，由此證實了Service確實是運行在主線程裡的，也就是說如果你在Service裡編寫了非常耗時的代碼，程式必定會出現ANR的。 你可能會驚呼，這不是坑爹麼！？那我要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：

服務的開發比較簡單，如下：

第一步：繼承Service類

public classSMSService extends Service {}

第二步：在AndroidManifest.xml檔案中的<application>節點裡對服務進行配置:<service android:name=".SMSService"/>

服務不能自己運行，需要通過調用Context.startService()或Context.bindService()方法啟動服務。這兩個方法都可以啟動Service，但是它們的使用場合有所不同。使用startService()方法啟用服務，調用者與服務之間沒有關連，即使調用者退出了，服務仍然運行。使用bindService()方法啟用服務，調用者與服務綁定在了一起，調用者一旦退出，服務也就終止，大有“不求同時生，必須同時死”的特點。

如果打算採用Context.startService()方法啟動服務，在服務未被建立時，系統會先調用服務的onCreate()方法，接著調用onStart()方法。如果調用startService()方法前服務已經被建立，多次調用startService()方法並不會導致多次建立服務，但會導致多次調用onStart()方法。採用startService()方法啟動的服務，只能調用Context.stopService()方法結束服務，服務結束時會調用onDestroy()方法。

如果打算採用Context.bindService()方法啟動服務，在服務未被建立時，系統會先調用服務的onCreate()方法，接著調用onBind()方法。這個時候調用者和服務綁定在一起，調用者退出了，系統就會先調用服務的onUnbind()方法，接著調用onDestroy()方法。如果調用bindService()方法前服務已經被綁定，多次調用bindService()方法並不會導致多次建立服務及綁定(也就是說onCreate()和onBind()方法並不會被多次調用)。如果調用者希望與正在綁定的服務解除綁定，可以調用unbindService()方法，調用該方法也會導致系統調用服務的onUnbind()-->onDestroy()方法。

 

服務常用生命週期回調方法如下：

onCreate() 該方法在服務被建立時調用，該方法只會被調用一次，無論調用多少次startService()或bindService()方法，服務也只被建立一次。

onDestroy()該方法在服務被終止時調用。

與採用Context.startService()方法啟動服務有關的生命週期方法

onStart() 只有採用Context.startService()方法啟動服務時才會回調該方法。該方法在服務開始運行時被調用。多次調用startService()方法儘管不會多次建立服務，但onStart() 方法會被多次調用。

與採用Context.bindService()方法啟動服務有關的生命週期方法

onBind()只有採用Context.bindService()方法啟動服務時才會回調該方法。該方法在調用者與服務綁定時被調用，當調用者與服務已經綁定，多次調用Context.bindService()方法並不會導致該方法被多次調用。

onUnbind()只有採用Context.bindService()方法啟動服務時才會回調該方法。該方法在調用者與服務解除綁定時被調用