Android开发学习笔记——Jetpack之WorkManager

WorkManager

概述

WorkManager是Jetpack中提供用于处理后台任务的一个库，使我们可以轻松调度那些即使在退出应用或重启设备时仍应运行的可延期异步任务。在实际的Android开发过程中，如果我们想要处理后台任务，我们可能会想到使用Service、AlarmManager等技术，实际上实现后台任务，Android系统提供了众多的相关API供我们使用，如下图：

那么我们应该如果合理选择相关技术实现呢？我们为什么需要使用WorkManager呢？对此，谷歌给出了如下解释：

上述英文，大致就是描述了对于Android用户而言，电池的电量消耗是他们关注的一个重点，而如何处理延迟后台任务需求对于App电量消耗有着很大的影响，因此谷歌提供了一个统一的后台任务延迟处理方法——WorkManager。而从2020.11.1开始，谷歌将开始围绕WorkManager来统一Android系统上的后台任务延迟处理需求。并且GCMNetworkManager将会被弃用。
那么WorkManager有什么优势呢？为什么要选择WorkManager呢？谷歌做出如下解释：

大致可以翻译如下：
WorkManager的API集成了FJD和GcmNetworkManager相关技术的特性，考虑到了延长电池寿命的问题，提供了一致的任务调度服务，并且向后兼容到API14。例如，如果你的app需要向服务器发送日志文件，此时等待设备充电并连接到WiFi再执行相关后台发送日志任务会更有效。在这种情况下，WorkManager将确保在满足给定的约束(充电和连接WiFi)时执行同步。此外，它不需要Google play服务。
除此之外，WorkManager还有以下优势：

• 生命周期长，在app更新和设备重启后仍然能够持久化工作
• 提供了一次性和周期性执行后台任务
• 有效监控和关联后台任务
• 可以将不同的后台任务链式一起执行

基本使用

首先，我们需要认识几个类，WorkManager的使用主要就依靠以下几个核心类：

• Worker：后台任务的真正执行者，是一个抽象类，需要继承它实现doWork方法，实现要执行的后台任务；
• WorkRequest：指定让哪个 Woker 执行任务，指定执行的环境，执行的顺序等。
  要使用它的子类 OneTimeWorkRequest 或 PeriodicWorkRequest；
• WorkManager：管理任务请求和任务队列，单例对象，发起的 WorkRequest 会进入它的任务队列；
• WorkStatus：包含有任务的状态和任务的信息，以 LiveData 的形式提供给观察者。

使用WorkManager主要包含以下几个步骤：

1. 添加相关依赖
2. 继承Work类，自定义Work类，编写相关后台任务实现
3. 创建WorkRequest对象，指定相关环境约束，即后台任务的执行条件
4. 将WorkRequest对象添加到WorkManager任务队列中

接下来，我们就从这几个步骤来学习下WorkManager的相关使用。
首先，我们添加相关依赖，如下：

def work_version = "2.4.0"
// WorkManager
// (Java only)
implementation "androidx.work:work-runtime:$work_version"
// Kotlin + coroutines
implementation "androidx.work:work-runtime-ktx:$work_version"
// optional - RxJava2 support
implementation "androidx.work:work-rxjava2:$work_version"
// optional - GCMNetworkManager support
implementation "androidx.work:work-gcm:$work_version"
// optional - Test helpers
androidTestImplementation "androidx.work:work-testing:$work_version"

然后，我们继承Worker，实现doWork方法，我们可以在doWork中执行相关后台任务，在实际开发中，我们所需要执行的后台任务，就在doWork中实现，如上述的上传日志文件，就是在doWork方法中调用相关网络接口上传的。如下：

class TestWork(context: Context, workerParams: WorkerParameters) : Worker(context, workerParams){
   

    override fun doWork(): Result {
   
        //执行后台任务
        Log.e("test", "执行后台任务")
        //返回任务执行状态
        return Result.success()
    }

}

其中，从 doWork() 返回的 Result 会通知 WorkManager 服务工作是否成功，以及工作失败时是否应重试工作。如下：

• Result.success()：任务成功完成。
• Result.failure()：任务失败。
• Result.retry()：任务失败，应根据其重试政策在其他时间尝试。

Worker 定义工作单元，WorkRequest（及其子类）则定义工作运行方式和时间。定义了Worker后，我们需要创建一个WorkRequest对象，来执行后台任务请求。不过WorkRequest本身是一个抽象类，WorkManager为我们提供了其两个子类OneTimeWorkRequest和PeriodicWorkRequest。其中OneTimeWorkRequest表示任务只执行一次而PeriodicWorkRequest表示任务周期性执行。如下：

//创建WorkRequest对象
val request = OneTimeWorkRequest.from(TestWork::class.java)

最后，需要使用 enqueue() 方法将 WorkRequest 提交到 WorkManager，WorkManager 服务进行调度。如下：

//将WorkRequest对象加入到WorkManager调度队列中，等待执行
WorkManager.getInstance().enqueue(request)

然后，WorkManager就会执行Worker中的后台任务。运行如下：

但是，我们需要注意，实际上执行Worker的确切时间取决于 WorkRequest 中使用的约束和系统优化方式。WorkManager 经过设计，能够在满足这些约束的情况下提供最佳行为。

Worker的调度

在上述小节中，我们说过Worker 定义工作单元，WorkRequest（及其子类）则定义工作运行方式和时间。对于如何调度后台任务的执行，WorkManager 提供了很大的灵活性。而如何调度主要就是依靠WorkerRquest来设置的。WorkRequest 对象包含 WorkManager 调度和运行工作所需的所有信息。其中包括运行工作必须满足的约束、调度信息（例如延迟或重复间隔）、重试配置，并且可能包含输入数据（如果工作需要）。

调度一次性任务和定期任务

我们提到过，WorkRequest是一个抽象类，而WorkManager为我们提供了其两个子类，其中OneTimeWorkRequest表示任务只执行一次而PeriodicWorkRequest表示任务周期性执行。

调度一次性任务

OneTimeWorkRequest的使用相对简单，对于无需，其它配置的Worker，我们可以直接使用from方法创建对象，如下：

val request = OneTimeWorkRequest.from(TestWork::class.java)

而对于更加复杂的，可能需要配置更多调度信息的，我们可以使用其构造器，如设置输入数据，如下：

val request = OneTimeWorkRequest.Builder(TestWork::