Pare de criar God ViewModels: um ViewModel por composable, não por tela

Visão Geral

O padrão "uma tela = um ViewModel" virou regra silenciosa no Android, mas ele amarra o ciclo de vida do ViewModel à Activity, Fragment ou destino de navegação. O resultado são os God ViewModels: classes enormes que seguram estado de diálogos, abas e páginas de pager, vivem mais do que a UI que servem e desperdiçam memória.

O problema do escopo tradicional

• ViewModels persistem por mais tempo do que o necessário
• Estado temporário de UI ocupa memória à toa
• Páginas de um pager compartilham estado sem querer
• O momento de limpeza (onCleared) fica ambíguo em UIs dinâmicas

O que há de novo

Duas APIs do Lifecycle permitem dar a um composable seu próprio ViewModelStoreOwner:

• rememberViewModelStoreOwner() — escopa um ViewModel ao tempo de vida de um composable específico
• rememberViewModelStoreProvider() — cria owners independentes para itens de pagers, abas e listas

Exemplo prático

Escopando um ViewModel a um trecho da composição:

Kotlin
Copiar
1@Composable
2fun DetailDialog() {
3    val storeOwner = rememberViewModelStoreOwner()
4    CompositionLocalProvider(LocalViewModelStoreOwner provides storeOwner) {
5        val viewModel: DialogViewModel = viewModel()
6        // O ViewModel é limpo quando este composable sai da composição
7    }
8}

ViewModels independentes por página de um pager:

Kotlin
Copiar
1val provider = rememberViewModelStoreProvider()
2
3HorizontalPager(state = pagerState) { page ->
4    val owner = provider.getViewModelStoreOwner(key = page)
5    CompositionLocalProvider(LocalViewModelStoreOwner provides owner) {
6        val pageVm: PageViewModel = viewModel()
7    }
8}

Quando usar

Bons candidatos: diálogos, bottom sheets, páginas de pager, painéis expansíveis e fluxos de feature aninhados. Evite escopar componentes triviais e sem estado — o custo não compensa.

A ideia central

Mudanças de configuração continuam funcionando normalmente. O princípio é: a UI define o ciclo de vida, e não o contrário — alinhando a posse do ViewModel à estrutura real da composição.