WorkManager — 什么是它，API和任务计划

WorkManager如何工作？

WorkManager的架构围绕三个基本类构建：Worker、WorkRequest和WorkManager。Worker包含任务逻辑，WorkRequest描述执行参数，WorkManager管理队列和计划。该库使用内部Room数据库来存储所有任务的状态。

Worker和WorkRequest

Worker — 是一个抽象类，只有一个方法doWork，在后台线程中调用。该方法返回ListenableWorker.Result — SUCCESS、FAILURE或RETRY。WorkRequest将Worker与参数关联：超时、标签、初始延迟和约束条件。

class SyncWorker(
    context: Context,
    params: WorkerParameters
) : Worker(context, params) {

    override fun doWork(): Result {
        return try {
            val api = RetrofitClient.api
            val response = api.syncData()
            Result.success()
        } catch (e: Exception) {
            Result.retry()
        }
    }
}

通过WorkManager进行计划

WorkManager统一计划任务，与Android版本无关。调用enqueue时，库将任务保存在Room中，评估当前条件，并选择最佳启动时间。在底层，可以使用JobScheduler、AlarmManager或自己的调度程序——开发人员无需关心这些。

val syncRequest = OneTimeWorkRequestBuilder<SyncWorker>()
    .setInitialDelay(15, TimeUnit.MINUTES)
    .addTag("sync")
    .build()

WorkManager.getInstance(context)
    .enqueue(syncRequest)

WorkRequest的类型

WorkManager支持两种类型的执行请求：单次和周期性。类型的选择取决于场景：任务应该执行一次还是以特定间隔重复执行。

OneTimeWorkRequest

OneTimeWorkRequest用于应执行一次的任务。这可以是发送日志、授权后的数据同步、首次启动时的配置加载。延迟通过setInitialDelay设置，约束条件通过setConstraints设置。

PeriodicWorkRequest

PeriodicWorkRequest适用于重复性任务，最小间隔为15分钟。该库保证执行之间的间隔不会小于指定的间隔，但由于设备限制可能会更长。对于频率低于15分钟的任务，请使用Foreground Service中的Handler或Timer。

设置约束条件和任务链

WorkManager中的约束条件（constraints）允许设置任务启动的条件：网络连接（NetworkType）、电池电量（batteryNotLow）、存储状态（StorageNotLow）和空闲模式（DeviceIdle）。在满足所有约束条件之前，任务不会启动。

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

val request = OneTimeWorkRequestBuilder<ImageUploadWorker>()
    .setConstraints(constraints)
    .build()

链（chaining）允许组织任务的顺序或并行执行。beginWith启动一个链，then添加下一个Worker，它将在前一个成功完成后执行。对于并行执行，使用workManager.enqueue(listOf(request1, request2))。

WorkManager.getInstance(context)
    .beginWith(compressWorker)
    .then(uploadWorker)
    .then(cleanupWorker)
    .enqueue()
    // compress -> upload -> cleanup 顺序执行

从JobScheduler迁移到WorkManager

JobScheduler在Android 5（API 21）中被引入，作为计划后台任务的系统服务。WorkManager作为替代品出现，提供跨平台API、自动迁移和额外功能：链、执行保证、标签、通过LiveData进行状态监控。

在从JobScheduler迁移到WorkManager时，需要将JobService转换为Worker，将JobInfo替换为WorkRequest，将Context.getSystemService替换为WorkManager API。WorkManager自动解决兼容性问题，并比手动实现JobScheduler更正确地处理Doze Mode。迁移步骤：1）创建Worker类，2）使用相同条件构建WorkRequest，3）从代码和清单中删除JobService和JobInfo。

用于唯一任务的UniqueWork

WorkManager通过ExistingWorkPolicy支持唯一任务的概念。如果具有指定名称的任务已存在，策略决定行为：KEEP（不创建新任务）、REPLACE（替换现有任务）、APPEND（添加到链的末尾）和APPEND_OR_REPLACE。UniqueWorkRequest适用于不应重复的任务：数据库同步、配置加载、发送分析数据包。

WorkManager.getInstance(context)
    .enqueueUniqueWork(
        "sync_data",
        ExistingWorkPolicy.KEEP,
        syncRequest
    )

处理进度和中间结果

CoroutineWorker支持setProgress机制，允许传递任务的中间结果。这对于长时间操作很有用：加载大文件、批量处理图像、数据库迁移。UI可以通过getWorkInfosByTagLiveData订阅更新，并实时显示进度。还可以使用ForegroundInfo方法将Worker作为带有通知的Foreground Service启动，如果任务需要对用户可见的话。

class ProgressWorker(
    context: Context,
    params: WorkerParameters
) : CoroutineWorker(context, params) {

    override suspend fun doWork(): Result {
        val total = 100
        for (i in 1..total) {
            setProgress(
                workDataOf("progress" to i)
            )
        }
        return Result.success()
    }
}

用于数据传输的InputData和OutputData

WorkManager支持通过InputData和OutputData在Worker之间传输数据。InputData在构建WorkRequest时通过Data.Builder创建，并通过inputData传递给Worker。执行后，Worker通过workDataOf或Data.Builder创建OutputData，并与Result.success(outputData)一起返回。链中的下一个Worker接收前一个的输出数据作为其输入数据。数据以键值格式存储，支持基本类型：String、Int、Long、Boolean、Double。Data的最大大小为10 KB。

在实践中，许多项目使用WorkManager作为唯一的后台任务调度程序。Google建议将所有现有的JobService迁移到WorkManager，特别是在支持Android 4.4（API 19）及更低版本的应用程序中，这些版本中JobScheduler不可用，而WorkManager通过AlarmManager和BroadcastReceiver使用备用机制。对于测试，WorkManager提供了TestListenableWorkerBuilder和TestWorkerBuilder，允许在JUnit测试中测试Worker，而无需实际的调度程序。