Background Thread nello sviluppo mobile: cos'è, compiti e modalità d'uso

Cos'è un Background Thread

Background Thread — qualsiasi thread in un'applicazione che non sia il Main Thread e non abbia accesso all'UI. Il suo compito è liberare il thread principale dalle operazioni pesanti per mantenere l'interfaccia reattiva. Il sistema operativo distribuisce i thread in background tra i core della CPU, consentendo di eseguire più attività in parallelo. iOS gestisce automaticamente il pool di thread tramite GCD, Android tramite i pool di Java Executors.

A differenza del Main Thread, che elabora gli eventi in sequenza (uno dopo l'altro), i thread in background possono essere eseguiti in parallelo, limitati solo dal numero di core della CPU. Ad esempio, su un dispositivo a 8 core è possibile eseguire fino a 8 attività in background parallele senza un significativo rallentamento. Tuttavia, un numero eccessivo di thread (centinaia) porta al thread starvation — competizione per i core e aumento del overhead del cambio di contesto (context switch).

Quality of Service (QoS) — meccanismo iOS che permette di specificare la priorità di un'attività in background. Valori: .userInteractive (il più alto, quasi Main Thread), .userInitiated (l'utente si aspetta un risultato), .default (standard), .utility (l'utente non attende direttamente), .background (il più basso, per sincronizzazione e indicizzazione). Su Android, l'equivalente è Thread.setPriority() da 1 a 10, ma Android utilizza anche cgroups per la gestione di gruppo delle priorità dei thread.

Background Thread su iOS: GCD e DispatchQueue.global

DispatchQueue.global(qos:) — il modo principale per ottenere una coda in background su iOS. GCD (Grand Central Dispatch) crea automaticamente un pool di thread e distribuisce le attività tra i core. La chiamata DispatchQueue.global(qos: .background).async {} invia un blocco alla coda in background con la priorità più bassa. Per attività il cui risultato è necessario immediatamente, utilizzare .userInitiated o .utility.

OperationQueue — un'astrazione di più alto livello su GCD che consente di impostare dipendenze tra operazioni, il numero massimo di operazioni simultanee (maxConcurrentOperationCount) e priorità. OperationQueue è utile per catene multitasking complesse: scaricare file → decomprimere → salvare nella cache. Per impostazione predefinita, OperationQueue utilizza thread in background, salvo diversa indicazione.

import UIKit

class ImageDownloader {

    func downloadImagesSequentially() {
        let urls = ["https://example.com/1.png", "https://example.com/2.png"]

        // OperationQueue con maxConcurrentOperationCount = 2
        let queue = OperationQueue()
        queue.maxConcurrentOperationCount = 2
        queue.qualityOfService = .utility

        for urlString in urls {
            queue.addOperation {
                guard let url = URL(string: urlString),
                      let data = try? Data(contentsOf: url)
                else { return }

                DispatchQueue.main.async {
                    print("Caricato: \(url.lastPathComponent)")
                }
            }
        }
    }

    // GCD: coda globale in background con diversi QoS
    func backgroundTaskWithQoS() {
        DispatchQueue.global(qos: .userInitiated).async {
            // Priorità alta — l'utente attende il risultato
            let result = self.heavyComputation()
            DispatchQueue.main.async {
                self.showResult(result)
            }
        }
    }

    private func heavyComputation() -> String {
        Thread.sleep(forTimeInterval: 2) // simulazione di lavoro
        return "Risultato del calcolo"
    }

    private func showResult(_ result: String) {
        print("Result on Main: \(result)")
    }
}

Nell'esempio, OperationQueue carica due immagini in parallelo (maxConcurrentOperationCount = 2) con QoS in background tramite qualityOfService = .utility. Il metodo GCD backgroundTaskWithQoS utilizza una coda globale con .userInitiated per un'attività di cui l'utente attende il risultato. Entrambi gli approcci terminano tornando a DispatchQueue.main per aggiornare l'UI — questo è un requisito obbligatorio su iOS.

Code in background Serial vs Concurrent

GCD supporta due tipi di code: seriali e concorrenti. Le code seriali eseguono le attività una dopo l'altra — comodo per accedere a una risorsa condivisa (file, DB) senza blocchi. Le code concorrenti eseguono le attività in parallelo, distribuendole tra i core disponibili. DispatchQueue.global è sempre concorrente. Per creare una coda seriale, utilizzare DispatchQueue(label: "com.app.queue").

Background Thread su Android: Executors e Dispatchers

Android fornisce diversi livelli di astrazione per i thread in background. L'approccio classico è java.util.concurrent.Executors.newFixedThreadPool(n) o Executors.newCachedThreadPool(). L'approccio moderno sono le Kotlin Coroutines con Dispatchers.IO (per I/O: rete, file, DB) e Dispatchers.Default (per attività intensive di CPU: ordinamento, elaborazione immagini). WorkManager è per attività in background differite e garantite.

HandlerThread — una classe Android specializzata per creare un thread in background con il proprio Looper (coda di messaggi). A differenza di Executors, HandlerThread consente di inviare messaggi e Runnable tramite un Handler. Viene utilizzato per operazioni che richiedono l'accodamento (ad esempio, scrittura sequenziale nel DB). Dopo l'uso, è necessario chiamare quit() o quitSafely() per liberare le risorse.

// Android: Executors e Dispatchers delle Coroutine
import kotlinx.coroutines.Dispatchers
import kotlinx.coroutines.withContext
import java.util.concurrent.Executors

class DataRepository {

    private val ioExecutor = Executors.newFixedThreadPool(4)

    // Approccio classico tramite Executors
    fun loadDataLegacy(callback: (String) -> Unit) {
        ioExecutor.execute {
            val result = readFromFile()
            val handler = android.os.Handler(android.os.Looper.getMainLooper())
            handler.post { callback(result) }
        }
    }

    // Approccio moderno tramite Coroutine
    suspend fun loadDataCoroutines(): String {
        return withContext(Dispatchers.IO) {
            // Operazione file — esecuzione nel pool in background
            readFromFile()
        }
        // Risultato restituito automaticamente a Dispatchers.Main
    }

    // Attività intensiva di CPU su Dispatchers.Default
    suspend fun processImage(pixels: IntArray): IntArray {
        return withContext(Dispatchers.Default) {
            // Ordinamento, filtraggio — esecuzione sul pool Default
            pixels.sortedArray()
        }
    }

    private fun readFromFile(): String {
        Thread.sleep(1000) // simulazione lettura da file
        return "file_content"
    }

    fun cleanup() {
        ioExecutor.shutdown()
    }
}

L'esempio DataRepository mostra l'evoluzione dei thread in background su Android. Il metodo legacy loadDataLegacy utilizza Executors.newFixedThreadPool(4) con un Handler per tornare al Main Thread. Il metodo moderno loadDataCoroutines utilizza withContext(Dispatchers.IO) — la coroutine viene sospesa durante l'esecuzione senza bloccare il thread e riprende automaticamente sul Main Thread. Dispatchers.Default è consigliato per operazioni CPU-bound (ordinamento, filtraggio, trasformazione dati).

Le Coroutine come standard moderno per attività in background

Kotlin Coroutines — non solo un modo di lavorare con i thread, ma un modello fondamentalmente diverso: le attività asincrone non sono legate a un thread specifico e possono essere sospese senza bloccare. Ciò significa che, mentre è in background, una coroutine non occupa un thread ma lo libera per altre attività. Il meccanismo di sospensione consente di eseguire centinaia di migliaia di attività concorrenti su un pool di 4–8 thread senza thread starvation.

Tre dispatcher principali: Dispatchers.Main (UI, un thread), Dispatchers.IO (64 thread per impostazione predefinita per operazioni bloccanti: rete, file, DB), Dispatchers.Default (uguale al numero di core CPU, per calcoli intensivi). Combinandoli tramite withContext, lo sviluppatore cambia thread senza creare callback. withContext è una funzione suspend che non restituisce il controllo fino al completamento dell'attività.

// Coroutine: composizione di attività in background
import kotlinx.coroutines.async
import kotlinx.coroutines.coroutineScope
import kotlinx.coroutines.delay

suspend fun loadUserProfile(userId: String): UserProfile =
    coroutineScope {
        // Caricamento parallelo di dati da diverse fonti
        val user = async(Dispatchers.IO) { fetchUser(userId) }
        val posts = async(Dispatchers.IO) { fetchPosts(userId) }
        val avatar = async(Dispatchers.Default) {
            processAvatar(fetchAvatar(userId))
        }

        // await() — si sospende fino al completamento di tutte le attività
        UserProfile(
            user = user.await(),
            posts = posts.await(),
            avatar = avatar.await()
        )
    }

data class UserProfile(
    val user: String,
    val posts: List<String>,
    val avatar: ByteArray
)

suspend fun fetchUser(id: String): String { delay(300); return "User:$id" }
suspend fun fetchPosts(id: String): List<String> { delay(500); return listOf("Post1") }
suspend fun fetchAvatar(id: String): ByteArray { delay(200); return ByteArray(1024) }
suspend fun processAvatar(data: ByteArray): ByteArray { delay(100); return data }

La funzione loadUserProfile avvia tre attività in background parallele tramite async. fetchUser e fetchPosts sono IO-bound (rete), eseguite su Dispatchers.IO. processAvatar è CPU-bound (elaborazione immagini), eseguita su Dispatchers.Default. await() sospende la coroutine fino al completamento di tutte le attività. Il tempo totale di esecuzione è uguale al tempo massimo tra le tre attività (500 ms per fetchPosts), non alla loro somma. Questo è un vantaggio chiave delle coroutine rispetto all'esecuzione sequenziale.

Concorrenza strutturata: prevenzione delle perdite

Structured concurrency — principio per cui ogni coroutine ha un ambito padre e la cancellazione del padre annulla automaticamente le coroutine figlie. Su Android, lifecycleScope annulla tutte le coroutine alla distruzione dell'Activity. viewModelScope lo fa alla pulizia del ViewModel. Ciò previene le perdite di attività in background: se l'utente chiude lo schermo, mentre è in background la coroutine non continuerà a caricare dati che non sono più necessari.

// WorkManager con coroutine
import android.content.Context
import androidx.work.*
import kotlinx.coroutines.Dispatchers
import kotlinx.coroutines.withContext

class SyncWorker(
    appContext: Context,
    workerParams: WorkerParameters
) : CoroutineWorker(appContext, workerParams) {

    override suspend fun doWork(): Result {
        // Esecuzione su Dispatchers.Default (per impostazione predefinita)
        return withContext(Dispatchers.IO) {
            try {
                syncDataToServer()
                Result.success()
            } catch (e: Exception) {
                if (runAttemptCount < 3) Result.retry() else Result.failure()
            }
        }
    }

    private suspend fun syncDataToServer() {
        // Simulazione sincronizzazione
        delay(1000)
    }
}

// Avvio attività WorkManager con vincoli
fun scheduleSync(context: Context) {
    val constraints = Constraints.Builder()
        .setRequiredNetworkType(NetworkType.CONNECTED)
        .setRequiresBatteryNotLow(true)
        .build()

    val syncWork = OneTimeWorkRequestBuilder<SyncWorker>()
        .setConstraints(constraints)
        .setBackoffCriteria(BackoffPolicy.EXPONENTIAL, 10, java.util.concurrent.TimeUnit.SECONDS)
        .build()

    WorkManager.getInstance(context).enqueue(syncWork)
}