软件开发  APP  程序员

前言

一般情况下，我们大部分的操作都是在app打开的时候进行的，但是在某些情况下，即使app关闭了，我们也可能需要执行必要的动作，或者会采取一个动作，而不是让用户等待加载，我们可以在后台执行此操作并通知用户结果。针对这些日常工作中经常出现但是又非常棘手的情况，学会使用workManager将会大家轻松解决这些问题。

WorkManager 是一个 API，可供大家轻松调度那些即使在退出应用或重启设备后仍应运行的可靠异步任务。WorkManager API 是一个适合用来替换所有先前的 Android 后台调度 API（包括 FirebaseJobDispatcher、GcmNetworkManager 和 JobScheduler等）的组件，本人也建议您这样做。WorkManager 在其现代、一致的 API 中整合了其前身的功能，该 API 支持 14及以上，在开发时考虑到了对电池续航等影响。

何时使用 WorkManager

WorkManager 处理需要在满足各种约束时运行的后台工作，而不管应用程序进程是否处于活动状态。后台工作可以在应用程序在后台、应用程序在前台或应用程序在前台启动但转到后台时启动。无论应用程序在做什么，后台工作都应该继续执行，或者如果 Android 终止其进程则重新启动。

关于 WorkManager 的一个常见混淆是它用于需要在“后台”线程中运行但不需要在进程死亡后继续存在的任务。不是这种情况。对于此用例，还有其他解决方案，例如 Kotlin 的协程、线程池或 RxJava 等库。

针对许多不同的情况都需要运行后台工作，因此运行后台工作有不同的解决方案。

使用的充分不必要条件？

在 WorkManager 的情况下，最好用于必须完成且可延迟的后台工作。

首先，问问自己：

• 这个任务需要完成吗？

如果应用被用户关闭，是否还需要完成任务？一个例子是带有远程同步的笔记应用程序；写完笔记后，如果希望该应用程序将笔记与后端服务器同步。即使切换到另一个应用程序并且操作系统需要关闭该应用程序以回收一些内存，也会发生这种情况。就算重新启动设备，它也应该发生。可以通过WorkManager 来确保任务完成。

• 这个任务可以延期吗？

我们可以在以后运行的任务，或者只运行是有用的权利呢？如果任务可以稍后运行，那么它是可延迟的。看下前面的示例，立即上传即时笔记很理想，但是由于网络限制等原因,不可能和编辑同步进行，不过这也不是什么大问题，毕竟主流应用的用户习惯都是这样。而正因为WorkManager 尊重操作系统背景限制，并尝试以省电的方式运行您的工作， 因此这也是选择WorkManager来做延时任务的最佳选择之一。

WorkerManager的工作流程

在后台，WorkManager 根据以下条件使用底层作业来调度服务：

🎃Work Request

我们可以创建两种类型的工作请求。

OneTimeWorkRequest → 当我们只处理一次

PeriodicWorkRequest → 当我们以一定的时间间隔来做

🎃 Worker

Coroutinework是要暂停一个DoWork的通过在操作过程中进行必要的处理函数重载这个函数成功 失败条件，我们可以处理。

🌀工作器初始化简易过程。

我们指定它将使用 OneTimeWorkRequest 触发一次，并将我们的 Worker 类作为参数。我们> 运行使用 WorkManager 创建的 workRequest。

doWork函数将在Worker 被触发时运行。

📝向 Worker 发送数据

在构建WorkRequest之前，我们可以设置很多值，其中之一便是setInputData()参数，足以发送属于androidx.work的Data。

在 Worker类中，我们可以获取与inputData一起发送的值及其键。

⚠️ 限制条件

我们可以使用setConstraints()设置一些条件，以便在运行worker之前检查这些条件。

🟢 setRequiresDeviceIdle → 如果我们想让它在进入 Doze 模式时工作，我们只需要将其设置为 true。默认值为假。

🟢 setRequiresNetworkType → 我们可以设置互联网连接状态。

🟢 setRequiresBatteryNotLow → 如果电池电量不低，我们可以设置它的状态。默认值为假。

🟢 setRequiresCharging → 插入状态。默认值为假。

⏳Delay

延迟部分对于 OneTimeRequest 会起作用一次，对于临时workder也会以同样的方式起作用，但是这种延迟不会在每次触发时起作用。

🧐Worker State Observe

我们可以通过状态观察我们在Worker 中所做的过程，有不止一种方法，我们可以在它们之间进行选择。

getWorkInfosByTagLiveData —> getWorkInfosForUniqueWorkLiveData —> getWorkInfoByIdLiveData

本人更偏向使用workRequest的id进行观察，通过将数据分配给Worker中的成功和失败状态，将能够再次接收该数据并对其进行观察。

⏱️ 临时worker

它的工作方式与OneTime类似，除此之外我们需要指定作用时间。

但是！会存在一个问题，如果设备处于休眠模式，进程会被搁置；当设备被唤醒时，进程会按顺序再次处理。如果大家希望能准确对进程进行操作，则需要往清单文件中添加一下权限。

uses-permission android:name="android.permission.REQUEST_IGNORE_BATTERY_OPTIMIZATIONS"/>

官方文档 :

https://developer.android.com/topic/libraries/architecture/workmanager https://bugrayetkinn.medium.com/android-workmanager-6bc60dcd17fd https://android-developers.googleblog.com/2018/10/modern-background-execution-in-android.html