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

7,328 阅读9分钟

作为 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()

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

状态 说明
NOT_REQUIRED 没有要求
CONNECTED 网络连接
UNMETERED 连接无限流量的网络
METERED 连接按流量计费的网络
NOT_ROAMING 连接非漫游网络

我们试一下效果,添加一个需要联网的条件,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> { 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()

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

状态 说明
REPLACE 删除已有的任务,添加现有的任务
KEEP 什么都不做,不添加新任务,让已有的继续执行
APPEND 加入已有任务的任务链最末端

但这种方式也是只支持 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 作为一个更合理的后台任务管理库,在这种情况下就是一个更好的选择了。