Android开发Android-JetpackAndroid开发经验谈

Android Jetpack - 使用 WorkManager

2018-06-30  本文已影响239人  NanBox

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

相关类

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

接下来是 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 的生命力这么强，还可以实现定时任务，那能不能让我们的应用生命力也这么强？换句话说，能不能用它来保活?

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

总之，用 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 作为一个更合理的后台任务管理库，在这种情况下就是一个更好的选择了。

上一篇下一篇

猜你喜欢

热点阅读