這個問題只是爲了瞭解這些概念的一些想法，以瞭解業內人們如何使用這些概念。報警管理器vs Job Scheduler vs ScheduledThreadPoolExecutor
如果你可以給每一個這樣的例子使用，我將不勝感激。我知道他們是如何工作的，並且閱讀了關於他們的谷歌文檔，但我似乎仍然難以選擇一個。我不需要你向我解釋他們是如何工作的。我只是要求他們的一些示例用途。你最終如何將它們整合到你的應用程序中，以及爲什麼你選擇了它們。
感謝
AlarmManager
使用AlarmManager排定在系統級
的AlarmManager提供訪問系統級別的報警服務任務。使用AlarmManager允許應用程序安排可能需要運行或重複超出其生命週期範圍的任務。這允許應用程序甚至在應用程序進程或其所有Android組件已被系統清理之後執行一些功能。
通常情況下，AlarmManager用於啓動未來啓動服務的PendingIntent。 AlarmManager根據已用間隔或特定時鐘時間觸發服務。如果警報緊急，這兩種選項都可以在設備處於睡眠狀態時喚醒設備。
使用不精確的時間間隔或時間來啓動服務時，AlarmManager的好處就起作用了。 Android系統會嘗試以相似的時間間隔或次數將警報分批處理，以便延長電池壽命。通過批量處理來自多個應用程序的警報，系統可以避免頻繁的設備喚醒和聯網。
使用AlarmManager時需要考慮的一個問題是，在設備重啓過程中警報會被清除。應用程序需要在他們的Android Manifest中註冊RECEIVE_BOOT_COMPLETE權限，並在BroadcastReceiver中重新安排其警報。
另一個問題是，一個設計不當的警告可能會導致電池消耗。雖然AlarmManager確實能夠喚醒設備併爲報警設置確切時間，但文檔中提到開發人員在執行聯網時應該謹慎使用這些功能。除了通過避免批量警報消除設備電池外，如果每個應用程序安裝都嘗試與服務器同時同步，那麼爲應用程序設置與服務器同步的準確時間可能會給服務器帶來很大壓力！這可以通過向警報間隔或時間添加一些隨機性來避免。
如果應用程序需要在確切的時間或不精確的時間間隔執行本地事件，AlarmManager是一個很好的調度候選。鬧鐘或提醒應用程序是AlarmManager使用的很好例子。但是，文檔不鼓勵使用AlarmManager來調度與網絡相關的任務。讓我們來看看一些更好的網絡選擇。
作業調度
的jobscheduler有助於以高效的方式進行後臺工作，特別是網絡。 JobServices計劃根據JobInfo.Builder（）中聲明的條件運行。這些標準包括僅在設備充電，空閒，連接到網絡或連接到未計量的網絡時執行JobService。 JobInfo還可以包含執行JobService的最小延遲和某些截止日期。如果沒有滿足這些標準，則作業將在系統中排隊等待以後執行。系統還會嘗試按照計劃報警的方式將這些作業分批處理，以便在進行網絡連接時節省電池使用時間。
開發人員可能會關注一個調度程序，這個調度程序經常會延遲觸發它的JobServices。如果工作經常因爲工作延遲而導致數據陳舊，那麼知道這樣的事情會很好。 JobScheduler將返回有關JobService的信息，例如重新計劃或失敗。 JobScheduler具有回退和重試邏輯來處理這些場景，或者開發人員可以自己處理這些場景。
子類JobService需要覆蓋onStartJob（JobParams params）和onStopJob（JobParams params）方法。 onStartJob（）是應放置作業的回調邏輯的位置，它在主線程上運行。處理長時間運行的作業時，開發人員負責線程。如果單獨的線程處理需要發生，則返回true onStartJob（）;如果主線程上可以進行處理並且此作業不再需要完成任何工作，則返回false。開發人員還必須在作業完成時調用jobFinished（JobParameters params，布爾needsReschedule）並確定是否重新安排更多作業。當不再滿足初始JobInfo參數時，onStopJob（）將被調用以停止或清除任務，例如，如果該參數是需求，則用戶拔下其設備。
在實現JobService時可能有很多想法，但它比AlarmManager具有更多的靈活性。另一個方便的功能是，通過系統重新啓動，計劃的作業持續存在。
使用JobScheduler至少有一個缺點。在撰寫這篇文章時，它僅適用於API等級21及更高版本。在這裏您可以找到運行各種API級別的Android設備的分佈。雖然技術上沒有JobScheduler的後臺端口，但類似的工具是GCM網絡管理器。