那我們回過頭來思考下這個在Android L時候加入的JobService和元老Service到底有何異同，各有什麼優勢？
在需要使用Service的時候，對於JobService和Service，我們該如何用哪一個？
首先從他們的實現原理去對比。
◆Service
由APP側發出請求，ActivityManagerService接收請求後進行調度，通知APP側進行創建，開始(綁定)，停止(解綁)和銷燬Service。
◆JobService
由APP側發出請求，JobSchedulerService接收請求後，通過ActivityManagerService去調度JobService的創建，綁定和解綁。
並由JobSchedulerService自己進行JobService的開始，取消和停止等操作。
從原理上看，JobService的開始，取消和停止是由JobSchedulerService維護的，而不是由ActivityManagerService維護的。
這是他們在實現原理上的明顯區別。
再者從他們的啓動條件上對比。
◆Service
Service的啓動並沒有什麼特定的條件設置。
如果說非要有什麼具體的執行條件的話，就是APP側自己根據業務邏輯在適當的時候調用startService()或者bindService()。
◆JobService
JobService的執行需要至少一個條件。沒有條件的JobService是無法啓動的，在創建JobInfo的時候會拋出異常。
然後從他們的啓動時機上對比。
◆Service
APP側一旦通知Context去執行startService()，APP側的Service將得到運行。
(使用bindService()的話，Service的運行取決於ServiceConnection的onServiceConnected()的回調)
◆JobService
JobService的執行必須等待執行條件滿足了才能被創建和開始。
再看看執行時間上的對比。
◆Service
onStartCommand()的回調在UI線程，不可執行耗時邏輯，否則可能造成ANR。
◆JobService
onStartJob()的回調在UI線程，不可執行耗時邏輯，否則可能造成ANR或者Job被強制銷燬(超過8s)。
並且，JobService裏即便新起了線程，處理的時間也不能超過10min，否則Job將被強制銷燬。
從能否再啓動角度看。
◆Service
onStartCommand()裏返回START_STICKY可以告訴AMS在被停止後自動啓動。
◆JobService
onStopJob()裏返回true，即可在被強制停止後再度啓動起來。
最後再從擴展性上看。
◆Service
APP側可以通過Binder創建遠程Service進行IPC。
◆JobService
JobService的綁定實際上是由JobSchedulerService自己去做的。
綁定後產生的Binder用於和JobSchedulerService進行IPC，APP側無法通過JobService擴展去實現別的IPC功能。
※Google本來的初衷也不是讓JobService實現遠程Service的功能。
從上面的幾個角度的對比，我們能夠清晰地看出來，兩者除了些許的共通之外，區別還是很明顯的。
聯繫到實際應用的話，他們的擅長領域應該是很清晰的。
實際應用上的對比
◆Service
適合需要常駐後臺，立即執行，進行數據獲取，功能維持的場景。
比如 音樂播放，定位，郵件收發等。
◆JobService
適合不需要常駐後臺，不需要立即執行，在某種條件下觸發，執行簡單任務的場景。
比如 聯繫人信息變化後的快捷方式的更新，定期的更新電話程序的聯繫人信息，壁紙更改後去從壁紙提取顏色的後臺任務。
簡單來講，Service適合一些優先級較高，執行任務複雜耗時的任務。
JobService適合輕量級的靈活的任務。
大家在實際開發的時候可以根據需要進行選擇，只不過要注意兩者的特性，恰當地使用。