兩種情況得運用場景：
1、用于長期執行某些操作，并且甚至與UI（主）線程沒有交互。比如啟動app直接去網絡下載文件
2、跨進程間通信，比如appA程序中Service被appB中程序調用
注意：Service默認時運行在它所在的宿主進程的主進程中，也就是說如果我們在Service中做耗時工作，UI（主）線程會卡死，出現ARN程序無響應現象。為了防止這種情況出現，我們一般都是在Service中創建一個新的線程來處理一些耗時工作，這樣就不會阻塞主線程。從這里也側面反映了Service不是另一個獨立的進程，Service自己本身不會開辟新的進程，除非手動來設置。默認情況下，Service是運行在本運用程序所屬的進程中。
Service啟動模式也有兩種，分別是：startService和bindService
1、通過startService方式啟動
如果運行在后臺的Service甚至不需要和UI（主）線程間進行交互，這種情況下，一般是調用startService來啟動Service。
2、通過bindService方式啟動
兩個不同進程間通信或者某個應用中Service方法的暴露出去（同個進程間），一般是調用bindService來啟動Service。
onCreate：如果多次執行了Context的startService方法啟動Service，Service方法的onCreate方法只會在第一次創建Service的時候調用一次，以后均不會再次調用。我們可以在onCreate方法中完成一些Service初始化相關的操作
onStartCommand：如果多次執行了Context的startService方法，那么Service的onStartCommand方法也會相應的多次調用。onStartCommand方法很重要，我們在該方法中根據傳入的Intent參數進行實際的操作，比如會在此處創建一個線程用于下載數據或播放音樂等
onBind：Service中的onBind方法是個抽象方法，所以Service類本身就是一個抽象類，也就是說onBind方法必須要重寫，即使用不到。通過startService使用Service時，我們在重寫onBind方法時，只需要將其返回值設為null即可。onBind方法主要是用于給bindService方法調用Service時才使用到。
onDestiny：Service銷毀時回調函數
如果Service啟動后沒有去停止掉它，它會一直運行下去，停止startService啟動的Service有兩種方法：
1、在外部調用stopService
2、在Service內部調用stopSelf方法
值得注意的是在onStartCommand中返回值，常用的返回值有：START_NOT_STICKY、START_SICKY和START_REDELIVER_INTENT,這三個都是靜態常理值。
START_NOT_STICKY：表示當Service運行的進程被Android系統強制殺掉之后，不會重新創建該Service，如果想重新實例化該Service，就必須重新調用startService來啟動。
使用場景：表示當Service在執行工作中被中斷幾次無關緊要或者對Android內存緊張的情況下需要被殺掉且不會立即重新創建這種行為也可接受的話，這是可以在onStartCommand返回值中設置該值。如在Service中定時從服務器中獲取最新數據
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：表示Service運行的進程被Android系統強制殺掉之后，與返回START_STICKY的情況類似，Android系統會將再次重新創建該Service，并執行onStartCommand回調方法，但是不同的是，Android系統會再次將Service在被殺掉之前最后一次傳入onStartCommand方法中的Intent再次保留下來并再次傳入到重新創建后的Service的onStartCommand方法中，這樣我們就能讀取到intent參數。
使用場景：如果我們的Service需要依賴具體的Intent才能運行（需要從Intent中讀取相關數據信息等），并且在強制銷毀后有必要重新創建運行，那么這樣的Service就適合返回START_REDELIVER_INTENT。
接著補充一個知識點，Service進一步的封裝類IntentService由于Service是運行在UI（主）線程中，會帶來UI阻塞，所以在操作耗時工作時，都在onStartCommand中開啟一個新的線程去執行一些耗時工作。正因為這樣，創建一個帶有工作線程Service是很常見的（因為工作線程不會阻塞主線程），為了簡化程序員工作量，Android額外開發了一個類那就是IntentService
IntentService特點:
1. IntentService
自帶一個工作線程，當我們的Service中做一些阻塞UI（主）線程工作時，可以使用IntentService。
2.將我們實際要做的工作放入到IntentService的onHandleIntent方法中處理，并且onHandleIntent運行在IntentService所持有的工作線程中，而非主線程。
3.當多次啟動IntentService，產生多個job，IntentService只能一個一個處理，也就是按照先后順序進行處理。先將intent1傳入onHandleIntent，讓其完成job1，然后將intent2傳入onHandleIntent，讓其完成job2…這樣直至所有job完成，所以我們IntentService不能并行地執行多個job，只能一個一個的按照先后順序完成，當所有job完成的時候IntentService就銷毀了，會執行onDestroy回調方法
