这种新行为显然是为了阻止应用在后台做很多事情，而用户甚至都没有意识到，这很公平。
但是，建议的解决方法之一是改用计划作业。但这是否也可能导致应用程序“在用户不知情的情况下在后台做很多事情”？唯一的区别是 Android 决定何时完成这些事情，而不是应用程序。
那么，新限制的意义到底是什么？或者，也许我错过了一些基本的东西。
编辑:这不是 this question 的副本...那个是关于使用 startServiceInForeground() 作为替代方案(或关于与此相关的文档)，而这个问题是关于使用计划作业作为替代方案(以及这是否违背了完全新的限制)。这些是完全不同的选择。
最佳答案
我明白你的意思。
在我看来(在通读文档之后)这是我们使用新的 JobScheduler 的唯一好处。
但是，如果您查看 Job Scheduler Improvements in O
Scheduled jobs now support several new constraints:
JobInfo.isRequireStorageNotLow() Job does not run if the device's available storage is low.
JobInfo.isRequireBatteryNotLow() Job does not run if the battery level is at or below the criticial threshold; this is the level at which the device shows the Low battery warning system dialog.
NETWORK_TYPE_METERED Job requires a metered network connection, like most cellular data plans.
您会注意到对于每个 JobInfo您可以指定需要保留哪些约束才能开始作业。
Once the job has been started, it is then free to use as many resources as it wants for however long it wants.
这似乎是真的，因为文档中没有说明如果/何时再次需要资源会发生什么。但是，您可以将大任务分解为较小的任务，然后使用 [JobScheduler.enque()]( https://developer.android.com/reference/android/app/job/JobScheduler.html#enqueue(android.app.job.JobInfo , android.app.job.JobWorkItem)) 方法确保 JobScheduler 在开始队列中的下一个作业之前停止，如果否则系统需要资源。但是，如果 JobScheduler 为作业提供暂停/停止的方法或回调，这可能不是必需的(令人怀疑，因为文档没有涉及它)我自己从未尝试过。
结论:
总而言之，虽然新的 API 没有完全限制后台服务在所需资源可用时运行，但它确实为编码人员提供了一个平台来限制它们仅启动 当满足上述条件时，同时还限制所需的最小代码行。在大多数情况下，这应该可以最大限度地减少电池使用量并为用户提供更流畅的体验。
关于android - Android O 后台服务限制背后的逻辑，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/45502063/