withContext: co to je, změna kontextu a práce v korutinách

Co je withContext v Kotlinu?

withContext — pozastavující funkce z balíčku kotlinx.coroutines, která provádí předaný blok kódu v zadaném CoroutineContext a vrací výsledek zpět do původního kontextu. Signatura funkce vypadá takto:

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

Parametr context přijímá libovolný CoroutineContext — nejčastěji jeden ze standardních Dispatchers.IO, Dispatchers.Default nebo Dispatchers.Main. Blok se provádí přesně v tomto kontextu a výsledek se vrací tam, odkud byl withContext volán.

Klíčová vlastnost: automatický návrat

Po dokončení lambdy withContext zaručeně přepne provádění zpět na původní dispečer. To znamená, že vývojář nemusí ručně volat withContext(Dispatchers.Main) po operaci na pozadí — návrat probíhá automaticky. Toto chování je stanoveno ve specifikaci Kotlin Coroutines od verze 1.3.

Kde se withContext používá

Vývoj pro Android — hlavní oblast použití withContext. Typický scénář: ViewModel spouští korutinu na hlavním vlákně, uvnitř se volá withContext(Dispatchers.IO) pro síťový požadavek a výsledek se po automatickém návratu na Main používá k aktualizaci UI. Tento přístup tvoří základ architektury MVVM a je doporučován Googlem v oficiálním průvodci korutinami.

Jak funguje withContext: přepínání dispečerů

Pro pochopení withContext je třeba se seznámit s CoroutineContext a jeho klíčovou komponentou — dispečerem (Dispatcher). Každá korutina má sadu kontextových prvků, mezi nimiž dispečer určuje, na kterém vlákně nebo fondu vláken se kód provádí.

Standardní dispečeři pro withContext

Je důležité pochopit, že withContext nevytváří novou korutinu — pouze mění kontext pro existující. To je klíčový rozdíl oproti launch a async, které vytvářejí nové korutiny. Vnitřní implementace withContext je optimalizována: pokud se požadovaný kontext shoduje s aktuálním, k přepnutí nedochází — funkce se provádí na stejném dispečeru.

Kdy withContext NEPřepíná vlákno

Dispatchers.Main uvnitř withContext(Dispatchers.Main) nezpůsobuje přepnutí — Kotlin Coroutines rozpozná identitu kontextů a přeskočí zbytečnou operaci. Podobně withContext(Dispatchers.Default) uvnitř korutiny již běžící na Default nevytváří režii. Tato optimalizace je implementována v ContinuationInterceptor.

withContext vs launch a async: kdy co vybrat

Začátečníci často zaměňují withContext s launch a async, protože všechny tři funkce pracují s korutinami a kontextem. Jejich účel je však zásadně odlišný.

Porovnání tří funkcí

Pravidlo výběru

Pokud potřebujete provést jednu operaci na vlákně na pozadí a získat výsledek — použijte withContext. Pokud potřebujete spustit několik nezávislých operací paralelně — použijte async s await. Pokud výsledek není potřeba (logování, zápis cache) — launch. Google doporučuje withContext jako preferovaný nástroj pro vrstvu Repository v architektuře Android.

Příklady kódu s withContext

Podívejme se na tři praktické scénáře použití withContext v Android aplikacích v Kotlinu. Každý příklad ukazuje konkrétní úkol a správný vzor.

Příklad 1: Síťový požadavek v Repository

ViewModel volá metodu repozitáře z korutiny na Main. Uvnitř withContext(Dispatchers.IO) se provádí HTTP požadavek a výsledek se automaticky vrací:

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

Korutina ve ViewModelu volá getUser stejně jako běžnou pozastavující funkci — bez explicitního uvedení dispečera. withContext skrývá detaily přepínání vláken.

Příklad 2: Dvě sekvenční operace na pozadí

Když je třeba provést několik IO operací jednu po druhé, withContext je spojí do jednoho bloku. To je efektivnější než zabalit každou operaci do samostatného withContext:

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

Obě operace se provádějí na Dispatchers.IO a výsledek Profile se vytváří a vrací bez zbytečných přepnutí kontextu. Pokud jsou operace nezávislé, je lepší použít async pro paralelní provádění.

Příklad 3: Smíšený kontext s NonCancellable

V některých scénářích je třeba provést kód, který nelze zrušit — například uložení stavu při zavírání obrazovky. Kombinace withContext + NonCancellable řeší tento úkol:

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

Operátor + kombinuje dva kontextové prvky: IO dispečer a příznak NonCancellable. Blok se provádí, i když byla nadřazená korutina zrušena — to je užitečné pro finalizační operace.

Co se děje pod kapotou: Continuation a optimalizace

Vnitřní implementace withContext se opírá o mechanismus Continuation — centrální abstrakci korutin Kotlin. Každý bod pozastavení (suspend point) ukládá stav provádění do objektu Continuation a withContext není výjimkou.

Jak withContext přepíná kontext na úrovni bytekódu

Kotlin překladač překládá withContext na volání metody withContext z kotlinx.coroutines, která interně vytváří novou instanci DispatchedContinuation. Tento objekt obaluje původní Continuation a nahrazuje v něm dispečera. Pokud se nový dispečer liší od aktuálního, provádění je pozastaveno, blok je odeslán do příslušného fondu vláken a po dokončení — obnoveno s původním kontextem.

Optimalizace: fast-path při shodě kontextů

Když je withContext volán se stejným dispečerem, na kterém již korutina běží, Kotlin aktivuje fast-path: blok se provádí synchronně, bez vytváření DispatchedContinuation a bez odesílání do fondu vláken. To činí withContext prakticky zdarma při opakovaných voláních se stejným kontextem. Podle benchmarků JetBrains (kotlinx.coroutines 1.8) se fast-path provádí za méně než 0,1 μs.

Omezení z hlediska výkonu

Každé volání withContext s jiným dispečerem vytváří nový DispatchedContinuation a vyžaduje přepnutí vlákna — to trvá 1 až 5 μs v závislosti na zatížení. Pro většinu aplikací je toto zpoždění nepostřehnutelné, ale ve smyčkách s tisíci iteracemi je lepší agregovat operace do jednoho bloku withContext.

Typické chyby při používání withContext

I zkušení vývojáři dělají chyby při práci s withContext. Podívejme se na čtyři nejčastější problémy a způsoby jejich prevence.

Chyba 1: Vnořené withContext bez potřeby

Vývojáři často balí každý řádek do samostatného withContext, místo aby spojili operace do jednoho bloku. Každé další volání s jiným dispečerem vytváří režii.

Správně: spojte sekvenční IO operace do jednoho withContext(Dispatchers.IO) { ... }. Pokud je část operací CPU-intenzivní — použijte withContext(Dispatchers.Default) uvnitř stejného bloku.

Chyba 2: Použití withContext místo async pro paralelní úlohy

withContext provádí kód sekvenčně. Pokud jsou dva nezávislé síťové požadavky zabaleny do jednoho withContext, budou prováděny jeden po druhém. Pro paralelismus použijte async + await.

// Sekvenční — pomalé
withContext(Dispatchers.IO) {
    val a = api.fetchA()
    val b = api.fetchB()
}

// Paralelní — rychlé
coroutineScope {
    val a = async { api.fetchA() }
    val b = async { api.fetchB() }
    println("${a.await()} ${b.await()}")
}

Chyba 3: Zapomenutí na NonCancellable u kritických operací

Pokud je korutina zrušena během withContext, blok na Dispatchers.IO je také přerušen. Pro operace, které musí být dokončeny za každou cenu (zápis do databáze, odeslání analytiky), kombinujte withContext s NonCancellable.

Chyba 4: Změna stavu UI uvnitř IO bloku

Nikdy neaktualizujte View komponenty uvnitř withContext(Dispatchers.IO). withContext se nevrací na Main až do dokončení celého bloku. Aktualizaci UI proveďte po uzavírací závorce withContext — tehdy bude korutina již na hlavním vlákně.