这个问题只是为了了解这些概念的一些想法，以了解业内人们如何使用这些概念。报警管理器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网络管理器。