Service stopSelf(int statId)和onStartcommand(Intent intent,int flags,int startId)

Stopping a service

A started service must manage its own lifecycle. That is, the system does not stop or destroy the service unless it must recover system memory and the service continues to run after onStartCommand() returns. So, the service must stop itself by calling stopSelf() or another component can stop it by calling stopService().

Once requested to stop with stopSelf() or stopService(), the system destroys the service as soon as possible.

However, if your service handles multiple requests to onStartCommand() concurrently, then you shouldn't stop the service when you're done processing a start request, because you might have since received a new start request (stopping at the end of the first request would terminate the second one). To avoid this problem, you can usestopSelf(int) to ensure that your request to stop the service is always based on the most recent start request. That is, when you call stopSelf(int), you pass the ID of the start request (the startId delivered toonStartCommand()) to which your stop request corresponds. Then if the service received a new start request before you were able to call stopSelf(int), then the ID will not match and the service will not stop.

 

    上面是來自google官網的Service說明文檔，大體意思是說：其一，用戶必須本身管理Service的生命週期，其二，調用stopSelf(int)方法時，傳入的startId和onStartcommand方法被回調時的startId應該相對應，這樣就能夠確保，當Service同時處理多個請求時，就不會由於第一個請求的結束後當即中止Service致使第二個請求沒有被徹底執行。上文紅色字體標出stopSelf(int)方法結束Service時，會以最近的請求的startId爲標準，也就是說，系統在回調stopSelf(startId)時，會用傳入的startId和最近的請求的startId相比較，若是相同，則退出Service，不然，Service不會被中止。

 

      如上圖，水平方向上三個箭頭，表明三個請求Service的任務，假設它們的執行時間都是同樣的，進一步假設它們的startId分別爲startId一、startId2和startId3。在T1時刻，Service接收到第一個請求，在T4時刻第一個請求已經被處理完畢，這時調用stopSelf(startId1)，結束Service的生命週期時，發現最近請求的startId爲startId3(T3時刻第三個請求到來了)，因此T4時刻根本停不掉Service，同理T5時刻也停不調，直到T6時刻時，三個排隊的任務都處理完了，才成功結束Service的生命週期。

 

      因此綜上，獲得基本的結論：

1. Service的stopSelf(int)方法被調用時不必定就能將本身的生命週期結束掉。
2. onStartCommand方法由AMS經過消息回調，因此是順序執行的，且在主線程中回調。
3. AMS中保存一個ServiceRecord，其實它是一個binder token，能夠跨進程傳遞代理對象到應用ActivityThread中，從而找到對應的Service對象。