withContext: cos'è, cambio di contesto e lavoro nelle coroutine

Cos'è withContext in Kotlin?

withContext è una funzione sospensiva del pacchetto kotlinx.coroutines che esegue il blocco di codice passato in un CoroutineContext specificato e restituisce il risultato al contesto originale. La firma della funzione è la seguente:

suspend fun  withContext(
    context: CoroutineContext,
    block: suspend CoroutineScope.() -> T
): T

Il parametro context accetta qualsiasi CoroutineContext — più comunemente uno dei Dispatchers.IO, Dispatchers.Default o Dispatchers.Main standard. Il blocco viene eseguito in quel contesto e il risultato viene restituito al punto in cui withContext è stato chiamato.

Caratteristica chiave: ritorno automatico

Dopo il completamento del lambda, withContext riporta garantitamente l'esecuzione al dispatcher originale. Ciò significa che lo sviluppatore non deve chiamare manualmente withContext(Dispatchers.Main) dopo un'operazione in background — il ritorno avviene automaticamente. Questo comportamento è documentato nelle specifiche di Kotlin Coroutines dalla versione 1.3.

Dove viene usato withContext

Lo sviluppo Android è l'area principale di utilizzo di withContext. Uno scenario tipico: un ViewModel avvia una coroutine sul thread principale, all'interno chiama withContext(Dispatchers.IO) per una richiesta di rete e il risultato dopo il ritorno automatico a Main viene utilizzato per aggiornare l'interfaccia utente. Questo approccio è alla base dell'architettura MVVM ed è raccomandato da Google nella guida ufficiale alle coroutine.

Come funziona withContext: cambio di dispatcher

Per capire withContext, è necessario comprendere CoroutineContext e il suo componente chiave — il dispatcher. Ogni coroutine ha un insieme di elementi di contesto, tra i quali il dispatcher determina su quale thread o pool di thread viene eseguito il codice.

Dispatcher standard per withContext

È importante capire che withContext non crea una nuova coroutine — cambia solo il contesto per quella esistente. Questa è una differenza chiave rispetto a launch e async, che generano nuove coroutine. L'implementazione interna di withContext è ottimizzata: se il contesto richiesto corrisponde a quello attuale, non si verifica alcun cambio — la funzione viene eseguita sullo stesso dispatcher.

Quando withContext NON cambia thread

Dispatchers.Main all'interno di withContext(Dispatchers.Main) non causa un cambio — Kotlin Coroutines riconosce l'identità dei contesti e salta l'operazione non necessaria. Allo stesso modo, withContext(Dispatchers.Default) all'interno di una coroutine già in esecuzione su Default non crea overhead. Questa ottimizzazione è implementata in ContinuationInterceptor.

withContext vs launch e async: quando scegliere cosa

I principianti spesso confondono withContext con launch e async, poiché tutte e tre le funzioni lavorano con coroutine e contesto. Tuttavia, il loro scopo è fondamentalmente diverso.

Confronto delle tre funzioni

Regola di selezione

Se è necessario eseguire un'operazione su un thread in background e ottenere un risultato — usa withContext. Se è necessario eseguire più operazioni indipendenti in parallelo — usa async con await. Se non serve il risultato (logging, scrittura cache) — usa launch. Google raccomanda withContext come strumento preferito per il livello Repository nell'architettura Android.

Esempi di codice con withContext

Vediamo tre scenari pratici di utilizzo di withContext in applicazioni Android con Kotlin. Ogni esempio dimostra un compito specifico e il pattern corretto.

Esempio 1: Richiesta di rete nel Repository

Un ViewModel chiama un metodo del repository da una coroutine su Main. All'interno, withContext(Dispatchers.IO) esegue una richiesta HTTP e il risultato viene restituito automaticamente:

class UserRepository(
    private val api: UserApi
) {
    suspend fun getUser(id: String): User {
        return withContext(Dispatchers.IO) {
            api.fetchUser(id)
        }
    }
}

La coroutine nel ViewModel chiama getUser come qualsiasi normale funzione sospensiva — senza specificare esplicitamente il dispatcher. withContext nasconde i dettagli del cambio di thread.

Esempio 2: Due operazioni di background sequenziali

Quando è necessario eseguire più operazioni IO una dopo l'altra, withContext le combina in un unico blocco. È più efficiente che avvolgere ogni operazione in un withContext separato:

suspend fun loadUserProfile(id: String): Profile {
    return withContext(Dispatchers.IO) {
        val user = api.fetchUser(id)
        val posts = api.fetchPosts(id)
        Profile(user, posts)
    }
}

Entrambe le operazioni vengono eseguite su Dispatchers.IO e il risultato Profile viene creato e restituito senza cambi di contesto inutili. Se le operazioni sono indipendenti, è meglio usare async per l'esecuzione parallela.

Esempio 3: Contesto misto con NonCancellable

In alcuni scenari, è necessario eseguire codice che non può essere annullato — ad esempio, salvare lo stato durante la chiusura di una schermata. La combinazione di withContext + NonCancellable risolve questo compito:

withContext(Dispatchers.IO + NonCancellable) {
    cache.saveState(state)
    analytics.logEvent("state_saved")
}

L'operatore + combina due elementi di contesto: il dispatcher IO e il flag NonCancellable. Il blocco viene eseguito anche se la coroutine padre è stata annullata — utile per operazioni di finalizzazione.

Cosa succede sotto il cofano: Continuation e ottimizzazioni

L'implementazione interna di withContext si basa sul meccanismo Continuation — l'astrazione centrale delle coroutine Kotlin. Ogni punto di sospensione salva lo stato di esecuzione in un oggetto Continuation, e withContext non fa eccezione.

Come withContext cambia contesto a livello di bytecode

Il compilatore Kotlin traduce withContext in una chiamata al metodo withContext di kotlinx.coroutines, che internamente crea una nuova istanza di DispatchedContinuation. Questo oggetto avvolge la Continuation originale e sostituisce il suo dispatcher. Se il nuovo dispatcher differisce da quello corrente, l'esecuzione viene sospesa, il blocco viene inviato al pool di thread corrispondente e, dopo il completamento — riprende con il contesto originale.

Ottimizzazione: fast-path quando i contesti coincidono

Quando withContext viene chiamato con lo stesso dispatcher su cui la coroutine è già in esecuzione, Kotlin attiva il fast-path: il blocco viene eseguito in modo sincrono, senza creare un DispatchedContinuation e senza inviarlo al pool di thread. Ciò rende withContext praticamente gratuito per chiamate ripetute con lo stesso contesto. Secondo i benchmark di JetBrains (kotlinx.coroutines 1.8), il fast-path viene completato in meno di 0,1 µs.

Considerazioni sulle prestazioni

Ogni chiamata a withContext con un dispatcher diverso crea un nuovo DispatchedContinuation e richiede un cambio di thread — ci vogliono da 1 a 5 µs a seconda del carico. Per la maggior parte delle applicazioni, questo ritardo è impercettibile, ma all'interno di cicli con migliaia di iterazioni, vale la pena aggregare le operazioni in un unico blocco withContext.

Errori comuni nell'uso di withContext

Anche gli sviluppatori esperti commettono errori lavorando con withContext. Vediamo quattro problemi comuni e come prevenirli.

Errore 1: withContext annidati non necessari

Gli sviluppatori spesso avvolgono ogni riga in un withContext separato invece di combinare le operazioni in un unico blocco. Ogni chiamata extra con un dispatcher diverso crea overhead.

Corretto: combinare operazioni IO sequenziali in un unico withContext(Dispatchers.IO) { ... }. Se alcune operazioni sono intensive di CPU — usa withContext(Dispatchers.Default) all'interno dello stesso blocco.

Errore 2: Usare withContext invece di async per compiti paralleli

withContext esegue il codice in modo sequenziale. Se due richieste di rete indipendenti sono avvolte in un unico withContext, verranno eseguite una dopo l'altra. Per il parallelismo, usa async + await.

// Sequenziale — lento
withContext(Dispatchers.IO) {
    val a = api.fetchA()
    val b = api.fetchB()
}

// Parallelo — veloce
coroutineScope {
    val a = async { api.fetchA() }
    val b = async { api.fetchB() }
    println("${a.await()} ${b.await()}")
}

Errore 3: Dimenticare NonCancellable per operazioni critiche

Se una coroutine viene annullata durante withContext, il blocco su Dispatchers.IO viene anch'esso interrotto. Per le operazioni che devono essere completate a tutti i costi (scrittura database, invio analisi), combina withContext con NonCancellable.

Errore 4: Aggiornare lo stato UI all'interno di un blocco IO

Non aggiornare mai i componenti View all'interno di withContext(Dispatchers.IO). withContext non torna a Main fino al completamento dell'intero blocco. Posiziona gli aggiornamenti UI dopo la parentesi di chiusura di withContext — allora la coroutine sarà già sul thread principale.