Android。应用程序关闭时 WorkManager 运行？
Android. Is WorkManager running when app is closed?
我想安排夜间数据库更新。所以我使用新的 Android WorkManager。我的理解是，一旦安排好，它将始终 运行 在后台独立于应用程序的生命周期。
那正确吗？我的第一个测试表明 Work 仅在应用 运行ning.
时执行
val locationWork = PeriodicWorkRequest.Builder(UpdateDatabaseWorker::class.java, 24, TimeUnit.HOURS)
.addTag("DATABASE_UPDATE_SERVICE")
.build()
WorkManager.getInstance().enqueue(locationWork)
My understanding is that once scheduled it will always run in the
background independently from the app's lifecycle. Is that right?
是的。基于 documentation
The task is still guaranteed to run, even if your app is force-quit or
the device is rebooted.
WorkManager 根据设备 API 级别和应用程序状态等因素选择适当的方式来 运行 您的任务。如果 WorkManager 在应用 运行ning 时执行您的任务之一，WorkManager 可以 运行 在应用进程的新线程中执行您的任务。如果您的应用不是 运行ning，WorkManager 会选择合适的方式来安排后台任务——具体取决于设备 API 级别。
WorkManager 可能会使用 JobScheduler、Firebase JobDispatcher 或 AlarmManager，具体取决于 API 级别。在执行工作之前，它将尊重打瞌睡并考虑所有其他约束。您可以预期打瞌睡模式会有一些延迟，因为它可能等待维护 window.
注：
WorkManager is intended for tasks that require a guarantee that the system will run them even if the app exits, like uploading app data to a server. It is not intended for in-process background work that can safely be terminated if the app process goes away; for situations like that, we recommend using ThreadPools.
文档是这么说的：
Note: WorkManager is intended for tasks that require a guarantee that the system will run them even if the app exits, like uploading app data to a server. It is not intended for in-process background work that can safely be terminated if the app process goes away; for situations like that, we recommend using ThreadPools.
但必须有一些条件。 如果该条件满足，那么 WorkManager 将 运行 任务 （这很重要）。条件 如 "only while device is charging and online"
阅读此 carefully，WorkManager 会尝试 运行 您的任务以您请求的时间间隔执行，服从您施加的约束 及其其他要求。
在这里我找到了一个关于如何使用 WorkManager 来安排任务的很好的教程：https://android.jlelse.eu/how-scheduling-work-with-new-android-jetpack-component-workmanager-852163f4825b
根据 WorkManager bugtracker 上报告的各种问题，他们的文档对 WorkManager[=45 的确切行为并不完全准确=] 在这种边缘情况下。
On certain devices, apps are force stopped when the app is cleared from task manager, so that part is expected. ... source
Unfortunately, some devices implement killing the app from the recents menu as a force stop. Stock Android does not do this. When an app is force stopped, it cannot execute jobs, receive alarms or broadcasts, etc. So unfortunately, it's infeasible for us to address it - the problem lies in the OS and there is no workaround. source
The only issue that we have come across is the case where some Chinese OEMs treat swipe to dismiss from Recents as a force stop. When that happens, WorkManager will reschedule all pending jobs, next time the app starts up. Given that this is a CDD violation, there is not much more that WorkManager can do given its a client library. source
To add to this, if a device manufacturer has decided to modify stock Android to force-stop the app, WorkManager will stop working (as will JobScheduler, alarms, broadcast receivers, etc.). There is no way to work around this. Some device manufacturers do this, unfortunately, so in those cases WorkManager will stop working until the next time the app is launched. source
在 Pixel 2 XL 上 android 对 OneTimeWorkRequest（无限制）进行严格测试后，行为如下：
- 任务管理器关闭：
- 工作继续（稍后）
- 重启设备（工作运行）：
- 重启完成后继续工作
- “强行停止”应用信息：
- 工作停止，只有在应用程序再次启动时才会继续
- 重启设备（工作被“强制停止”）：
- 应用程序再次启动后工作才会继续
您可以在 dontkillmyapp.com. It seems the Android team also acknowledges this issue and added a test for this into their CTS test for Android Q. source
上找到不同 OEM 行为的完整列表
我想安排夜间数据库更新。所以我使用新的 Android WorkManager。我的理解是，一旦安排好，它将始终 运行 在后台独立于应用程序的生命周期。 那正确吗？我的第一个测试表明 Work 仅在应用 运行ning.
时执行val locationWork = PeriodicWorkRequest.Builder(UpdateDatabaseWorker::class.java, 24, TimeUnit.HOURS)
.addTag("DATABASE_UPDATE_SERVICE")
.build()
WorkManager.getInstance().enqueue(locationWork)
My understanding is that once scheduled it will always run in the background independently from the app's lifecycle. Is that right?
是的。基于 documentation
The task is still guaranteed to run, even if your app is force-quit or the device is rebooted.
WorkManager 根据设备 API 级别和应用程序状态等因素选择适当的方式来 运行 您的任务。如果 WorkManager 在应用 运行ning 时执行您的任务之一，WorkManager 可以 运行 在应用进程的新线程中执行您的任务。如果您的应用不是 运行ning，WorkManager 会选择合适的方式来安排后台任务——具体取决于设备 API 级别。
WorkManager 可能会使用 JobScheduler、Firebase JobDispatcher 或 AlarmManager，具体取决于 API 级别。在执行工作之前，它将尊重打瞌睡并考虑所有其他约束。您可以预期打瞌睡模式会有一些延迟，因为它可能等待维护 window.
注：
WorkManager is intended for tasks that require a guarantee that the system will run them even if the app exits, like uploading app data to a server. It is not intended for in-process background work that can safely be terminated if the app process goes away; for situations like that, we recommend using ThreadPools.
文档是这么说的：
Note: WorkManager is intended for tasks that require a guarantee that the system will run them even if the app exits, like uploading app data to a server. It is not intended for in-process background work that can safely be terminated if the app process goes away; for situations like that, we recommend using ThreadPools.
但必须有一些条件。 如果该条件满足，那么 WorkManager 将 运行 任务 （这很重要）。条件 如 "only while device is charging and online"
阅读此 carefully，WorkManager 会尝试 运行 您的任务以您请求的时间间隔执行，服从您施加的约束 及其其他要求。
在这里我找到了一个关于如何使用 WorkManager 来安排任务的很好的教程：https://android.jlelse.eu/how-scheduling-work-with-new-android-jetpack-component-workmanager-852163f4825b
根据 WorkManager bugtracker 上报告的各种问题，他们的文档对 WorkManager[=45 的确切行为并不完全准确=] 在这种边缘情况下。
On certain devices, apps are force stopped when the app is cleared from task manager, so that part is expected. ... source
Unfortunately, some devices implement killing the app from the recents menu as a force stop. Stock Android does not do this. When an app is force stopped, it cannot execute jobs, receive alarms or broadcasts, etc. So unfortunately, it's infeasible for us to address it - the problem lies in the OS and there is no workaround. source
The only issue that we have come across is the case where some Chinese OEMs treat swipe to dismiss from Recents as a force stop. When that happens, WorkManager will reschedule all pending jobs, next time the app starts up. Given that this is a CDD violation, there is not much more that WorkManager can do given its a client library. source
To add to this, if a device manufacturer has decided to modify stock Android to force-stop the app, WorkManager will stop working (as will JobScheduler, alarms, broadcast receivers, etc.). There is no way to work around this. Some device manufacturers do this, unfortunately, so in those cases WorkManager will stop working until the next time the app is launched. source
在 Pixel 2 XL 上 android 对 OneTimeWorkRequest（无限制）进行严格测试后，行为如下：
- 任务管理器关闭：
- 工作继续（稍后）
- 重启设备（工作运行）：
- 重启完成后继续工作
- “强行停止”应用信息：
- 工作停止，只有在应用程序再次启动时才会继续
- 重启设备（工作被“强制停止”）：
- 应用程序再次启动后工作才会继续
您可以在 dontkillmyapp.com. It seems the Android team also acknowledges this issue and added a test for this into their CTS test for Android Q. source
上找到不同 OEM 行为的完整列表