1.onStartCommand()方法
在Android開發中，調用Context的startService方法啓動Service的生命週期時，如果Android面臨內存匱乏，可能會銷燬掉你當前運行的Service，然後待內存充足的時候可以重新創建Service，Service被Android系統強制銷燬並再次重建的行爲依賴於Service中onStartCommand方法的返回值。而Service onStartCommand方法中，常用的返回值主要有：START_NOT_STICKY、START_STICKY和START_REDELIVER_INTENT三種，這三個值都是Service中的靜態常量。下面小編就和大家分享下這三種返回值的具體的含義及使用情況。
START_NOT_STICKY
如果返回START_NOT_STICKY，表示當Service運行的進程被Android系統強制殺掉之後，不會重新創建該Service，當然如果在其被殺掉之後一段時間又調用了startService，那麼該Service又將被實例化。那什麼情境下返回該值比較恰當呢？如果我們某個Service執行的工作被中斷幾次無關緊要或者對Android內存緊張的情況下需要被殺掉且不會立即重新創建這種行爲也可接受，那麼我們便可將 onStartCommand的返回值設置爲START_NOT_STICKY。舉個例子，某個Service需要定時從服務器獲取最新數據：通過一個定時器每隔指定的N分鐘讓定時器啓動Service去獲取服務端的最新數據。當執行到Service的onStartCommand時，在該方法內再規劃一個N分鐘後的定時器用於再次啓動該Service並開闢一個新的線程去執行網絡操作。假設Service在從服務器獲取最新數據的過程中被Android系統強制殺掉，Service不會再重新創建，這也沒關係，因爲再過N分鐘定時器就會再次啓動該Service並重新獲取數據。
START_STICKY
如果返回START_STICKY，表示Service運行的進程被Android系統強制殺掉之後，Android系統會將該Service依然設置爲started狀態（即運行狀態），但是不再保存onStartCommand方法傳入的intent對象，然後Android系統會嘗試再次重新創建該Service，並執行onStartCommand回調方法，但是onStartCommand回調方法的Intent參數爲null，也就是onStartCommand方法雖然會執行但是獲取不到intent信息。如果你的Service可以在任意時刻運行或結束都沒什麼問題，而且不需要intent信息，那麼就可以在onStartCommand方法中返回START_STICKY，比如一個用來播放背景音樂功能的Service就適合返回該值。
START_REDELIVER_INTENT
如果返回START_REDELIVER_INTENT，表示Service運行的進程被Android系統強制殺掉之後，與返回START_STICKY的情況類似，Android系統會將再次重新創建該Service，並執行onStartCommand回調方法，但是不同的是，Android系統會再次將Service在被殺掉之前最後一次傳入onStartCommand方法中的Intent再次保留下來並再次傳入到重新創建後的Service的onStartCommand方法中，這樣我們就能讀取到intent參數。只要返回START_REDELIVER_INTENT，那麼onStartCommand重的intent一定不是null。如果我們的Service需要依賴具體的Intent才能運行（需要從Intent中讀取相關數據信息等），並且在強制銷燬後有必要重新創建運行，那麼這樣的Service就適合返回START_REDELIVER_INTENT。
ps:關於生命週期中的onStart()方法
從圖中可以看出沒有該方法，實際測試也不會打印onStart()的log;
onStart方法是在Android2.0之前的平臺使用的.在2.0及其之後，則需重寫onStartCommand方法，同時，舊的onStart方法則不會再被直接調用（外部調用onStartCommand，而onStartCommand裏會再調用 onStart。在2.0之後，推薦覆蓋onStartCommand方法，而爲了向前兼容，在onStartCommand依然會調用onStart方法，即平常基本用不到了。
2.關於生命週期中的onStartCommand()方法如果用startService()方法啓動Service，OnStartCommand方法能夠執行；
如果用bindService（）方法啓動Service，OnstartCommand方法就不能夠執行了。
其實個人認爲這和onStartCommand的作用也有關，這個方法可以設置進程意外結束時是否重啓。但是bind方法是和啓動它的主線程綁定的，生命週期也綁定。因此理論上進程結束，他也就結束了，不會有服務再次單獨啓動大的問題
