Почему WorkManager рекомендуют использовать вместо сервисов
Что проверяют
Понимаете ли вы, от чего WorkManager защищает. Ответ «он удобнее» ничего не стоит: спрашивают про системные ограничения на фоновую работу, из-за которых обычный сервис просто не запустится, и про то, где WorkManager наоборот не подходит.
Как отвечать
Начиная с Android 8 приложение в фоне не может поднять обычный фоновый сервис, а startForegroundService обязан за несколько секунд показать уведомление, иначе система убьёт процесс. Сверху ложатся Doze и ограничения для неактивных приложений. Поэтому «просто сервис» это ненадёжный способ доделать работу.
WorkManager закрывает ровно это. Очередь хранится в собственной базе, задача переживает смерть процесса и перезагрузку устройства, под капотом выбирается JobScheduler или более старый механизм в зависимости от версии системы. Сверху идёт то, что руками пишется долго: условия запуска, повторы с растущей задержкой, цепочки и уникальные работы.
val work = OneTimeWorkRequestBuilder<UploadWorker>()
.setConstraints(Constraints.Builder().setRequiredNetworkType(NetworkType.CONNECTED).build())
.build()
WorkManager.getInstance(context).enqueueUniqueWork("upload", ExistingWorkPolicy.KEEP, work)Обязательно назовите границы применимости. Для того, что идёт прямо сейчас и видно пользователю (проигрывание, навигация, запись), нужен foreground service с типом. Для короткой работы внутри живого экрана достаточно корутины в viewModelScope. WorkManager это отложенная гарантированная работа, а не универсальная замена всему.
Где спотыкаются
Обещают мгновенность. Система вправе отложить запуск, у периодической работы минимальный интервал пятнадцать минут, и точное время не гарантируется вовсе.
Пишут неидемпотентный Worker. Он перезапускается по Result.retry, после перезагрузки, после смерти процесса, и неаккуратная отправка уходит дважды. Нужен ключ операции и проверка на стороне сервера.
Трактуют гарантию слишком широко. Принудительная остановка приложения пользователем и агрессивные оболочки производителей работу отменяют, поэтому критичное дублируется серверной логикой, а не надеждой на планировщик.