在多进程应用中使用 WorkManager

作者 / 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 库了。