Zadania w tle w rozwoju mobilnym: czym są, rodzaje i jak działają

Czym są zadania w tle?

Zadanie w tle to dowolny kod wykonywany, gdy aplikacja nie jest na pierwszym planie (aktywny ekran). Może to obejmować: okresową synchronizację danych z serwerem, pobieranie dużych plików, przetwarzanie powiadomień push, śledzenie geolokalizacji, aktualizację widgetów. Każda platforma ma własne ograniczenia dotyczące pracy w tle: iOS jest bardziej restrykcyjny (10–30 minut czasu w tle), Android jest bardziej liberalny, ale od wersji 9 zaostrzył zasady.

Architektura zadań w tle opiera się na trzech poziomach: (1) zadania natychmiastowe — wykonywane od razu (Foreground Service); (2) zadania odroczone — wykonywane w odpowiednich warunkach (WorkManager, BGTaskScheduler); (3) zadania okresowe — powtarzane w ustalonym odstępie czasu. Wybór odpowiedniego poziomu decyduje o tym, czy zadanie zostanie ukończone na czas i czy doprowadzi do odrzucenia aplikacji w sklepie.

Na obu platformach Google/Apple zdecydowanie zalecają używanie deklaratywnych API zamiast bezpośredniego zarządzania wątkami w tle. WorkManager na Androidzie i BGTaskScheduler na iOS pozwalają systemowi optymalnie rozdzielać pracę w tle między aplikacjami, grupując zadania w celu oszczędzania energii. W IT Sectr zawsze zaczynamy projektowanie architektury tła od analizy wymagań dotyczących częstotliwości i pilności aktualizacji.

Zadania w tle na iOS (Background Fetch, BGTaskScheduler)

iOS zapewnia kilka mechanizmów do pracy w tle. Background Fetch — okresowa aktualizacja treści z interwałem określonym przez system (nie programistę). Aplikacja otrzymuje okno ~30 sekund na pobranie nowych danych. Background Fetch włącza się przez Capabilities → Background Modes → Background Fetch i implementuje w AppDelegate: application(_:performFetchWithCompletionHandler:).

BGTaskScheduler to nowoczesne API dla iOS 13+, zastępujące Background Fetch. Programista rejestruje zadanie z identyfikatorem, a system uruchamia je w odpowiednich warunkach. BGAppRefreshTask — do krótkich aktualizacji treści; BGProcessingTask — do długotrwałych zadań (czyszczenie pamięci podręcznej, synchronizacja bazy danych). Zadania są rejestrowane przy uruchomieniu aplikacji, a system planuje ich wykonanie, biorąc pod uwagę stan baterii, sieć i aktywność użytkownika.

Background Modes — lista trybów umożliwiających pracę w tle dla konkretnych scenariuszy: Audio (odtwarzanie w tle), Location (śledzenie GPS), VoIP (połączenia przez PushKit), BLE (połączenie z urządzeniami Bluetooth), Processing (długotrwałe zadania przez BGTaskScheduler). Każdy tryb wymaga uzasadnienia podczas przeglądu w App Store. Używanie trybów bez rzeczywistej potrzeby jest częstym powodem odrzucenia aplikacji.

Significant Location Change — mechanizm dla aplikacji, które nie potrzebują stałej geolokalizacji, ale muszą wiedzieć o znaczącym przemieszczeniu użytkownika (ponad 500 metrów). System wybudza aplikację przy zmianie stacji bazowej. Ten mechanizm znacznie oszczędza baterię w porównaniu do ciągłego śledzenia GPS.

Zadania w tle na Androidzie (WorkManager, JobScheduler, Foreground Service)

Android oferuje najbogatszy zestaw API dla zadań w tle, ale od wersji 8.0 (API 26) zasady stały się bardziej rygorystyczne. WorkManager to zalecane przez Google rozwiązanie dla wszystkich typów zadań w tle. WorkManager gwarantuje wykonanie zadania nawet po ponownym uruchomieniu urządzenia (przez BootReceiver) i obsługuje łańcuchy zadań, obserwowalne LiveData/Flow oraz wsteczną kompatybilność aż do API 14.

WorkManager używa Worker — klasy bazowej z metodą doWork(). Constraints określają warunki wykonania: NetworkType.CONNECTED, BatteryNotLow, StorageNotLow. PeriodicWorkRequest — dla zadań okresowych z minimalnym interwałem 15 minut. WorkManager automatycznie dostosowuje się do Doze Mode i App Standby, grupując zadania w okna konserwacyjne. Przykład prostego Workera:

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 — starsze API (Android 5+, API 21). Planuje zadania z określonymi warunkami (sieć, ładowanie, bezczynność). Ograniczenie: nie obsługuje ponownego uruchamiania urządzenia (potrzebny BootReceiver) i nie ma obserwowalnego stanu. JobScheduler nadaje się do prostych zadań w starszych projektach; w nowych projektach używaj WorkManager.

Foreground Service — usługa, którą użytkownik widzi poprzez stałe powiadomienie (ongoing notification). Używana do: odtwarzania muzyki, śledzenia GPS, pobierania dużych plików. Foreground Service ma wysoki priorytet — system nie zabije go przy braku pamięci. Od Androida 13 wymagane jest zezwolenie FOREGROUND_SERVICE_SPECIAL_USE dla niektórych typów. Alternatywą jest WorkManager z ForegroundServiceOption (długie zadania).

AlarmManager — dla zadań, które muszą być wykonane o dokładnym czasie (alarm, przypomnienie). AlarmManager może obudzić urządzenie z Doze Mode (setAlarmClock). Nie jest zalecany do regularnej synchronizacji ze względu na wysokie zużycie energii. Do zadań okresowych używaj WorkManager, a AlarmManager tylko wtedy, gdy dokładny czas jest krytyczny.

Doze Mode i App Standby

Doze Mode to tryb oszczędzania energii w Androidzie, który wpływa na wykonywanie zadań w tle. Wprowadzony w Android 6.0 (API 23). Gdy urządzenie nie ładuje się, ekran jest wyłączony, a urządzenie jest nieruchome, Doze Mode blokuje żądania sieciowe, odkłada JobScheduler i WakeLock. Okresowo Doze otwiera okna konserwacyjne — krótkie interwały, w których aplikacje mogą wykonywać odroczone zadania. Od Androida 7.0 (API 24) Doze aktywuje się przy wyłączonym ekranie, nie tylko przy całkowitym bezruchu.

App Standby — tryb, w którym nieużywane aplikacje są przełączane w stan oczekiwania. Jeśli aplikacja nie ma aktywnego powiadomienia i nie była otwierana przez kilka dni, zostaje umieszczona w Standby Bucket: aktywny (active), working, frequent, rare. Im rzadziej używana jest aplikacja, tym bardziej restrykcyjne są ograniczenia: żądania sieciowe są odkładane, synchronizacja blokowana, JobScheduler nie uruchamia się.

WakeLock — mechanizm utrzymujący urządzenie w stanie aktywnym (zapobiega usypianiu). Używany do kończenia ważnych operacji. WakeLock musi być zwolniony (release) po wykonaniu zadania, w przeciwnym razie bateria rozładuje się w ciągu kilku godzin. WakeLock nie działa w Doze Mode — system go ignoruje. Praca z WakeLock na Android 8+ wymaga zezwolenia WAKE_LOCK i prawidłowego zarządzania cyklem życia.

W IT Sectr uwzględniamy Doze Mode i App Standby na etapie projektowania. WorkManager automatycznie obsługuje te tryby, ale dla Foreground Service należy przewidzieć prawidłową obsługę przejść do Doze. Zaleca się testowanie pracy w tle na rzeczywistych urządzeniach z włączonym trybem oszczędzania energii i po dłuższych okresach bezczynności.

Praktyczne wskazówki

Projektując zadania w tle, postępuj zgodnie z poniższymi wskazówkami. 1. Zawsze używaj WorkManager do nowych projektów Android. Rozwiązuje problemy ze zgodnością, Doze Mode i ponownym uruchamianiem urządzenia. 2. Na iOS preferuj BGTaskScheduler zamiast Background Fetch dla iOS 13+. 3. Używaj Foreground Service tylko wtedy, gdy zadanie naprawdę wymaga widocznego powiadomienia. 4. Nie nadużywaj WakeLock — wyczerpuje baterię i może prowadzić do odrzucenia aplikacji. 5. Testuj zadania w tle w Doze Mode: adb shell dumpsys deviceidle force-idle. 6. Zawsze weryfikuj wykonanie zadania poprzez logowanie i analitykę. 7. Pamiętaj o limitach: iOS daje ~30 sekund na Background Fetch i ~kilka minut na BGProcessingTask. Android WorkManager nie gwarantuje dokładnego czasu wykonania.