作为 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) 是将任务加入任务队列，并不代表马上执行任务，因为任务可能需要等到满足环境条件的情况才会执行。
强大的生命力
还是一样的代码，我们来做点不一样的操作：
- 断网后运行
- 将进程杀掉
- 联网
- 再次运行
不出意外的话，这时候你会看到有两个时间的打印，而且两个时间还不一样，这是为什么呢？
第一个时间是第一次运行后，加入了任务队列，但还没有执行的任务。第二个则是本次执行的任务打印的。这说明了，就算进程被杀掉，任务还是存在，甚至如果重启手机，任务依然会在满足条件的情况下得到执行。
这是 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 作为一个更合理的后台任务管理库，在这种情况下就是一个更好的选择了。
作者：NanBox
链接：https://www.jianshu.com/p/e495ee6e84de
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
