什麼是START_STICKY，START_NOT_STICKY和START_REDELIVER_INTENT服務

Question

我無法理解

1. START_STICKY，
2. START_NOT_STICKY和
3. START_REDELIVER_INTENT

誰能舉例解釋清楚。

我經歷了this鏈接，但無法清楚地理解它。

Answer 1

這些與服務有關。我們都知道服務會在後臺運行，並且還會消耗一些內存來執行。

因此，隨着更多的應用程序在Android設備上運行，設備內存不斷下降，當時間到了，當設備內存嚴重不足時，android系統啓動終止進程，釋放內存由進程佔用。

但是，您可能正在做一些與服務有關的重要任務，也可能會在服務停止時終止。 所以這些概念是告訴android系統當設備內存變得穩定時以及準備重新啓動服務時要執行的操作。

這些最簡單的解釋是，

START_STICKY-告訴系統創建服務，全新副本時有足夠內存，它從低內存恢復後。在這裏，您將失去之前可能計算的結果。

START_NOT_STICKY-告訴系統即使在有足夠的內存時也不要去重新啓動服務。

START_REDELIVER_INTENT-告訴系統在崩潰後重新啓動服務，並重新傳送崩潰時出現的意圖。

Answer 2

那麼，我讀了你的鏈接中的線程，它說明了一切。

如果你的服務是由Android由於內存不足殺死，而Android清除一些記憶，然後......

1. 置頂：... Android將重新啓動服務，因爲該特定標誌。
2. NOT_STICKY：... Android不會在意再次啓動，因爲該標誌告訴Android它不應該打擾。
3. REDELIVER_INTENT：... Android將重新啓動該服務並重新傳遞該服務的相同意圖onStartCommand()，因爲該標誌也是。

Answer 3

這兩個代碼僅在手機內存不足並在完成執行前殺死服務時才相關。 START_STICKY告訴操作系統在有足夠內存後重新創建服務，並再次以空目的調用onStartCommand（）。 START_NOT_STICKY告訴操作系統不要再次重新創建服務。還有第三個代碼START_REDELIVER_INTENT告訴操作系統重新創建服務並將其重新發送到onStartCommand（）的同一個意圖。

這篇由Dianne Hackborn撰寫的文章解釋了這個比官方文檔更好的背景。

來源：http://android-developers.blogspot.com.au/2010/02/service-api-changes-starting-with.html

這裏的關鍵部分是由函數返回，系統知道它應該與服務做了新的結果代碼，如果同時運行其進程被終止：

START_STICKY與之前的行爲基本相同，其中 服務保留「啓動」狀態，稍後將由系統重新啓動。 與以前版本的平臺的唯一區別是，如果它因爲其進程被終止而重新啓動，它將在下一個服務實例上調用onStartCommand（） 而不是根本沒有。使用這種模式的服務應該總是檢查這種情況並適當地處理它。

START_NOT_STICKY說，從onStartCreated（）返回後，如果 該進程在沒有剩餘的啓動命令交付的情況下被終止，則該服務將停止而不是重新啓動。這使 對於僅在 執行發送給它們的命令時才運行的服務更有意義。例如，可以從警報每隔15分鐘開始一次服務，以輪詢某些網絡狀態。如果在做這項工作時遇到了 死亡，最好是讓它停止，並在下次火警發生時開始。

START_REDELIVER_INTENT就像START_NOT_STICKY，但如果 服務的過程中被殺害，它調用stopSelf（）對於一個給定 意圖，這一意圖將重新傳遞給它之前，直到它完成 （除非在一些數量更多的嘗試它仍然無法完成，在 系統放棄哪個點）。這對 接收工作命令的服務很有用，並且希望確保他們最終完成每個發送的命令的工作。