Android 架构组件之 WorkManager

setBackoffCriteria()方法可以设置在任务失败时的重试策略，可以设置重新调度需要等待的时间,配合着策略(框架给出了线性和指数两种方式 backoffPolicy)使用，默认开始30s，逐渐增加最多5小时。

3. 使用 WorkManager 的 enqueue()方法，将任务添加到队列中，

WorkManager.getInstance(context).enqueue(uploadWorkRequest)

至此完成了 WorkManager 上传图片的简单示例，即使应用退出或者设备重启，只要在满足网络的条件下，系统会在将来某个时刻完成上传图片的任务。

先来看看 WorkManager 由哪些类组成。

按照惯例，先给出 WorkManager 相关的一张类图（基于work-runtime-ktx:2.2.0），在类图中根据职责的不同，进行了不同颜色的标注，绿色的 WorkManager 负责后台任务的调度；粉色的 Worker 及 WorkRequest 指代具体的后台任务，黄色的 Constrains 等主要是与后台任务，或者任务调度的参数配置及状态信息相关。下面逐一介绍：

• Worker 类是一个抽象类，我们需要继承 Worker 类，并实现 doWork()方法，在 doWork()方法中实现我们需要在后台执行的业务逻辑，我们可以将业务封装在多个 Woker 的实现类中。

• WorkRequest 代表一个单独的后台任务。WorkRequest 类也是一个抽象类，我们通常会直接使用它的两个子类，oneTimeWorkRequest 和 PeriodicWorkRequest。

• WorkRequest 还有一个内部类 WorkRequest.Builder，OneTimeWorkRequest.Builder 和 PeriodicWorkRequest.Builder都是 WorkRequest.Builder 的子类，Builder 使用的是创建者模式，我们通过 Builder 实例来创建具体的 WorkRequest 对象。

• WorkRequest 可以指定那个 Worker 来执行任务。每一个 WorkRequest 实例都会生成唯一的id，可以通过 id 取消任务，或者获取任务的状态信息等。

• Constraints 类用来设定执行任务的条件，比如设备空闲时、充电时、电量充足时等等，通过 WorkRequest 的 setConstraints() 方法将 Constraints 对象传入。

• WorkInfo 用来记录任务信息，WorkInfo 有一个内部枚举State，用来保存任务的状态，一个后台任务有以下六种状态、分别是 ENQUEUED、RUNNING、SUCCEEDED、FAILED、BLOCKED 及 CANCELLED。

• WorkInfo 除了记录任务的状态信息，还记录着任务的 id，tag 等，如果后台任务有输出的数据，也通过 WorkInfo 的成员变量 Data 对象得到。

• 如果后台任务需要接收一些输入的参数数据，可以通过 Data 对象，Data.Builder 针对不同数据类型封装了一系列 putXXX()方法。后台任务执行后返回的结果，通过 Data 对象封装的一系列 getXXX()方法获取。

• WorkContinuation，很多 WorkManager 的高级用法都与这个类有关，比如建立任务链等，后面在 WorkManager 的高级用法中详细介绍。

• WorkManager，后台任务的调度器，它负责将我们创建好的 WorkRequest 对象添加到队列中，根据我们设定的约束条件(Constraints对象)，并且会综合考虑设备资源的使用情况，进行任务的调度。

前面提到 WorkManager 保证任务能够执行到，即使应用关闭或设备重启。再补充一点，WorkManager 保证后台任务运行在**主线程之外的线程。**我们分析一下 WorkManager 是如何做到的。

先给出一张原理图：

我们逐一分析一下：

• Internal TaskExecutor， 一个单线程的线程池，用来处理后台任务的入队，并将 WorkRequest 信息保存到数据库中。当 WorkRequest 的触发条件满足时，从数据库中取出，并告诉 WorkFactory 创建 Worker 实例。

• WorkManager database，WorkManager 会将后台任务保存到本地的数据库中，这也说明了为什么应用退出，设备重启，WorkManager 都能保证后台任务会被执行。在数据库中会存储后台任务的状态信息，输入输出数据，运行时的触发条件等等。

• WorkerFactory，用来创建具体的 Worker 实例。

• Default Executor，WorkManager 默认将后台任务运行在 Default Executor 线程池中，Default Executor 会调用 Worker 实例的 doWork() 方法，这也说明了 WorkManager 默认的后台任务运行在非主线程。

我们再来看一下 WorkRequest 有哪些状态信息：

通常 WorkRequest 有以上 6 中状态信息，它们之间的转换关系：

• ENQUEUED，当 WorkRequest 被添加到队列，并且处在任务链的下一个任务，等待触发条件被满足。

• RUNNING，在这种状态时，任务正在被执行，即 Worker 中的 doWork() 方法正在执行。在这种状态时，可以通过调用 Result.retry()方法，任务会继续回到 ENQUEUED 状态。

• SUCCEEDED，在这种状态时，任务已经执行完，对于周期性的任务，没有这一状态，而是直接进入 ENQUEUED 状态，等待触发条件满足，再次执行。

• FAILED，在这种状态时，任务在失败的状态下，已经执行完，任务不会再被执行。

• BLOCKED，WorkRequest 的触发条件不满足，并且也不是任务链中下一个要执行的任务。

• CANCELLED，当任务被取消时，会处在该状态，被取消的任务不会被执行，任务处在 ENQUEUED、RUNNING、BLOCKED 时都可以被取消，进入 CANCELLED 状态。

分析完 WorkManager 的原理，再来看一下 WorkManager 的一些高级用法。

在介绍 WorkManager 类图时，提到了 WorkContinuation 类，这个类主要用来将后台任务组装成任务链。需要指出的是，任务链只适合一次性任务 OneTimeWorkRequest，对于周期性任务 PeriodicWorkRequest 不适用；任务链中的某个任务的状态是 FAILURE，则整条任务链结束。

对于上面提到的上传图片的案例，如果现在要同时选择三张图片，进行压缩，上传。通过任务链的方式，可以用以下的方式：

WorkManager.getInstance()
    .beginWith(Arrays.asList(
 filterImageOneWorkRequest, 
 filterImageTwoWorkRequest, 
 filterImageThreeWorkRequest))
    .then(compressWorkRequest)
    .then(uploadWorkRequest)
    .enqueue()

WorkContinuation left = workManager.beginWith(A).then(B);
WorkContinuation right = workManager.beginWith(C).then(D);
WorkContinuation final = WorkContinuation.combine(Arrays.asList(left, right)).then(E);
final.enqueue();

// In your UI (activity, fragment, etc)
WorkManager.getInstance().getWorkInfoByIdLiveData(uploadWorkRequest.id)
 .observe(lifecycleOwner, Observer { workInfo ->
     // Check if the current work's state is "successfully finished"
     if (workInfo != null && workInfo.state == WorkInfo.State.SUCCEEDED) {
  displayImage(workInfo.outputData.getString(KEY_IMAGE_URI))
     }
 })