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 минут используйте Handler или Timer в Foreground Service.

Настройка ограничений и цепочки задач

Ограничения (constraints) в WorkManager позволяют задать условия, при которых задача может быть запущена: подключение к сети (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 автоматически решает проблемы совместимости и обрабатывает Doze Mode корректнее, чем ручная имплементация JobScheduler. Шаги миграции: 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 поддерживает передачу данных между Worker-ами через InputData и OutputData. InputData создаётся на этапе построения WorkRequest через Data.Builder и передаётся в Worker через inputData. После выполнения Worker формирует OutputData через workDataOf или Data.Builder и возвращает вместе с Result.success(outputData). Следующий Worker в цепочке получает outputData предыдущего как свой inputData. Данные хранятся в формате ключ-значение с поддержкой базовых типов: String, Int, Long, Boolean, Double. Максимальный размер Data — 10 КБ.

На практике многие проекты используют WorkManager как единственный планировщик фоновых задач. Google рекомендует мигрировать все существующие JobService на WorkManager, особенно в приложениях, поддерживающих Android 4.4 (API 19) и ниже, где JobScheduler недоступен, а WorkManager использует резервный механизм через AlarmManager и BroadcastReceiver. Для тестирования WorkManager предоставляет TestListenableWorkerBuilder и TestWorkerBuilder, которые позволяют тестировать Worker-ов в JUnit-тестах без реального планировщика.