Android O后台服务限制背后的逻辑

Question

关于运行后台服务的新限制在这里和这里有解释。

这种新的行为显然是为了防止应用在用户毫不知情的情况下大量使用后台功能，这是公平的。

然而，其中一个建议的解决方法是改用定时任务。但这难道不也可能导致应用程序“在用户毫不知情的情况下大量使用后台功能”吗？唯一的区别是Android决定何时完成这些操作，而不是应用程序。

那么，新限制的意义到底是什么呢？或者我可能错过了一些基本的东西。

编辑：这不是这个问题的重复...那个问题是关于使用startServiceInForeground()作为替代方案（或相关文档），而这个问题是关于使用定时任务作为替代方案（以及是否完全打败了新限制的目的）。这些是完全不同的替代方案。

- drmrbrewer

---

我认为现在的JobScheduler只有在系统有可用资源时才会启动。而不是允许每个后台服务尽可能地占用资源并运行。 - Abbas

@Abbas 是的，但是一旦工作开始了，它就可以自由地使用尽可能多的资源，无论需要多长时间，对用户没有任何可见的指示，这显然是这些新限制旨在防止发生的情况。通常，如果您安排一个工作现在开始，并且所有条件都得到满足，那么它确实会在现在附近开始... 实际上与按照预先-O行为调用startService()没有什么不同。 - drmrbrewer

好的一面是，提供的解决方案过于专注于Webtraffic。如果您需要在后台扫描特定设备，比如使用BLE进行工作，则没有解决方案。 - Christopher

Answer 1

我了解你的观点。

在阅读文档后，我认为这是我们使用新JobScheduler获得的唯一优势。

但是，如果您查看O中的Job Scheduler Improvements，

计划作业现在支持多个新约束：

JobInfo.isRequireStorageNotLow() 如果设备的可用存储空间较低，则作业不会运行。

JobInfo.isRequireBatteryNotLow() 如果电池电量达到或低于临界阈值，则作业不会运行；这是设备显示低电池警告系统对话框的级别。

NETWORK_TYPE_METERED 作业需要按计量收费的网络连接，例如大多数蜂窝数据计划。

您会注意到，对于每个JobInfo，您可以指定需要满足哪些约束才能启动作业。

一旦作业已启动，则可以自由地使用尽可能多的资源，时间长短都没有限制。

这似乎是正确的，因为文档中没有任何迹象表明如果/当再次需要资源时会发生什么。但是，您可以将大任务分解为较小的任务，然后使用[JobScheduler.enque()](https://developer.android.com/reference/android/app/job/JobScheduler.html#enqueue(android.app.job.JobInfo, android.app.job.JobWorkItem))方法来确保如果系统需要资源，则JobScheduler在启动下一个作业之前停止。但是，如果JobScheduler提供了一种方法或回调来暂停/停止作业（文档中没有涉及，所以值得怀疑），则可能不需要这样做。我自己从未尝试过。

---

结论：

综上所述，虽然新的 API 并没有完全禁止后台服务在可用资源时运行，但它提供了一个平台，让编码人员在满足上述条件的情况下限制它们仅在需要时开始工作，并限制所需的最小代码行数。这在大多数情况下应该可以最小化电池使用量并为用户提供更流畅的体验。

- Abbas