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.

Налаштування обмежень і ланцюжки завдань

Обмеження в WorkManager дозволяють задати умови, при яких завдання може бути запущено: підключення до мережі (NetworkType), рівень заряду батареї (batteryNotLow), стан сховища (StorageNotLow) і режим очікування (DeviceIdle). Завдання не запуститься, поки всі обмеження не будуть виконані.

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

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

Ланцюжки дозволяють організувати послідовне або паралельне виконання завдань. 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-тестах без реального планувальника.