Esecuzione in background nello sviluppo mobile — essenza, limiti e principi di funzionamento

Cos'è l'esecuzione in background nelle app mobili?

Background Execution è la capacità di un'applicazione di continuare a eseguire codice dopo che l'utente l'ha ridotta a icona o è passato a un'altra app. Senza meccanismi speciali, il sistema operativo mobile mette l'applicazione nello stato Suspended (sospeso) entro pochi secondi dal passaggio in background, liberando CPU e memoria per le app attive.

Stati dell'applicazione in background

Un'applicazione mobile attraversa diversi stati del ciclo di vita: Foreground (attivo), Background (in background), Suspended (sospeso) e Terminated (terminato). Background è l'unico stato in cui l'app può eseguire codice senza un'interfaccia visibile. iOS e Android definiscono la durata e le operazioni disponibili in questo stato in modo diverso.

Casi d'uso principali

L'esecuzione in background è necessaria per la sincronizzazione dei dati, il download di contenuti, l'elaborazione delle notifiche Push, la geolocalizzazione in background e la riproduzione audio. La sincronizzazione è lo scenario più comune: l'app invia dati al server o scarica aggiornamenti senza l'intervento dell'utente.

• Sincronizzazione — caricamento e scaricamento dei dati al cambiamento dello stato della rete.
• Geolocalizzazione — tracciamento della posizione nei tracker fitness e nei navigatori.
• Multimedia — riproduzione di audio e video in background (musica, podcast).
• Notifiche — elaborazione di notifiche Push e locali.
• Download — scaricamento di file di grandi dimensioni (podcast, video) in background.

Perché i sistemi operativi mobili limitano l'esecuzione in background

I limiti dell'esecuzione in background sono dovuti a tre fattori: consumo energetico, prestazioni del dispositivo e privacy dell'utente. La CPU e i moduli radio (Wi-Fi, dati cellulari) consumano più energia — ogni processo in background riduce la durata della batteria.

Consumo energetico e autonomia

Gli studi di Google mostrano che le app che eseguono attività in background ogni 5 minuti riducono la durata della batteria del dispositivo del 20–30% al giorno. Anche le operazioni in background ottimizzate con una frequenza di una volta all'ora hanno un impatto notevole se ci sono più di due di queste app.

RAM e prestazioni

Ogni app in background occupa RAM. Quando la RAM è insufficiente, il sistema scarica le app dalla memoria, causando un riavvio al ritorno dell'utente. iOS utilizza l'algoritmo Jetsam — un meccanismo di terminazione forzata dei processi in background quando viene superato il limite di memoria. Android utilizza LMK (Low Memory Killer) con un principio simile.

Privacy dell'utente

A partire da Android 10 e iOS 13, il sistema richiede che le app dichiarino lo scopo del lavoro in background. Android ha introdotto restrizioni all'avvio dei Broadcast Receiver in background. iOS richiede di specificare la Background Mode nelle Capabilities del progetto. L'utente può disabilitare l'esecuzione in background per qualsiasi app nelle impostazioni.

Esecuzione in background su Android: WorkManager e Foreground Service

Android fornisce diversi meccanismi per l'esecuzione in background, ciascuno dei quali risolve una categoria diversa di attività. WorkManager è l'API consigliata per attività differite e periodiche. Foreground Service è per l'esecuzione immediata con una notifica visibile. JobScheduler è un'alternativa di basso livello a WorkManager.

WorkManager — Soluzione universale

WorkManager fa parte di Android Jetpack e fornisce l'esecuzione di attività in background con garanzia di completamento anche dopo il riavvio del dispositivo. L'API sceglie il momento di esecuzione ottimale tenendo conto dello stato della rete, del livello della batteria e della modalità Doze. WorkManager è compatibile con API 14+ e sostituisce i deprecati AlarmManager e JobScheduler.

Foreground Service — Per operazioni prolungate

Quando un'app deve eseguire un'attività visibile all'utente (riproduzione musicale, registrazione di geolocalizzazione), viene utilizzato Foreground Service. Il servizio mostra una notifica persistente nella barra di stato e ha una priorità più alta — il sistema non lo terminerà fino al completamento dell'attività. A partire da Android 13, è richiesta l'autorizzazione POST_NOTIFICATIONS.

Modalità Doze e ottimizzazione della batteria

A partire da Android 6.0, il dispositivo entra in modalità Doze quando è inattivo. In questa modalità, le operazioni di rete, la sincronizzazione e JobScheduler vengono rinviati. WorkManager si adatta automaticamente a Doze — le attività vengono eseguite durante la successiva finestra di manutenzione quando il dispositivo si risveglia per la manutenzione.

Esecuzione in background su iOS: Background Tasks e App Refresh

iOS adotta un approccio più rigoroso all'esecuzione in background. Background App Refresh è il meccanismo principale per l'aggiornamento periodico dei dati. BGTaskScheduler è l'API per pianificare le attività in base allo stato del sistema. Per operazioni prolungate, sono disponibili Background Modes: audio, location, voip, fetch e processing.

Background App Refresh

Background App Refresh consente all'app di riattivarsi ogni 15–30 minuti per sincronizzare i dati. Il tempo di riattivazione dipende dal comportamento dell'utente — il sistema analizza la frequenza con cui apre l'app. Gli utenti possono disabilitare questa funzione per singole app in Impostazioni — Generali — Background App Refresh.

BGTaskScheduler — Approccio moderno

A partire da iOS 13, BGTaskScheduler ha sostituito i deprecati performFetch e beginBackgroundTask. L'app registra le attività con un identificatore e un intervallo minimo, e il sistema determina il momento di esecuzione ottimale. Le attività sono divise in due tipi: BGProcessingTask (lunghe, 10+ minuti) e BGAppRefreshTask (brevi, fino a 30 secondi).

Limiti di tempo di esecuzione

iOS alloca tempo limitato per l'esecuzione di attività in background — fino a 30 secondi per BGAppRefreshTask e fino a 10 minuti per BGProcessingTask. Quando il limite viene superato, il sistema termina forzatamente l'attività. Lo sviluppatore deve chiamare il gestore di scadenza (expiration handler) per salvare i risultati intermedi.

Esempi di codice: Android WorkManager

Vediamo un'implementazione pratica dell'esecuzione in background su Android usando WorkManager. Un esempio di sincronizzazione dei dati ogni 8 ore con consapevolezza dello stato della rete. WorkManager garantisce l'esecuzione dell'attività anche dopo il riavvio del dispositivo.

class SyncWorker(context: Context, params: WorkerParameters) : Worker(context, params) {
    override fun doWork(): Result {
        return try {
            syncDataToServer()
            Log.d("Sync", "Dati sincronizzati")
            Result.success()
        } catch (e: Exception) {
            Result.retry()
        }
    }
}

// Esegui attività periodica ogni 8 ore
val constraints = Constraints.Builder()
    .setRequiredNetworkType(NetworkType.CONNECTED)
    .setRequiresCharging(false)
    .build()

val syncRequest = PeriodicWorkRequestBuilder<SyncWorker>(
    8, TimeUnit.HOURS
).setConstraints(constraints).build()

WorkManager.getInstance(context).enqueue(syncRequest)

Foreground Service con notifica

Per operazioni prolungate visibili all'utente, utilizzare Foreground Service. Un esempio di download di file con stato di avanzamento nella notifica. Il servizio chiama startForeground() con una notifica che non può essere rimossa. Al completamento del download — stopForeground(STOP_FOREGROUND_REMOVE).

class DownloadService : Service() {
    override fun onStartCommand(intent: Intent?, flags: Int, id: Int): Int {
        startForeground(NOTIFICATION_ID, createNotification())
        downloadFile()
        stopForeground(STOP_FOREGROUND_REMOVE)
        stopSelf()
        return START_NOT_STICKY
    }
    private fun createNotification(): Notification {
        return NotificationCompat.Builder(this, CHANNEL_ID)
            .setContentTitle("Scarica file")
            .setSmallIcon(android.R.drawable.ic_download)
            .build()
    }
}

Esempi di codice: iOS BGTaskScheduler

Su iOS, l'esecuzione in background viene configurata tramite BGTaskScheduler. Un esempio di registrazione ed esecuzione di un'attività di aggiornamento dei contenuti. L'app deve registrare l'identificatore dell'attività in Info.plist e chiamare submit quando l'attività deve essere pianificata.

import BackgroundTasks

func registerBackgroundTask() {
    BGTaskScheduler.shared.register(
        forTaskWithIdentifier: "com.app.refresh",
        using: nil
    ) { task in
        self.handleAppRefresh(task: task as! BGAppRefreshTask)
    }
}

func scheduleAppRefresh() {
    let request = BGAppRefreshTaskRequest(
        identifier: "com.app.refresh"
    )
    request.earliestBeginDate = Date(timeIntervalSinceNow: 15 * 60)
    try? BGTaskScheduler.shared.submit(request)
}

func handleAppRefresh(task: BGAppRefreshTask) {
    scheduleAppRefresh()
    task.expirationHandler = {
        // Salva dati intermedi
        cacheCurrentState()
    }
    fetchLatestData {
        task.setTaskCompleted(success: true)
    }
}

Background Processing Task

Per operazioni prolungate (pulizia della cache, elaborazione dati), utilizzare BGProcessingTask. Il sistema concede fino a 10 minuti per l'esecuzione. Viene eseguito solo quando il dispositivo è in carica e connesso al Wi-Fi. Richiede un identificatore separato in Info.plist e la registrazione tramite register(forTaskWithIdentifier:).

func scheduleProcessing() {
    let request = BGProcessingTaskRequest(
        identifier: "com.app.cleanup"
    )
    request.requiresExternalPower = true
    request.requiresNetworkConnectivity = true
    request.earliestBeginDate = Date(timeIntervalSinceNow: 24 * 60 * 60)
    try? BGTaskScheduler.shared.submit(request)
}

Confronto degli approcci Android e iOS

Android e iOS differiscono fondamentalmente nella loro filosofia di esecuzione in background. Android offre strumenti flessibili con maggiore controllo ma richiede allo sviluppatore di scegliere l'API corretta. iOS limita le capacità ma garantisce prestazioni stabili e autonomia per l'utente.

Quando scegliere Android WorkManager

WorkManager è ottimale per attività che devono essere completate indipendentemente dallo stato dell'app: sincronizzazione dati, invio di analisi, elaborazione code. L'API garantisce l'esecuzione anche dopo lo spegnimento del dispositivo — l'attività viene riprogrammata dopo l'avvio.

Quando scegliere iOS BGTaskScheduler

BGTaskScheduler è adatto per attività che il sistema può eseguire in qualsiasi momento opportuno: scaricare nuovi contenuti, aggiornare widget, pulire la cache. Non adatto per operazioni urgenti — il sistema ritarda l'attività se il dispositivo è in Doze o ha poca batteria.