Android Jetpack - 使用 WorkManager 管理后台任务

code小生,一个专注 Android 领域的技术分享平台

作者：SouthernBox
地址：https://www.jianshu.com/p/e495ee6e84de
声明：本文来自 SouthernBox 投稿,转发等请联系原作者授权

作为 Android Jetpack 中的新组件，WorkManager 负责用来管理后台任务，它和一个异步任务以及 Service 有什么区别呢？看完你就知道了。

相关类

我们先来看看 WorkManager 相关的几个类：

• Worker
  任务的执行者，是一个抽象类，需要继承它实现要执行的任务。

• WorkRequest
  指定让哪个 Woker 执行任务，指定执行的环境，执行的顺序等。
  要使用它的子类 OneTimeWorkRequest 或 PeriodicWorkRequest。

• WorkManager
  管理任务请求和任务队列，发起的 WorkRequest 会进入它的任务队列。

• WorkStatus
  包含有任务的状态和任务的信息，以 LiveData 的形式提供给观察者。

接下来是 WorkManager 的简单使用。

使用

WorkManager 的实现包括以下几个步骤。

依赖
在 build.gradle 添加如下依赖：

implementation "android.arch.work:work-runtime:$work_version"
implementation "android.arch.work:work-firebase:$work_version"

定义 Worker
我们定义 MainWorker 继承 Worker，发现需要重写 doWork 方法，并且需要返回任务的状态 WorkerResult：

class MainWorker : Worker() {
    override fun doWork(): WorkerResult {
        // 要执行的任务
        return WorkerResult.SUCCESS
    }
}

我们暂时什么都不做，直接返回任务执行完成 WorkerResult.SUCCESS。

定义 WorkRequest
在 MainActivity 中定义 WorkRequest：

val request = OneTimeWorkRequest.Builder(MainWorker::class.java).build()
OneTimeWorkRequest 意味着这个任务只需执行一遍。

加入任务队列
要让任务执行，需要将 WorkRequest 加入任务队列：

WorkManager.getInstance().enqueue(request)

现在加入任务队列后，任务会马上得到执行。但需要注意的是，这句代码的作用是将任务加入任务队列，而不是执行任务，至于区别后面会讲到。

数据交互

后台任务少不了数据的交互，我们看一下数据是如何传入传出的。

input
先是在 Activity 传数据给 Worker ，我们传一个格式化过的时间过去：

val dateFormat = SimpleDateFormat("hh:mm:ss", Locale.getDefault())

val data = Data.Builder()
        .putString("time", dateFormat.format(Date()))
        .build()

val request = OneTimeWorkRequest.Builder(DemoWorker::class.java)
        .setInputData(data)
        .build()

使用 WorkRequest 的 setInputData 方法传递 Data，Data 的使用和 Bundle 差不多。

在 Worker 中，从 inputData 可以取到数据，这里取到后简单打印一下：

class MainWorker : Worker() {
    override fun doWork(): WorkerResult {
        Log.d("WorkManager", inputData.getString("time",""))
        return WorkerResult.SUCCESS
    }
}

output
当任务处理完了，需要将处理结果返回。传入的是 inputData，传出就是 outputData：

class MainWorker : Worker() {
    override fun doWork(): WorkerResult {
        Log.d("MainWorker", inputData.getString("time",""))
        outputData = Data.Builder()
            .putString("name", "SouthernBox")
            .build()
        return WorkerResult.SUCCESS
    }
}

每一个 WorkRequest 都会有一个 id，通过 id 可以获取到对应任务的 WorkStatus，并且是以 LiveData 形式提供的：

WorkManager.getInstance()
        .getStatusById(request.id)
        .observe(this, Observer { workStatus ->
            if (workStatus != null && workStatus.state.isFinished) {
                Log.d("MainActivity", workStatus.outputData.getString("name", ""))
            }
        })

如果需要取消一个在队列中的任务，也是通过 id 实现的：

WorkManager.getInstance().cancelWorkById(request.id)

这样我们就完成了一个最简单的 WorkManager，执行一下就可以看到打印的结果了。

特性

到目前为止都是基本操作，和一个普通的异步任务没有太大区别，接下来我们看看它不一样的一些地方。

环境约束
WorkManager 允许我们指定任务执行的环境，比如网络已连接、电量充足时等，在满足条件的情况下任务才会执行。

可指定的条件及设置方法如下：

val constraints = Constraints.Builder()
        .setRequiredNetworkType(NetworkType.CONNECTED)  // 网络状态
        .setRequiresBatteryNotLow(true)                 // 不在电量不足时执行
        .setRequiresCharging(true)                      // 在充电时执行
        .setRequiresStorageNotLow(true)                 // 不在存储容量不足时执行
        .setRequiresDeviceIdle(true)                    // 在待机状态下执行，需要 API 23
        .build()

val request = OneTimeWorkRequest.Builder(MainWorker::class.java)
        .setConstraints(constraints)
        .build()

这个很好理解，除了网络状态，其他设置项都是传入一个布尔值，网络状态可选值如下:

我们试一下效果，添加一个需要联网的条件，Activity 代码如下:

class MainActivity : AppCompatActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        val constraints = Constraints.Builder()
                .setRequiredNetworkType(NetworkType.CONNECTED)
                .build()

        val dateFormat = SimpleDateFormat("hh:mm:ss", Locale.getDefault())
        val data = Data.Builder()
                .putString("date", dateFormat.format(Date()))
                .build()

        val request = OneTimeWorkRequest
                .Builder(MainWorker::class.java)
                .setConstraints(constraints)
                .setInputData(data)
                .build()

        WorkManager.getInstance().enqueue(request)

        WorkManager.getInstance()
                .getStatusById(request.id)
                .observe(this, Observer { workStatus ->
                    if (workStatus != null && workStatus.state.isFinished) {
                        Log.d("MainActivity",
                                workStatus.outputData.getString("name", ""))
                    }
                })

    }
}

打开应用之前，先把网络关闭，打开后发现 Worker 并没有打印时间，这时候再把网连上，就会看到打印出时间了。

这也是为什么前面说 WorkManager.getInstance().enqueue(request) 是将任务加入任务队列，并不代表马上执行任务，因为任务可能需要等到满足环境条件的情况才会执行。

强大的生命力

还是一样的代码，我们来做点不一样的操作：

1. 断网后运行

2. 将进程杀掉

3. 联网

4. 再次运行

不出意外的话，这时候你会看到有两个时间的打印，而且两个时间还不一样，这是为什么呢？

第一个时间是第一次运行后，加入了任务队列，但还没有执行的任务。第二个则是本次执行的任务打印的。这说明了，就算进程被杀掉，任务还是存在，甚至如果重启手机，任务依然会在满足条件的情况下得到执行。

这是 WorkManager 的另一个特点，一旦发起一个任务，任务是可以保证一定会被执行的，就算退出应用，甚至重启手机都阻止不了他。但可能由于添加了环境约束等原因，它执行的时间是不确定的。

当应用正在运行时，它会在当前的进程中启用一个子线程执行。应用没有运行的情况下启用，它则会自己选择一种合适的方式在后台运行。具体是什么方式和 Android 的版本和依赖环境有关：

定时任务

前面说了 OneTimeWorkRequest 是指任务只需要执行一遍，而 PeriodicWorkRequest 则可以发起一个多次执行的定时任务：

val request = PeriodicWorkRequest
        .Builder(MainWorker::class.java, 15, TimeUnit.MINUTES)
        .setConstraints(constraints)
        .setInputData(data)
        .build()

这样，发起的任务就会每隔 15 分钟执行一次。除了需要传入间隔时间，使用起来跟 OneTimeWorkRequest 是没有区别的。

你可能会想更频繁的去执行一个任务，比如几秒钟执行一遍，但很遗憾，最小时间间隔就是 15 分钟，看一下源码就知道了。

还有需要注意的是，定时任务并不是说经过指定时间后它就马上执行，而是经过这一段时间后，等到满足约束条件等情况时，它才执行。

任务链

WorkManager 允许我们按照一定的顺序执行任务，比如我想 A、B、C 三个任务按先后顺序执行：

可以这样写，把它们组成一条任务链：

WorkManager.getInstance()
        .beginWith(workA)
        .then(workB)
        .then(workC)
        .enqueue()

这样的话，上一个任务的 outputData 会成为下一个任务的 inputData。

再更复杂一点，我想 A 和 B 同时执行，它们都执行完之后，再执行 C：

也是可以实现的：

WorkManager.getInstance()
        .beginWith(workA,workB)
        .then(workC)
        .enqueue()

再更更复杂一点，如果我想这样：

这样就需要先把 A、B 和 C、D 分别组成一条任务链，再进行联结：

val chain1 = WorkManager.getInstance()
        .beginWith(workA)
        .then(workB)
val chain2 = WorkManager.getInstance()
        .beginWith(workC)
        .then(workD)
val chain3 = WorkContinuation
        .combine(chain1, chain2)
        .then(workE)
chain3.enqueue()

再更更更复杂一点，如果我把定时任务放进去会怎样？不好意思，链式任务只支持 OneTimeWorkRequest。

使用任务链，我们可以将各种任务进行模块化。同样的，任务链不保证每个任务执行的时间，但是保证它们执行的先后顺序。

任务唯一性

很多情况下，我们希望在任务队列里，同一个任务只存在一个，避免任务的重复执行，这时候可以用到 beginUniqueWork 这个方法：

WorkManager.getInstance()
        .beginUniqueWork("unique", ExistingWorkPolicy.REPLACE, request)
        .enqueue()

需要传入一个任务的标签，和重复任务的执行方式，可取值如下：

但这种方式也是只支持 OneTimeWorkRequest。如果是 PeriodicWorkRequest，我想到的办法是每次执行之前，根据标签去取消已有的任务。

以上，就是本文对 WorkManager 的简单介绍和用法讲解。

保活?

这里引入一个思考，既然 WorkManager 的生命力这么强，还可以实现定时任务，那能不能让我们的应用生命力也这么强？换句话说，能不能用它来保活?

要是上面有细看的话，你应该已经发现这几点了：

• 定时任务有最小间隔时间的限制，是 15 分钟

• 只有程序运行时，任务才会得到执行

• 无法拉起 Activity

总之，用 WorkManager 保活是不可能了，这辈子都不可能保活了。

使用场景？

很明显，WorkManager 区别于异步任务，它更像是一个 Service。基本上，WorkManager 能做的，Service 也能做，我并没有想到有什么情况是非用 WorkManger 不可的。

但反观 Service，泛滥的 Service 后台任务可能是引起 Android 系统卡顿的主要原因，这几年 Google 也对 Service 也做了一些限制。

对 Service 的限制

Android 6.0 (API 23)

休眠模式：在关闭手机屏幕后，系统会禁止应用的网络请求等功能。

Android 8.0（API 26）

在某些不被允许的情况下，调用 startService 会抛异常。

但目前很多 APP 的 target API 还在 23 以下，因为不想处理运行时权限，更别说 API 26 了。基于此，2017 年年底，谷歌采取了少有的强硬措施。

对 Target API 的要求

2018 年 8 月起

所有新开发的应用，Target API 必须是 26 或以上。

2018 年 11 月起

所有已发布的应用，Target API 必须更新到 26 或以上。

2019 年起

每次发布新版本后，所有应用都必须在一年内将 Target API 更新到最新版本

虽然这些措施对国内的环境没有办法造成直接影响，但这也会成为一种发展指导方向。

更合理的后台任务管理

说了这么多，我想表达的是，在不久的将来，在某些情况下，Service 已经没卵用了！

而 WorkManager 作为一个更合理的后台任务管理库，在这种情况下就是一个更好的选择了。