withContext: co to jest, zmiana kontekstu i działanie w korutynach

Czym jest withContext w Kotlinie?

withContext — to funkcja zawieszająca z pakietu kotlinx.coroutines, która wykonuje przekazany blok kodu w zadanym CoroutineContext i zwraca wynik z powrotem do pierwotnego kontekstu. Sygnatura funkcji wygląda następująco:

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

Parametr context przyjmuje dowolny CoroutineContext — najczęściej jeden ze standardowych Dispatchers.IO, Dispatchers.Default lub Dispatchers.Main. Blok wykonuje się właśnie w tym kontekście, a wynik jest zwracany tam, skąd został wywołany withContext.

Kluczowa cecha: automatyczny powrót

Po zakończeniu lambdy withContext gwarantowanie przełącza wykonanie z powrotem na pierwotny dyspozytor. Oznacza to, że programista nie musi ręcznie wywoływać withContext(Dispatchers.Main) po operacji w tle — powrót następuje automatycznie. Takie zachowanie zostało ustalone w specyfikacji Kotlin Coroutines od wersji 1.3.

Gdzie stosuje się withContext

Tworzenie aplikacji na Androida — główny obszar zastosowania withContext. Typowy scenariusz: ViewModel uruchamia korutynę na głównym wątku, wewnątrz wywoływany jest withContext(Dispatchers.IO) dla żądania sieciowego, a wynik po automatycznym powrocie do Main jest używany do aktualizacji UI. Takie podejście leży u podstaw architektury MVVM i jest zalecane przez Google w oficjalnym przewodniku po korutynach.

Jak działa withContext: przełączanie dyspozytorów

Aby zrozumieć withContext, trzeba poznać CoroutineContext i jego kluczowy komponent — dyspozytora (Dispatcher). Każda współprograma ma zestaw elementów kontekstu, wśród których dyspozytor określa, na którym wątku lub puli wątków wykonywany jest kod.

Standardowe dyspozytory dla withContext

Ważne jest, aby zrozumieć, że withContext nie tworzy nowej korutyny — on tylko przełącza kontekst dla istniejącej. To kluczowa różnica w stosunku do launch i async, które tworzą nowe współprogramy. Wewnętrzna implementacja withContext jest zoptymalizowana: jeśli żądany kontekst jest zgodny z bieżącym, przełączenie nie następuje — funkcja wykonuje się na tym samym dyspozytorze.

Kiedy withContext NIE przełącza wątku

Dispatchers.Main wewnątrz withContext(Dispatchers.Main) nie powoduje przełączenia — Kotlin Coroutines rozpoznaje identyczność kontekstów i pomija zbędną operację. Podobnie withContext(Dispatchers.Default) wewnątrz korutyny już działającej na Default nie generuje narzutu. Ta optymalizacja jest zaimplementowana w ContinuationInterceptor.

withContext vs launch i async: kiedy co wybrać

Początkujący często mylą withContext z launch i async, ponieważ wszystkie trzy funkcje pracują z korutynami i kontekstem. Jednak ich przeznaczenie zasadniczo się różni.

Porównanie trzech funkcji

Zasada wyboru

Jeśli trzeba wykonać jedną operację w wątku tła i uzyskać wynik — użyj withContext. Jeśli trzeba uruchomić kilka niezależnych operacji równolegle — użyj async z await. Jeśli wynik nie jest potrzebny (logowanie, zapis cache) — launch. Google zaleca withContext jako preferowane narzędzie dla warstwy Repository w architekturze Androida.

Przykłady kodu z withContext

Rozważmy trzy praktyczne scenariusze użycia withContext w aplikacjach na Androida w Kotlinie. Każdy przykład demonstruje konkretne zadanie i prawidłowy wzorzec.

Przykład 1: Żądanie sieciowe w Repository

ViewModel wywołuje metodę repozytorium z korutyny na Main. Wewnątrz withContext(Dispatchers.IO) wykonywane jest żądanie HTTP, a wynik jest zwracany automatycznie:

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

Korutyna w ViewModel wywołuje getUser tak samo jak zwykłą funkcję zawieszającą — bez jawnego określania dyspozytora. withContext ukrywa szczegóły przełączania wątków.

Przykład 2: Dwie sekwencyjne operacje w tle

Gdy trzeba wykonać kilka operacji IO jedna po drugiej, withContext łączy je w jeden blok. Jest to bardziej efektywne niż owijanie każdej operacji w osobny withContext:

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

Obie operacje wykonują się na Dispatchers.IO, a wynik Profile jest tworzony i zwracany bez zbędnych przełączeń kontekstu. Jeśli operacje są niezależne, lepiej użyć async do równoległego wykonania.

Przykład 3: Mieszany kontekst z NonCancellable

W niektórych scenariuszach trzeba wykonać kod, którego nie można anulować — na przykład zapis stanu przy zamykaniu ekranu. Kombinacja withContext + NonCancellable rozwiązuje to zadanie:

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

Operator + łączy dwa elementy kontekstu: dyspozytor IO i flagę NonCancellable. Blok wykonuje się nawet jeśli nadrzędna korutyna została anulowana — jest to przydatne dla operacji finalizujących.

Co dzieje się pod maską: Continuation i optymalizacje

Wewnętrzna implementacja withContext opiera się na mechanizmie Continuation — centralnej abstrakcji korutyn Kotlina. Każdy punkt zawieszenia (suspend point) zapisuje stan wykonania w obiekcie Continuation i withContext nie jest wyjątkiem.

Jak withContext przełącza kontekst na poziomie bajtkodu

Kompilator Kotlina transluje withContext na wywołanie metody withContext z kotlinx.coroutines, która wewnętrznie tworzy nową instancję DispatchedContinuation. Ten obiekt opakowuje oryginalny Continuation i zastępuje w nim dyspozytora. Jeśli nowy dyspozytor różni się od bieżącego, wykonanie jest zawieszane, blok wysyłany do odpowiedniej puli wątków, a po zakończeniu — wznawiane z pierwotnym kontekstem.

Optymalizacja: fast-path przy zgodności kontekstów

Gdy withContext jest wywoływany z tym samym dyspozytorem, na którym już działa korutyna, Kotlin uruchamia fast-path: blok wykonuje się synchronicznie, bez tworzenia DispatchedContinuation i bez przekazywania do puli wątków. To sprawia, że withContext jest praktycznie darmowy przy ponownych wywołaniach z tym samym kontekstem. Według benchmarków JetBrains (kotlinx.coroutines 1.8), fast-path wykonuje się poniżej 0,1 μs.

Ograniczenia z punktu widzenia wydajności

Każde wywołanie withContext z innym dyspozytorem tworzy nowy DispatchedContinuation i wymaga przełączenia wątków — zajmuje to od 1 do 5 μs w zależności od obciążenia. Dla większości aplikacji takie opóźnienie jest niezauważalne, ale w pętlach z tysiącami iteracji warto agregować operacje w jeden blok withContext.

Typowe błędy przy użyciu withContext

Nawet doświadczeni programiści popełniają błędy podczas pracy z withContext. Rozważmy cztery najczęstsze problemy i sposoby ich zapobiegania.

Błąd 1: Zagnieżdżone withContext bez potrzeby

Programiści często owijają każdą linię w osobny withContext, zamiast połączyć operacje w jeden blok. Każde zbędne wywołanie z innym dyspozytorem generuje narzut.

Prawidłowo: połączyć sekwencyjne operacje IO w jeden withContext(Dispatchers.IO) { ... }. Jeśli część operacji jest CPU-intensywna — użyj withContext(Dispatchers.Default) wewnątrz tego samego bloku.

Błąd 2: Używanie withContext zamiast async dla zadań równoległych

withContext wykonuje kod sekwencyjnie. Jeśli dwa niezależne żądania sieciowe są owinięte w jeden withContext, będą wykonywane jedno po drugim. Dla równoległości używaj async + await.

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

// Równolegle — szybko
coroutineScope {
    val a = async { api.fetchA() }
    val b = async { api.fetchB() }
    println("${a.await()} ${b.await()}")
}

Błąd 3: Zapomnienie o NonCancellable przy krytycznych operacjach

Jeśli korutyna zostanie anulowana podczas withContext, blok na Dispatchers.IO również zostanie przerwany. Dla operacji, które muszą się zakończyć za wszelką cenę (zapis do bazy danych, wysłanie analityki), łącz withContext z NonCancellable.

Błąd 4: Zmiana stanu UI wewnątrz bloku IO

Nigdy nie aktualizuj komponentów View wewnątrz withContext(Dispatchers.IO). withContext nie wraca do Main aż do zakończenia całego bloku. Aktualizację UI wykonuj po zamykającym nawiasie withContext — wtedy korutyna będzie już na głównym wątku.