Attività in background nello sviluppo mobile: cosa sono, tipi e come funzionano

Cosa sono le attività in background?

Un'attività in background è qualsiasi codice eseguito quando l'app non è in primo piano (schermo attivo). Può includere: sincronizzazione periodica dei dati con il server, download di file grandi, elaborazione di notifiche push, tracciamento GPS, aggiornamento widget. Ogni piattaforma ha le proprie restrizioni sul lavoro in background: iOS è più restrittivo (10–30 minuti di tempo in background), Android è più permissivo ma ha inasprito le regole dalla versione 9.

L'architettura delle attività in background si basa su tre livelli: (1) attività immediate — eseguite subito (Foreground Service); (2) attività differite — eseguite in condizioni adatte (WorkManager, BGTaskScheduler); (3) attività periodiche — si ripetono a intervalli prestabiliti. Scegliere il livello giusto determina se l'attività verrà completata in tempo e se porterà al rifiuto dell'app dallo store.

Su entrambe le piattaforme, Google/Apple raccomandano vivamente di utilizzare API dichiarative invece di gestire direttamente i thread in background. WorkManager su Android e BGTaskScheduler su iOS consentono al sistema di distribuire in modo ottimale il lavoro in background tra le app, raggruppando le attività per risparmiare energia. In IT Sectr, iniziamo sempre la progettazione dell'architettura di background analizzando i requisiti di frequenza e urgenza degli aggiornamenti.

Attività in background su iOS (Background Fetch, BGTaskScheduler)

iOS fornisce diversi meccanismi per il lavoro in background. Background Fetch — aggiornamento periodico dei contenuti con un intervallo determinato dal sistema (non dallo sviluppatore). L'app riceve una finestra di circa 30 secondi per scaricare nuovi dati. Background Fetch si attiva tramite Capabilities → Background Modes → Background Fetch e si implementa in AppDelegate: application(_:performFetchWithCompletionHandler:).

BGTaskScheduler è l'API moderna per iOS 13+, che sostituisce Background Fetch. Lo sviluppatore registra un'attività con un identificatore e il sistema la esegue quando le condizioni sono adatte. BGAppRefreshTask — per aggiornamenti brevi dei contenuti; BGProcessingTask — per attività lunghe (pulizia cache, sincronizzazione database). Le attività vengono registrate all'avvio dell'app e il sistema pianifica la loro esecuzione considerando lo stato della batteria, della rete e l'attività dell'utente.

Background Modes — un elenco di modalità che consentono il lavoro in background per scenari specifici: Audio (riproduzione in background), Location (tracciamento GPS), VoIP (chiamate tramite PushKit), BLE (connessione a dispositivi Bluetooth), Processing (attività lunghe tramite BGTaskScheduler). Ogni modalità richiede una giustificazione durante la revisione dell'App Store. Utilizzare modalità senza reale necessità è una causa comune di rifiuto dell'app.

Significant Location Change — un meccanismo per app che non necessitano di geolocalizzazione costante ma devono sapere degli spostamenti significativi dell'utente (oltre 500 metri). Il sistema sveglia l'app quando cambia la torre cellulare. Questo meccanismo risparmia notevolmente la batteria rispetto al GPS costante.

Attività in background su Android (WorkManager, JobScheduler, Foreground Service)

Android offre il set più ricco di API per le attività in background, ma dalla versione 8.0 (API 26) le regole sono diventate più severe. WorkManager è la soluzione raccomandata da Google per tutti i tipi di attività in background. WorkManager garantisce l'esecuzione dell'attività anche dopo il riavvio del dispositivo (tramite BootReceiver) e supporta catene di attività, LiveData/Flow osservabili e retrocompatibilità fino all'API 14.

WorkManager utilizza Worker — una classe base con il metodo doWork(). Constraints definisce le condizioni di esecuzione: NetworkType.CONNECTED, BatteryNotLow, StorageNotLow. PeriodicWorkRequest — per attività periodiche con un intervallo minimo di 15 minuti. WorkManager si adatta automaticamente a Doze Mode e App Standby, raggruppando le attività in finestre di manutenzione. Esempio di un Worker semplice:

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 — un'API più vecchia (Android 5+, API 21). Pianifica attività con condizioni specificate (rete, carica, inattività). Limitazione: non supporta il riavvio del dispositivo (necessita di BootReceiver) e non ha stato osservabile. JobScheduler è adatto per attività semplici in progetti legacy; per nuovi progetti, utilizzare WorkManager.

Foreground Service — un servizio che l'utente vede tramite una notifica persistente (ongoing notification). Utilizzato per: riproduzione musicale, tracciamento GPS, download di file grandi. Foreground Service ha alta priorità — il sistema non lo terminerà in caso di memoria insufficiente. Da Android 13, è richiesta l'autorizzazione FOREGROUND_SERVICE_SPECIAL_USE per alcuni tipi. Un'alternativa è WorkManager con ForegroundServiceOption (attività lunghe).

AlarmManager — per attività che devono essere eseguite a un'ora esatta (sveglia, promemoria). AlarmManager può svegliare il dispositivo da Doze Mode (setAlarmClock). Non raccomandato per sincronizzazioni regolari a causa dell'elevato consumo energetico. Per attività periodiche, utilizzare WorkManager e AlarmManager solo quando l'ora esatta è critica.

Doze Mode e App Standby

Doze Mode è una modalità di risparmio energetico in Android che influenza l'esecuzione delle attività in background. Introdotto in Android 6.0 (API 23). Quando il dispositivo non è in carica, lo schermo è spento e il dispositivo è fermo, Doze Mode blocca le richieste di rete, rimanda JobScheduler e WakeLock. Periodicamente, Doze apre finestre di manutenzione — brevi intervalli in cui le app possono eseguire attività differite. Da Android 7.0 (API 24), Doze si attiva quando lo schermo è spento, non solo quando è completamente fermo.

App Standby — una modalità in cui le app inutilizzate vengono messe in attesa. Se un'app non ha notifiche attive e non è stata aperta per diversi giorni, viene inserita in uno Standby Bucket: attivo (active), working, frequent, rare. Meno l'app viene utilizzata, più severe sono le restrizioni: le richieste di rete vengono rimandate, la sincronizzazione viene bloccata, JobScheduler non viene eseguito.

WakeLock — un meccanismo che mantiene il dispositivo attivo (evita che si addormenti). Utilizzato per completare operazioni importanti. WakeLock deve essere rilasciato dopo il completamento dell'attività, altrimenti la batteria si scaricherà in poche ore. WakeLock non funziona in Doze Mode — il sistema lo ignora. Lavorare con WakeLock su Android 8+ richiede l'autorizzazione WAKE_LOCK e una corretta gestione del ciclo di vita.

In IT Sectr, consideriamo Doze Mode e App Standby in fase di progettazione. WorkManager gestisce automaticamente queste modalità, ma per Foreground Service è necessario pianificare una corretta gestione delle transizioni verso Doze. Si consiglia di testare il lavoro in background su dispositivi reali con la modalità di risparmio energetico attivata e dopo periodi prolungati di inattività.

Consigli pratici

Quando si progettano attività in background, seguire questi consigli. 1. Utilizzare sempre WorkManager per nuovi progetti Android. Risolve problemi di compatibilità, Doze Mode e riavvio del dispositivo. 2. Su iOS, preferire BGTaskScheduler a Background Fetch per iOS 13+. 3. Utilizzare Foreground Service solo quando l'attività richiede realmente una notifica visibile. 4. Non abusare di WakeLock — consuma la batteria e può portare al rifiuto dell'app. 5. Testare le attività in background in Doze Mode: adb shell dumpsys deviceidle force-idle. 6. Verificare sempre il completamento dell'attività tramite logging e analisi. 7. Ricordare i limiti: iOS concede circa 30 secondi per Background Fetch e circa alcuni minuti per BGProcessingTask. Android WorkManager non garantisce un tempo di esecuzione esatto.