viewModelScope: co to je, vazba na ViewModel a fungování v Androidu

Co je viewModelScope v Androidu?

viewModelScope — je rozšiřující vlastnost (extension property) na rozhraní ViewModel, přidaná v knihovně lifecycle-viewmodel-ktx (od verze 2.1.0). Poskytuje hotový CoroutineScope svázaný s životním cyklem ViewModel.

// Vnitřní struktura (zjednodušená)
val ViewModel.viewModelScope: CoroutineScope
    get() {
        val scope = this.getTag(JOB_KEY)
        if (scope != null) return scope
        return CoroutineScope(SupervisorJob() + Dispatchers.Main.immediate)
            .also { setTag(JOB_KEY, it) }
    }

Scope je vytvářen líně (lazy) při prvním přístupu a je ukládán do mezipaměti přes setTag. Používá se SupervisorJob, což znamená, že výjimka v jedné podřízené korutině neruší ostatní. Výchozí dispatcher je Dispatchers.Main.immediate, který spouští kód na hlavním vlákně bez dalšího dispatchování, pokud je volání již na Main.

Jak viewModelScope obdrží oznámení o čištění

Když ViewModel opustí životní cyklus (Activity je dokončena nebo Fragment je odstraněn), systém zavolá clear(), který spustí onCleared(). V tomto callbacku viewModelScope ruší svůj Job, což rekurzivně ukončí všechny aktivní korutiny. Mechanismus je implementován přes rozhraní Closeable, kde je Job scope registrován jako prostředek pro automatické uzavření.

Jak funguje viewModelScope: vazba na životní cyklus ViewModel

Mechanismus vazby viewModelScope na životní cyklus ViewModel je založen na tagování a callbacku onCleared. Podívejme se krok za krokem, jak to funguje.

Krok 1: Vytvoření scope při prvním přístupu

Když ViewModel provádí viewModelScope.launch { ... }, getter zkontroluje, zda existuje uložený scope pod tagem JOB_KEY. Pokud scope ještě není vytvořen — vytvoří se nová instance CoroutineScope(SupervisorJob() + Dispatchers.Main.immediate). Scope je uložen uvnitř ViewModel přes vnitřní mapu tagů.

Krok 2: Životní cyklus korutin

Všechny korutiny spuštěné přes viewModelScope.launch nebo viewModelScope.async se stávají podřízenými vůči SupervisorJob scope. Pracují na hlavním vlákně (pokud není uveden jiný dispatcher přes withContext). Dokud je ViewModel živý — korutiny mohou být aktivní, pozastavené nebo dokončené.

Krok 3: Zrušení při onCleared

Když systém ničí ViewModel, je voláno ViewModel.clear(). Uvnitř clear() dochází k následujícímu:

• Volání onCleared() pro uživatelskou logiku
• Uzavření všech Closeable prostředků registrovaných přes addCloseable
• Job viewModelScope přechází do stavu Cancelled
• Všechny podřízené korutiny jsou rekurzivně rušeny
• Uvolnění referencí na scope pro garbage collector

Odolnost vůči rotaci obrazovky

Při rotaci obrazovky je Activity znovu vytvořeno, ale ViewModel je zachován (díky ViewModelStoreOwner). To znamená, že viewModelScope zůstává aktivní a korutiny pokračují v běhu bez přerušení. Po znovuvytvoření Activity je stejný ViewModel (a stejný scope) použit znovu — načítání dat nezačíná od začátku.

viewModelScope v architektuře MVVM

MVVM (Model-View-ViewModel) — je architektura doporučená Googlem pro Android aplikace. viewModelScope v ní zaujímá ústřední místo jako vykonavatel asynchronních operací.

Role viewModelScope ve vrstvách architektury

ViewModel přes viewModelScope spouští korutiny, uvnitř kterých volá suspend-funkce Repository. Výsledek je převeden na StateFlow, který je sledován UI vrstvou. Toto schéma zajišťuje jasné oddělení odpovědností a testovatelnost každé vrstvy nezávisle.

Proč viewModelScope ve ViewModel, ne ve Fragment

Pokud by korutiny byly spouštěny z Fragmentu, při rotaci obrazovky by byly zrušeny spolu se zničením Fragmentu. ViewModel přežije rotaci, takže korutiny spuštěné v jeho scope pokračují v běhu. To je klíčová výhoda viewModelScope oproti lifecycleScope při načítání dat.

Příklady použití viewModelScope

Podívejme se na tři praktické scénáře použití viewModelScope v Android aplikaci v Kotlin.

Příklad 1: Načítání dat při vytvoření ViewModel

class ProfileViewModel(
    private val repo: ProfileRepository
) : ViewModel() {

    private val _profile = MutableStateFlow<Profile?>(null)
    val profile: StateFlow<Profile?> = _profile

    init {
        loadProfile()
    }

    private fun loadProfile() {
        viewModelScope.launch {
            val result = repo.getProfile()
            _profile.value = result
        }
    }
}

V bloku init je okamžitě spuštěno načítání profilu. Korutina běží na hlavním vlákně (standardně). Repository používá withContext(Dispatchers.IO) pro síťový požadavek uvnitř své suspend-funkce, takže ViewModel se nemusí starat o přepínání vláken.

Příklad 2: Zpracování chyb přes sealed class

sealed class UiState {
    object Loading : UiState()
    data class Success(val data: List<Item>) : UiState()
    data class Error(val message: String) : UiState()
}

fun fetchItems() {
    _state.value = UiState.Loading
    viewModelScope.launch {
        try {
            val items = repo.getItems()
            _state.value = UiState.Success(items)
        } catch (e: Exception) {
            _state.value = UiState.Error(e.message ?: "Unknown error")
        }
    }
}

Stav UI je popsán přes sealed class UiState. ViewModel aktualizuje state při každé změně. Fragment je přihlášen k odběru StateFlow a reaguje pouze na aktuální stav, ignoruje zastaralá volání při opakovaných rotacích.

Příklad 3: Zrušení předchozí korutiny při novém požadavku

private var searchJob: Job? = null

fun search(query: String) {
    searchJob?.cancel()
    searchJob = viewModelScope.launch {
        delay(300)
        val results = repo.search(query)
        _searchResults.value = results
    }
}

Při každém novém vyhledávacím požadavku je předchozí korutina zrušena. delay(300) implementuje debounce — vyhledávání se provede až po 300 ms pauze ve vstupu. To snižuje zatížení serveru a zabraňuje zastaralým výsledkům.

viewModelScope vs lifecycleScope: kdy co zvolit

Oba scope jsou poskytovány knihovnou AndroidX Lifecycle, ale jsou svázány s různými životními cykly. Volba mezi nimi závisí na typu úkolu.

Srovnání scope

Doporučení Google

Google doporučuje používat viewModelScope pro všechny úkoly související s načítáním a zpracováním dat. lifecycleScope by měl být aplikován pro operace vázané na konkrétní okamžik života UI — například spuštění animace při prvním zobrazení obrazovky nebo přihlášení k odběru Location aktualizací, které by měly skončit při opuštění obrazovky.

Typické chyby při práci s viewModelScope

I v dobře zdokumentovaném API Androidu dělají vývojáři charakteristické chyby. Podívejme se na čtyři nejčastější problémy.

Chyba 1: Aktualizace UI po zrušení scope

Nejzákeřnější chyba — pokus o aktualizaci StateFlow nebo LiveData po vyčištění ViewModel. Přestože je viewModelScope zrušen při onCleared(), korutina může provést kód až do okamžiku skutečného zrušení. Použijte isActive pro kontrolu nebo se spolehněte na dokončení catch bloku.

Chyba 2: Spouštění korutin bez ohledu na SupervisorJob

viewModelScope interně používá SupervisorJob, což izoluje chyby mezi korutinami. Ale pokud spustíte korutinu s vlastním Job() uvnitř viewModelScope.launch, tato korutina se stane podřízenou SupervisorJob, ale nebude chráněna před zrušením při chybách v jiných korutinách.

Chyba 3: Příliš mnoho korutin v jednom scope

Ačkoli viewModelScope nemá přísný limit, tisíce aktivních korutin mohou zpomalit systém. Pro dlouhé seznamy dat použijte Flow s collectLatest místo vytváření samostatných korutin pro každý prvek.

Chyba 4: Použití GlobalScope místo viewModelScope

Pokud omylem importujete GlobalScope místo viewModelScope, korutina nebude zrušena při čištění ViewModel. To vede k úniku paměti a potenciálnímu pádu. Vždy kontrolujte, že korutiny jsou spouštěny přes viewModelScope, zejména v zděděných fragmentech.