作者 / Android 开发者关系 Ben Weiss
最近发布的 WorkManager 2.5.0 更适用于在多进程环境中使用，并提供了多项稳定性改进。
因此，如果您的某款应用管理着多个进程，并需要一种稳健的方式来管理后台工作 (不再出现初始化错误 
)，那么此版本便是您的首选。
您需要对代码进行几处更改，请继续阅读以了解更多内容。
在本文末尾，我还将列出此版本 WorkManager 库中的一些其他行为变更和新增内容。
隆重推出: work-multiprocess
这一全新的多进程工件通过将作业调度统一为单个进程，从而带来性能的提升。要开始使用此工件，请将其添加到您的应用。
Implementation "androidx.work:work-multiprocess:2.5.0"
您现在可以 选择 WorkManager 用于将 WorkRequest 加入队列的指定进程，并运行其进程中调度程序。
使用 Configuration.Provider 的配置如下所示。
class MyApplication() : Application(), Configuration.Provider { override fun getWorkManagerConfiguration() =
Configuration.Builder()
.setProcessName("com.example:remote")
.build()
}
注意: 您需要传递完全限定的进程名称作为 setProcessName 的参数，该名称由您的应用包名称，后跟英文冒号和主机的进程名称组成，例如 com.example:remote。
使用 work-multiprocess 时，您需要使用 RemoteWorkManager (而非 WorkManager) 来管理您的工作请求。RemoteWorkManager 将始终使用指定的进程将您的工作加入队列。这可确保您不会在调用进程中意外初始化新的 WorkManager。进程中调度程序也会在指定的同一进程中运行。
优势
按照上述方法配置 WorkManager 并使用 RemoteWorkManager 调度作业时，您的工作会在多进程应用中得到更快速、更可靠的管理。这是因为 SQLite 争用 情况会大大减少 (因为我们不再依赖于以文件为基础的锁定)，且不再需要跨进程的作业协调，因为您的应用仅会在您指定的进程中运行单个 WorkManager 实例。
行为变更 
作业协调
之前，当 ActivityManager 无法实例化 JobService 以启动作业时，该作业将因为平台中的底层问题而被静默删除。WorkManager 现在可确保通过协调 WorkRequest 对象与作业创建 “应用” 实例时，每个 WorkRequest 都会有一个后备调度程序作业。
限制内部数据库增长
我们发现应用崩溃的原因之一是设备存储空间不足。这种情况主要发生在存储空间本来就很少的设备上。但是，当应用调度大量工作时，导致设备存储空间不足的部分原因在于 WorkManager。
默认情况下，内部的 WorkManager 数据库会将已完成作业的记录保留 7 天。而现在，这个期限已减少至 1 天，大大降低了数据库的大小。
我们缩短了缓冲区持续时间，这样您就能借助 keepResultsForAtLeast() API 控制作业应被保留的时长。
全新测试 API 
如果您将 ListenableFuture 和 WorkManager 配合使用，测试工作会变得更轻松 — TestListenableWorkerBuilder Kotlin 扩展程序现在可以接收任何类扩展 ListenableWorker，从而在测试过程中为您提供更高的灵活性。
问题修复 
除了新增的功能，此版本还包含多个错误修复，以提高 WorkManager 的稳定性、可靠性和性能。您可以在 版本说明 中查看所有更改以及修复的错误。
如何改进 WorkManager
通过 GitHub 向 WorkManager 贡献内容 
WorkManager 以及其他几个 Jetpack 库都接受通过 GitHub 贡献的内容。
Alan Viverette 撰写了一篇关于整个流程的 详尽博文。
遇到问题时请告诉我们
2.5.0 版本中修复的大部分错误都是通过 公开问题跟踪器 报告的。
创建可修复问题 的最佳方式就是创建一个我们可复现的问题。为帮助我们再现问题，建议您使用该 WorkManager 示例，或通过问题描述提供您的示例代码。
是时候行动起来，并更新您应用中使用的 WorkManager 库了。