Фоновые задачи в мобильной разработке: что это, какие бывают и как работают

Что такое фоновые задачи?

Фоновая задача — любой код, выполняющийся, когда приложение не находится на переднем плане (активный экран). Это может быть: периодическая синхронизация данных с сервером, загрузка больших файлов, обработка push-уведомлений, трекинг геолокации, обновление виджетов. Каждая платформа имеет собственные ограничения на фоновую работу: iOS более строгая (10–30 минут фонового времени), Android лояльнее, но с версии 9 ужесточает правила.

Архитектура фоновых задач строится на трёх уровнях: (1) немедленные задачи — выполняются прямо сейчас (Foreground Service); (2) отложенные задачи — выполняются при подходящих условиях (WorkManager, BGTaskScheduler); (3) периодические задачи — повторяются с заданным интервалом. Правильный выбор уровня определяет, будет ли задача выполнена вовремя и не приведёт ли к блокировке приложения магазином.

На обеих платформах Google/Apple настоятельно рекомендуют использовать декларативные API вместо прямого управления потоками в фоне. WorkManager на Android и BGTaskScheduler на iOS позволяют системе оптимально распределять фоновую работу между приложениями, группируя задачи для экономии энергии. В IT Sectr мы всегда начинаем проектирование фоновой архитектуры с анализа требований к частоте и срочности обновлений.

Фоновые задачи на iOS (Background Fetch, BGTaskScheduler)

iOS предоставляет несколько механизмов для фоновой работы. Background Fetch — периодическое обновление контента с интервалом, который определяет система (не разработчик). Приложение получает окно ~30 секунд для загрузки новых данных. Background Fetch включается через Capabilities → Background Modes → Background Fetch и реализуется в AppDelegate: application(_:performFetchWithCompletionHandler:).

BGTaskScheduler — современный API для iOS 13+, который заменяет Background Fetch. Разработчик регистрирует задачу с идентификатором, а система запускает её при подходящих условиях. BGAppRefreshTask — для коротких обновлений контента; BGProcessingTask — для длительных задач (очистка кеша, синхронизация базы данных). Задачи регистрируются при запуске приложения, а система планирует их выполнение с учётом состояния батареи, сети и активности пользователя.

Background Modes — список режимов, которые разрешают фоновую работу для конкретных сценариев: Audio (фоновое воспроизведение), Location (GPS-трекинг), VoIP (звонки через PushKit), BLE (подключение к Bluetooth-устройствам), Processing (длительные задачи через BGTaskScheduler). Каждый режим требует обоснования при ревью App Store. Использование режимов без реальной необходимости — частая причина отклонения приложения.

Significant Location Change — механизм для приложений, которым не нужна постоянная геолокация, но важно знать о значительном перемещении пользователя (более 500 метров). Система сама пробуждает приложение при смене вышки сотовой связи. Этот механизм значительно экономит батарею по сравнению с постоянным GPS-трекингом.

Фоновые задачи на Android (WorkManager, JobScheduler, Foreground Service)

Android предлагает самый богатый набор API для фоновых задач, но с версии 8.0 (API 26) правила стали строже. WorkManager — рекомендуемое решение от Google для всех типов фоновых задач. WorkManager гарантирует выполнение задачи даже после перезагрузки устройства (через BootReceiver) и поддерживает цепочки задач, наблюдаемые LiveData/Flow и обратную совместимость до API 14.

WorkManager использует Worker — базовый класс с методом doWork(). Constraints определяют условия выполнения: NetworkType.CONNECTED, BatteryNotLow, StorageNotLow. PeriodicWorkRequest — для периодических задач с минимальным интервалом 15 минут. WorkManager автоматически адаптируется к Doze Mode и App Standby, группируя задачи в окна обслуживания. Пример простого Worker:

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

    override suspend fun doWork(): Result {
        return try {
            val repository =
                Injection.provideRepository(applicationContext)
            repository.syncData()
            Result.success()
        } catch (e: Exception) {
            Result.retry()
        }
    }
}

// Запланировать задачу
val constraints = Constraints.Builder()
    .setRequiredNetworkType(NetworkType.CONNECTED)
    .build()

val syncRequest = OneTimeWorkRequestBuilder<SyncWorker>()
    .setConstraints(constraints)
    .build()

WorkManager.getInstance(context)
    .enqueue(syncRequest)

JobScheduler — более старый API (Android 5+, API 21). Планирует задачи с указанием условий (сеть, зарядка, простаивание). Ограничение: не поддерживает перезагрузку устройства (нужен BootReceiver) и не имеет наблюдаемого состояния. JobScheduler подходит для простых задач в легаси-проектах; для новых проектов следует использовать WorkManager.

Foreground Service — сервис, который пользователь видит через постоянное уведомление (ongoing notification). Используется для: воспроизведения музыки, записи GPS-трека, загрузки больших файлов. Foreground Service имеет высокий приоритет — система не убьёт его при нехватке памяти. Начиная с Android 13, требуется разрешение FOREGROUND_SERVICE_SPECIAL_USE для некоторых типов. Альтернатива — WorkManager с ForegroundServiceOption (долгие задачи).

AlarmManager — для задач, которые должны выполниться в точное время (будильник, напоминание). AlarmManager может разбудить устройство из Doze Mode (setAlarmClock). Не рекомендуется для обычной синхронизации из-за высокого энергопотребления. Для периодических задач используйте WorkManager, а AlarmManager — только когда точное время критично.

Doze Mode и App Standby

Doze Mode — режим энергосбережения Android, влияющий на выполнение фоновых задач. Введён в Android 6.0 (API 23). Когда устройство не заряжается, экран выключен и устройство неподвижно, Doze Mode запрещает сетевым запросам, откладывает JobScheduler и WakeLock. Периодически Doze открывает «окна обслуживания» (maintenance window) — короткие промежутки, когда приложения могут выполнить отложенные задачи. С версии Android 7.0 (API 24) Doze активируется при выключенном экране, а не только в полной неподвижности.

App Standby — режим, при котором неиспользуемые приложения переводятся в «ожидание». Если приложение не имеет активного уведомления и не открывалось несколько дней, оно помещается в Standby Bucket: активный (active), рабочий (working), частый (frequent), редкий (rare). Чем реже используется приложение, тем сильнее ограничения: сетевые запросы откладываются, синхронизация блокируется, JobScheduler не запускается.

WakeLock — механизм, удерживающий устройство в активном состоянии (не даёт уснуть). Используется для завершения важных операций. WakeLock нужно обязательно отпускать (release) после выполнения задачи, иначе батарея разрядится за несколько часов. WakeLock не работает в Doze Mode — система игнорирует его. Работа с WakeLock на Android 8+ требует разрещения WAKE_LOCK и правильного управления жизненным циклом.

В IT Sectr мы учитываем Doze Mode и App Standby на этапе проектирования. WorkManager автоматически обрабатывает эти режимы, но для Foreground Service нужно предусмотреть корректную обработку переходов в Doze. Рекомендуется тестировать фоновую работу на реальных устройствах с включённым режимом энергосбережения и после длительного простоя.

Практические советы

При проектировании фоновых задач придерживайтесь следующих советов. 1. Всегда используйте WorkManager для новых Android-проектов. Он решает проблемы совместимости, Doze Mode и перезагрузки устройства. 2. На iOS отдавайте предпочтение BGTaskScheduler вместо Background Fetch для iOS 13+. 3. Foreground Service используйте только когда задача действительно требует видимого уведомления. 4. Не злоупотребляйте WakeLock — это убивает батарею и может привести к блокировке приложения. 5. Тестируйте фоновые задачи в Doze Mode: adb shell dumpsys deviceidle force-idle. 6. Всегда проверяйте, что задача выполнилась, через логгирование и аналитику. 7. Помните про лимиты: iOS даёт ~30 секунд на Background Fetch и ~несколько минут на BGProcessingTask. Android WorkManager не гарантирует точное время выполнения.