here和here解释了运行后台服务的新限制。
这种新行为显然是为了阻止应用在后台进行大量工作而用户甚至不知道，这是公平的。
但是，建议的解决方法之一是使用预定作业。但是，这并不会导致应用程序在后台执行大量操作而用户甚至不知道＆＃34 ;?唯一的区别是Android决定何时完成这些工作，而不是应用程序。
那么，新限制究竟是什么意思呢？或者也许我错过了一些基本的东西。
编辑：这是不是this question的副本......一个是关于使用startServiceInForeground()作为替代（或与此相关的文档）而这个问题是关于使用预定作业作为替代方案（以及是否完全违背了新限制的目的）。这些是完全不同的选择。
1 个答案:
答案 0 :(得分：0)
I see your point.
Seems to me (after reading through the docs) this is the only pro that we get using the new JobScheduler.
However if you look through 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.
You would notice that for each JobInfo you get to specify which constraints need to hold for the job to start.
Once the job has been started, it is then free to use as many resources as it wants for however long it wants.
That seems to be true, since there is no indication from the docs on what would happen if/when the resources are required again. However you can break down your big task into smaller tasks and then use the [JobScheduler.enque()](https://developer.android.com/reference/android/app/job/JobScheduler.html#enqueue(android.app.job.JobInfo, android.app.job.JobWorkItem)) method to ensure that the JobScheduler stops before starting next job in queue if the System otherwise requires resources. However this may not be necessary if JobScheduler provides a method or a callback to the Job to pause/stop (doubtful since the docs don't get into it) I've never tried it myself.
Conclusion :
So in conclusion while the new API does not completely restrict the Background Services to run while required resources are available, it does however provide a platform for the coder to restrict them to start only when above mentioned conditions are met while also restricting min lines of code required. Which should in most cases minimize battery usage and provide a smoother experience to user.