Bakgrundsuppgifter i mobil utveckling: vad de är, typer och hur de fungerar

Vad är bakgrundsuppgifter?

En bakgrundsuppgift är all kod som körs när appen inte är i förgrunden (aktiv skärm). Detta kan omfatta: periodisk datasynkronisering med servern, nedladdning av stora filer, bearbetning av push-notiser, geolokaliseringsspårning, widgetuppdateringar. Varje plattform har sina egna begränsningar för bakgrundsarbete: iOS är striktare (10–30 minuters bakgrundstid), Android är mer generöst men har skärpt reglerna sedan version 9.

Arkitekturen för bakgrundsuppgifter är uppbyggd på tre nivåer: (1) omedelbara uppgifter — körs direkt (Foreground Service); (2) uppskjutna uppgifter — körs under lämpliga förhållanden (WorkManager, BGTaskScheduler); (3) periodiska uppgifter — upprepas med ett fast intervall. Att välja rätt nivå avgör om uppgiften slutförs i tid och om det leder till att appen avvisas i butiken.

På båda plattformarna rekommenderar Google/Apple starkt att använda deklarativa API:er istället för att direkt hantera trådar i bakgrunden. WorkManager på Android och BGTaskScheduler på iOS låter systemet optimera fördelningen av bakgrundsarbete mellan appar och gruppera uppgifter för att spara energi. På IT Sectr börjar vi alltid designen av bakgrundsarkitekturen med att analysera kraven på uppdateringsfrekvens och brådska.

Bakgrundsuppgifter på iOS (Background Fetch, BGTaskScheduler)

iOS tillhandahåller flera mekanismer för bakgrundsarbete. Background Fetch — periodisk innehållsuppdatering med ett intervall som bestäms av systemet (inte utvecklaren). Appen får ett fönster på ~30 sekunder för att ladda ner ny data. Background Fetch aktiveras via Capabilities → Background Modes → Background Fetch och implementeras i AppDelegate: application(_:performFetchWithCompletionHandler:).

BGTaskScheduler är det moderna API:t för iOS 13+, som ersätter Background Fetch. Utvecklaren registrerar en uppgift med en identifierare och systemet kör den under lämpliga förhållanden. BGAppRefreshTask — för korta innehållsuppdateringar; BGProcessingTask — för långvariga uppgifter (cacherensning, databassynkronisering). Uppgifter registreras vid appstart och systemet schemalägger deras körning med hänsyn till batteristatus, nätverk och användaraktivitet.

Background Modes — en lista med lägen som tillåter bakgrundsarbete för specifika scenarier: Audio (bakgrundsuppspelning), Location (GPS-spårning), VoIP (samtal via PushKit), BLE (anslutning till Bluetooth-enheter), Processing (långvariga uppgifter via BGTaskScheduler). Varje läge kräver motivering vid App Store-granskning. Att använda lägen utan verkligt behov är en vanlig orsak till appavvisning.

Significant Location Change — en mekanism för appar som inte behöver konstant geolokalisering men behöver veta om betydande användarförflyttning (mer än 500 meter). Systemet väcker appen när mobilmasten byts. Denna mekanism sparar betydligt batteri jämfört med konstant GPS-spårning.

Bakgrundsuppgifter på Android (WorkManager, JobScheduler, Foreground Service)

Android erbjuder den rikaste uppsättningen API:er för bakgrundsuppgifter, men sedan version 8.0 (API 26) har reglerna blivit striktare. WorkManager är den rekommenderade lösningen från Google för alla typer av bakgrundsuppgifter. WorkManager garanterar att uppgiften körs även efter omstart av enheten (via BootReceiver) och stöder uppgiftskedjor, observerbara LiveData/Flow och bakåtkompatibilitet ner till API 14.

WorkManager använder Worker — en basklass med metoden doWork(). Constraints definierar körningsvillkoren: NetworkType.CONNECTED, BatteryNotLow, StorageNotLow. PeriodicWorkRequest — för periodiska uppgifter med ett minimiintervall på 15 minuter. WorkManager anpassar sig automatiskt till Doze Mode och App Standby genom att gruppera uppgifter i underhållsfönster. Exempel på en enkel 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 — ett äldre API (Android 5+, API 21). Det schemalägger uppgifter med specificerade villkor (nätverk, laddning, inaktivitet). Begränsning: det stöder inte omstart av enheten (behöver BootReceiver) och har inget observerbart tillstånd. JobScheduler är lämpligt för enkla uppgifter i äldre projekt; använd WorkManager för nya projekt.

Foreground Service — en tjänst som användaren ser genom en permanent notis (ongoing notification). Används för: musikuppspelning, GPS-spårning, nedladdning av stora filer. Foreground Service har hög prioritet — systemet dödar den inte när minnet är lågt. Från och med Android 13 krävs tillståndet FOREGROUND_SERVICE_SPECIAL_USE för vissa typer. Ett alternativ är WorkManager med ForegroundServiceOption (långa uppgifter).

AlarmManager — för uppgifter som måste köras vid en exakt tidpunkt (alarm, påminnelse). AlarmManager kan väcka enheten från Doze Mode (setAlarmClock). Rekommenderas inte för regelbunden synkronisering på grund av hög strömförbrukning. För periodiska uppgifter, använd WorkManager och AlarmManager endast när exakt tid är kritisk.

Doze Mode och App Standby

Doze Mode är ett energisparläge i Android som påverkar körningen av bakgrundsuppgifter. Introducerat i Android 6.0 (API 23). När enheten inte laddas, skärmen är avstängd och enheten är stilla, blockerar Doze Mode nätverksförfrågningar och skjuter upp JobScheduler och WakeLock. Periodiskt öppnar Doze underhållsfönster — korta intervall när appar kan köra uppskjutna uppgifter. Sedan Android 7.0 (API 24) aktiveras Doze när skärmen är avstängd, inte bara vid fullständig stillhet.

App Standby — ett läge där oanvända appar försätts i standbyläge. Om en app inte har någon aktiv notis och inte har öppnats på flera dagar, placeras den i en Standby Bucket: aktiv (active), working, frequent, rare. Ju mindre appen används, desto strängare är begränsningarna: nätverksförfrågningar skjuts upp, synkronisering blockeras, JobScheduler körs inte.

WakeLock — en mekanism som håller enheten vaken (förhindrar den från att somna). Används för att slutföra viktiga operationer. WakeLock måste släppas (release) efter att uppgiften är slutförd, annars töms batteriet på några timmar. WakeLock fungerar inte i Doze Mode — systemet ignorerar det. Arbete med WakeLock på Android 8+ kräver tillståndet WAKE_LOCK och korrekt livscykelhantering.

På IT Sectr tar vi hänsyn till Doze Mode och App Standby i designstadiet. WorkManager hanterar dessa lägen automatiskt, men för Foreground Service måste korrekt hantering av övergångar till Doze planeras. Det rekommenderas att testa bakgrundsarbete på riktiga enheter med energisparläge aktiverat och efter längre perioder av inaktivitet.

Praktiska tips

När du utformar bakgrundsuppgifter, följ dessa tips. 1. Använd alltid WorkManager för nya Android-projekt. Det löser kompatibilitetsproblem, Doze Mode och omstart av enheter. 2. På iOS, föredra BGTaskScheduler framför Background Fetch för iOS 13+. 3. Använd Foreground Service endast när uppgiften verkligen kräver en synlig notis. 4. Missbruka inte WakeLock — det tömmer batteriet och kan leda till appavvisning. 5. Testa bakgrundsuppgifter i Doze Mode: adb shell dumpsys deviceidle force-idle. 6. Verifiera alltid uppgiftsslutförande genom loggning och analys. 7. Kom ihåg gränserna: iOS ger ~30 sekunder för Background Fetch och ~några minuter för BGProcessingTask. Android WorkManager garanterar inte exakt körningstid.