Háttérfeladatok a mobilfejlesztésben: mik ezek, milyen típusok vannak és hogyan működnek

Mik azok a háttérfeladatok?

A háttérfeladat bármely olyan kód, amely akkor fut, amikor az alkalmazás nincs az előtérben (aktív képernyő). Ez magában foglalhatja: időszakos adatszinkronizálást a szerverrel, nagy fájlok letöltését, push-értesítések feldolgozását, helymeghatározás követését, widgetek frissítését. Minden platformnak saját korlátozásai vannak a háttérmunkára vonatkozóan: az iOS szigorúbb (10–30 perc háttéridő), az Android megengedőbb, de a 9-es verziótól kezdve szigorította a szabályokat.

A háttérfeladatok architektúrája három szintre épül: (1) azonnali feladatok — azonnal végrehajtódnak (Foreground Service); (2) halasztott feladatok — megfelelő körülmények között hajtódnak végre (WorkManager, BGTaskScheduler); (3) időszakos feladatok — meghatározott időközönként ismétlődnek. A megfelelő szint kiválasztása határozza meg, hogy a feladat időben befejeződik-e, és hogy az alkalmazás elutasításához vezet-e az áruházban.

Mindkét platformon a Google/Apple határozottan javasolja a deklaratív API-k használatát a szálak háttérben történő közvetlen kezelése helyett. Az Androidon lévő WorkManager és az iOS-en lévő BGTaskScheduler lehetővé teszi a rendszer számára, hogy optimálisan ossza el a háttérmunkát az alkalmazások között, csoportosítva a feladatokat az energia megtakarítása érdekében. Az IT Sectr-nél mindig a frissítések gyakoriságának és sürgősségének követelményeit elemezve kezdjük a háttérarchitektúra tervezését.

Háttérfeladatok iOS-en (Background Fetch, BGTaskScheduler)

Az iOS több mechanizmust biztosít a háttérmunkához. Background Fetch — időszakos tartalomfrissítés a rendszer által meghatározott időközönként (nem a fejlesztő által). Az alkalmazás ~30 másodperces ablakot kap az új adatok letöltésére. A Background Fetch a Capabilities → Background Modes → Background Fetch útvonalon engedélyezhető, és az AppDelegate-ben implementálható: application(_:performFetchWithCompletionHandler:).

A BGTaskScheduler a modern API iOS 13+-hoz, amely felváltja a Background Fetch-et. A fejlesztő regisztrál egy feladatot egy azonosítóval, és a rendszer megfelelő körülmények között futtatja. BGAppRefreshTask — rövid tartalomfrissítésekhez; BGProcessingTask — hosszú idejű feladatokhoz (gyorsítótár tisztítása, adatbázis szinkronizálása). A feladatok az alkalmazás indításakor kerülnek regisztrálásra, és a rendszer az akkumulátor állapotát, a hálózatot és a felhasználói aktivitást figyelembe véve ütemezi a végrehajtásukat.

Background Modes — olyan módok listája, amelyek lehetővé teszik a háttérmunkát bizonyos forgatókönyvekhez: Audio (háttérlejátszás), Location (GPS-követés), VoIP (hívások PushKit-en keresztül), BLE (Bluetooth-eszközök csatlakoztatása), Processing (hosszú feladatok a BGTaskScheduler-en keresztül). Minden mód indoklást igényel az App Store-ellenőrzés során. A módok valós szükséglet nélküli használata az alkalmazás elutasításának gyakori oka.

Significant Location Change — olyan alkalmazásokhoz, amelyeknek nincs szükségük állandó helymeghatározásra, de tudniuk kell a felhasználó jelentős mozgásáról (több mint 500 méter). A rendszer felébreszti az alkalmazást a mobil torony váltásakor. Ez a mechanizmus jelentősen kíméli az akkumulátort az állandó GPS-követéshez képest.

Háttérfeladatok Androidon (WorkManager, JobScheduler, Foreground Service)

Az Android kínálja a leggazdagabb API-készletet a háttérfeladatokhoz, de a 8.0-s verziótól (API 26) kezdve a szabályok szigorúbbá váltak. A WorkManager a Google által ajánlott megoldás minden típusú háttérfeladathoz. A WorkManager garantálja a feladat végrehajtását még az eszköz újraindítása után is (BootReceiver-en keresztül), és támogatja a feladatláncokat, a megfigyelhető LiveData/Flow-t és a visszafelé kompatibilitást egészen az API 14-ig.

A WorkManager a Worker-t használja — egy alaposztályt a doWork() metódussal. A Constraints meghatározza a végrehajtási feltételeket: NetworkType.CONNECTED, BatteryNotLow, StorageNotLow. PeriodicWorkRequest — időszakos feladatokhoz, minimum 15 perces időközzel. A WorkManager automatikusan alkalmazkodik a Doze Mode-hoz és az App Standby-hoz, a feladatokat karbantartási ablakokba csoportosítva. Példa egy egyszerű Worker-re:

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 — egy régebbi API (Android 5+, API 21). Megadott feltételekkel (hálózat, töltés, tétlenség) ütemezi a feladatokat. Korlátozás: nem támogatja az eszköz újraindítását (BootReceiver szükséges), és nincs megfigyelhető állapota. A JobScheduler egyszerű feladatokhoz alkalmas örökölt projektekben; új projektekhez használja a WorkManager-t.

Foreground Service — egy szolgáltatás, amelyet a felhasználó egy állandó értesítésen (ongoing notification) keresztül lát. Használják: zenelejátszáshoz, GPS-követéshez, nagy fájlok letöltéséhez. A Foreground Service magas prioritású — a rendszer nem öli meg, ha kevés a memória. Az Android 13-tól kezdve bizonyos típusokhoz FOREGROUND_SERVICE_SPECIAL_USE engedély szükséges. Alternatíva a WorkManager a ForegroundServiceOptionnal (hosszú feladatok).

AlarmManager — olyan feladatokhoz, amelyeknek pontos időben kell futniuk (ébresztő, emlékeztető). Az AlarmManager felébresztheti az eszközt a Doze Mode-ból (setAlarmClock). Magas energiafogyasztása miatt nem ajánlott rendszeres szinkronizáláshoz. Időszakos feladatokhoz használja a WorkManager-t, az AlarmManager-t csak akkor, ha a pontos idő kritikus.

Doze Mode és App Standby

A Doze Mode egy energiatakarékos mód Androidon, amely befolyásolja a háttérfeladatok végrehajtását. Az Android 6.0-ban (API 23) vezették be. Amikor az eszköz nem töltődik, a képernyő ki van kapcsolva, és az eszköz mozdulatlan, a Doze Mode blokkolja a hálózati kéréseket, elhalasztja a JobScheduler-t és a WakeLock-ot. Rendszeresen a Doze karbantartási ablakokat nyit — rövid időközöket, amikor az alkalmazások végrehajthatják a halasztott feladatokat. Az Android 7.0-tól (API 24) a Doze akkor aktiválódik, amikor a képernyő ki van kapcsolva, nem csak teljes mozdulatlanság esetén.

App Standby — egy mód, amelyben a nem használt alkalmazások készenléti állapotba kerülnek. Ha egy alkalmazásnak nincs aktív értesítése, és több napig nem nyitották meg, egy Standby Bucket-ba kerül: aktív (active), working, frequent, rare. Minél ritkábban használják az alkalmazást, annál szigorúbbak a korlátozások: a hálózati kérések elhalasztódnak, a szinkronizálás blokkolódik, a JobScheduler nem fut.

WakeLock — egy mechanizmus, amely ébren tartja az eszközt (megakadályozza az elalvást). Fontos műveletek befejezéséhez használják. A WakeLock-ot fel kell szabadítani (release) a feladat befejezése után, különben az akkumulátor néhány órán belül lemerül. A WakeLock nem működik Doze Mode-ban — a rendszer figyelmen kívül hagyja. A WakeLock használata Android 8+-on WAKE_LOCK engedélyt és megfelelő életciklus-kezelést igényel.

Az IT Sectr-nél figyelembe vesszük a Doze Mode-ot és az App Standby-t a tervezési szakaszban. A WorkManager automatikusan kezeli ezeket a módokat, de a Foreground Service esetében meg kell tervezni a Doze-ba való átmenetek helyes kezelését. Javasoljuk a háttérmunka tesztelését valós eszközökön bekapcsolt energiatakarékos móddal és hosszabb tétlenségi időszakok után.

Gyakorlati tippek

A háttérfeladatok tervezésekor kövesse ezeket a tippeket. 1. Mindig használja a WorkManager-t új Android-projektekhez. Megoldja a kompatibilitási problémákat, a Doze Mode-ot és az eszköz újraindítását. 2. iOS-en részesítse előnyben a BGTaskScheduler-t a Background Fetch-csel szemben iOS 13+-on. 3. Csak akkor használja a Foreground Service-t, ha a feladat valóban látható értesítést igényel. 4. Ne éljen vissza a WakeLock-kal — lemeríti az akkumulátort, és az alkalmazás elutasításához vezethet. 5. Tesztelje a háttérfeladatokat Doze Mode-ban: adb shell dumpsys deviceidle force-idle. 6. Mindig ellenőrizze a feladat befejezését naplózás és analitika segítségével. 7. Ne feledje a korlátokat: az iOS ~30 másodpercet ad a Background Fetch-re és ~néhány percet a BGProcessingTask-ra. Az Android WorkManager nem garantál pontos végrehajtási időt.