524
Service onStartCommand各種返回詳解，解決問題：隻調用onCreate不調用onStartCommand
Service原理這裏不介紹，隻介紹onStartCommand的返回和Android Reference中的問題。
onStartCommand方法必須具有一個整形的返回值，這個整形的返回值是一個描述性質的數值，用來告訴係統在服務啟動完畢後，一旦遇到服務被係統銷毀（System kill），係統將如何繼續（操作），這些返回值必須是以下一個：
START_NOT_STICKY
如果係統在onStartCommand返回後被銷毀，係統將不會重新創建服務，除非收到一個未處理（pending懸而未決地）的Intent，當不是必須（necessary）並且Android應用能夠自行簡單地（simply）重啟未完成業務（不通過服務），那麼這樣的設定是最安全的（safest）。
如果係統在onStartCommand返回後被銷毀，係統將會重新創建服務並依次調用onCreate和onStartCommand（注意：根據測試Android2.3.3以下版本隻會調用onCreate根本不會調用onStartCommand，Android4.0可以辦到），重新創建的操作將會作為事件日程序列（schedule）加入到係統事件日程列表中，在延遲一個計算時間（如：5000ms）後重新啟動。但是不會重新將之前的傳入的Intent創新傳遞給、
onStartCommand，除非重新收到一個未處理（pending懸而未決地）的Intent，在這種情況下（inwhich case），未處理的心得Intent仍然按照流程被傳入和處理，但是前一次操作的Intent將會變null（等同於一次帶null intent的啟動）。對於不需要立刻執行命令的服務，如多媒體播放器（或者其他類似（similar）的服務）那麼這樣的設定是非常適合的，但是服務會無限期的運行，並等待一個適合的工作（個人理解：就是服務等於又重新啟動恢複到之前的狀態了）。
同START_STICKY，在重新調用onStartCommand的時候，之前的Intent將會被保留，並重新傳遞給該方法，除非此時出現了一次新的啟動服務請求，那麼Intent將會被替換成新的，否則仍然使用舊的Intent。經過測試Android2.3.3對於該操作同樣有效。
注意：以上行為隻有在System kill event的情況下有效，stopSelf和stopService都不會過問onStartCommand的返回狀態。
名詞解釋：
System kill:係統殺死服務，以釋放內存，在低內存的情況下係統會自行操作,System kill之後的操作有onStartCommand的返回值決定，注意，正常結束服務是不會發生重啟的，因為服務結束並不代表服務實例被釋放，一個服務實例可以被多次啟動，但是這並不表示產生了多個服務實例，從DDMS可以看到他們和hosting process使用同一個PID，服務實例是綁定在hosting process 主線程消息隊列的（Message Queue）。
最後更新：2017-04-02 17:28:39