Siga as práticas recomendadas

Você pode encontrar armadilhas comuns do Compose. Esses erros podem criar um código que parece funcionar bem, mas que também pode prejudicar a performance da IU. Siga as práticas recomendadas para otimizar seu app no Compose.

Usar remember para minimizar os cálculos caros

As funções de composição podem ser executadas com muita frequência, até mesmo para todos os frames de uma animação. Por isso, faça o menor cálculo possível no corpo da função.

Uma técnica importante é armazenar os resultados dos cálculos com remember. Dessa forma, o cálculo é executado uma vez, e você pode buscar os resultados sempre que necessário.

Por exemplo, confira um código que mostra uma lista de nomes classificados, mas faz a classificação de uma maneira muito cara:

@Composable
fun ContactList(
    contacts: List<Contact>,
    comparator: Comparator<Contact>,
    modifier: Modifier = Modifier
) {
    LazyColumn(modifier) {
        // DON’T DO THIS
        items(contacts.sortedWith(comparator)) { contact ->
            // ...
        }
    }
}

Toda vez que o elemento ContactsList é recomposto, toda a lista de contatos é classificada novamente, mesmo que ela não tenha mudado. Se o usuário rolar a lista, a função de composição vai ser recomposta sempre que uma nova linha aparecer.

Para resolver esse problema, classifique a lista fora de LazyColumn e armazene a lista ordenada com remember:

@Composable
fun ContactList(
    contacts: List<Contact>,
    comparator: Comparator<Contact>,
    modifier: Modifier = Modifier
) {
    val sortedContacts = remember(contacts, comparator) {
        contacts.sortedWith(comparator)
    }

    LazyColumn(modifier) {
        items(sortedContacts) {
            // ...
        }
    }
}

Agora, a lista é classificada uma vez, quando a ContactList é composta pela primeira vez. Se os contatos ou o comparador mudarem, a lista classificada vai ser gerada novamente. Caso contrário, o elemento de composição pode continuar usando a lista classificada em cache.

Usar chaves de layout lentas

Os layouts lentos reutilizam itens com eficiência, regenerando ou recompondo apenas quando necessário. No entanto, você pode ajudar a otimizar layouts lentos para recomposição.

Suponha que uma operação do usuário faça com que um item seja movido na lista. Por exemplo, suponha que você mostre uma lista de notas classificadas por hora de modificação com a nota modificada mais recentemente na parte de cima.

@Composable
fun NotesList(notes: List<Note>) {
    LazyColumn {
        items(
            items = notes
        ) { note ->
            NoteRow(note)
        }
    }
}

No entanto, há um problema com esse código. Suponha que a observação inferior seja alterada. Ela passa a ser a nota modificada mais recentemente e, portanto, ela vai para o topo da lista, e todas as outras descem uma posição.

Sem sua ajuda, o Compose não percebe que os itens inalterados estão apenas sendo movidos na lista. Em vez disso, o Compose acha que o "item 2" antigo foi excluído e um novo foi criado para o item 3, o item 4 e assim por diante. O resultado é que o Compose recompõe todos os itens da lista, mesmo que apenas um deles tenha mudado.

A solução aqui é fornecer chaves de item. Fornecer uma chave estável para cada item permite que o Compose evite recomposições desnecessárias. Nesse caso, o Compose pode determinar que o item agora no local 3 é o mesmo que estava no local 2. Como nenhum dos dados desse item foi alterado, o Compose não precisa recompor.

@Composable
fun NotesList(notes: List<Note>) {
    LazyColumn {
        items(
            items = notes,
            key = { note ->
                // Return a stable, unique key for the note
                note.id
            }
        ) { note ->
            NoteRow(note)
        }
    }
}

Usar derivedStateOf para limitar as recomposições

Um risco de usar o estado nas composições é que, se ele muda rapidamente, a IU pode ser recomposta mais do que o necessário. Por exemplo, suponha que você esteja mostrando uma lista rolável. Você examina o estado da lista para ver qual item é o primeiro visível na lista:

val listState = rememberLazyListState()

LazyColumn(state = listState) {
    // ...
}

val showButton = listState.firstVisibleItemIndex > 0

AnimatedVisibility(visible = showButton) {
    ScrollToTopButton()
}

O problema é que, se o usuário rola a lista, o listState muda constantemente, conforme o usuário arrasta o dedo. Isso significa que a lista está sendo recomposta constantemente. No entanto, você não precisa recompor com tanta frequência. Não é necessário recompor até que um novo item fique visível na parte de baixo. Isso exige muitos cálculos desnecessários, o que faz com que a IU tenha uma performance ruim.

A solução é usar um estado derivado. O estado derivado permite que o Compose informe quais mudanças de estado realmente acionam a recomposição. Nesse caso, especifique quando o primeiro item visível muda. Quando esse valor de estado muda, a IU precisa ser recomposta, mas se o usuário ainda não tiver rolado o suficiente para trazer um novo item para a parte de cima, ela não precisará ser recomposta.

val listState = rememberLazyListState()

LazyColumn(state = listState) {
    // ...
}

val showButton by remember {
    derivedStateOf {
        listState.firstVisibleItemIndex > 0
    }
}

AnimatedVisibility(visible = showButton) {
    ScrollToTopButton()
}

Adiar leituras pelo maior tempo possível

Quando um problema de desempenho é identificado, o adiamento de leituras de estado pode ajudar. Adiar leituras de estado garante que o Compose execute novamente o mínimo possível de código na recomposição. Por exemplo, se a IU tiver um estado elevado no lugar da árvore combinável e você ler o estado em um elemento combinável filho, vai ser possível unir o estado de leitura em uma função lambda. Isso faz com que a leitura ocorra somente quando necessário. Para referência, consulte a implementação no app de exemplo Jetsnack. O Jetsnack implementa um efeito do tipo "barra de ferramentas recolhível" na tela de detalhes. Para entender por que essa técnica funciona, consulte a postagem do blog Jetpack Compose: como depurar a recomposição (link em inglês).

Para conseguir esse efeito, a função de composição Title precisa do deslocamento de rolagem para se deslocar usando um Modifier. Confira uma versão simplificada do código do Jetsnack antes da otimização:

@Composable
fun SnackDetail() {
    // ...

    Box(Modifier.fillMaxSize()) { // Recomposition Scope Start
        val scroll = rememberScrollState(0)
        // ...
        Title(snack, scroll.value)
        // ...
    } // Recomposition Scope End
}

@Composable
private fun Title(snack: Snack, scroll: Int) {
    // ...
    val offset = with(LocalDensity.current) { scroll.toDp() }

    Column(
        modifier = Modifier
            .offset(y = offset)
    ) {
        // ...
    }
}

Quando o estado de rolagem muda, o Compose invalida o escopo de recomposição pai mais próximo. Nesse caso, o escopo mais próximo é a função de composição SnackDetail. Observe que Box é uma função inline e, portanto, não é um escopo de recomposição. Assim, o Compose recompõe SnackDetail e todas as funções de composição dentro de SnackDetail. Se você mudar o código para ler apenas o estado em que ele é usado, vai ser possível reduzir o número de elementos que precisam ser recompostos.

@Composable
fun SnackDetail() {
    // ...

    Box(Modifier.fillMaxSize()) { // Recomposition Scope Start
        val scroll = rememberScrollState(0)
        // ...
        Title(snack) { scroll.value }
        // ...
    } // Recomposition Scope End
}

@Composable
private fun Title(snack: Snack, scrollProvider: () -> Int) {
    // ...
    val offset = with(LocalDensity.current) { scrollProvider().toDp() }
    Column(
        modifier = Modifier
            .offset(y = offset)
    ) {
        // ...
    }
}

O parâmetro de rolagem agora é uma lambda. Isso significa que o Title ainda pode fazer referência ao estado elevado, mas o valor só é lido dentro de Title, onde é realmente necessário. Como resultado, quando o valor de rolagem mudar, o escopo de recomposição mais próximo vai ser o elemento de composição Title. O Compose não precisa mais recompor toda a Box.

Essa é uma boa melhoria, mas você pode fazer ainda melhor. Verifique se você não está fazendo a recomposição apenas para mudar o layout ou redesenhar um elemento de composição. Neste caso, você só está mudando o deslocamento do elemento de composição Title, o que pode ser feito na fase de layout.

@Composable
private fun Title(snack: Snack, scrollProvider: () -> Int) {
    // ...
    Column(
        modifier = Modifier
            .offset { IntOffset(x = 0, y = scrollProvider()) }
    ) {
        // ...
    }
}

Anteriormente, o código usava Modifier.offset(x: Dp, y: Dp), que recebe o deslocamento como um parâmetro. Ao mudar para a versão lambda do modificador, você garante que a função leia o estado de rolagem na fase de layout. Como resultado, quando o estado de rolagem muda, o Compose pode pular completamente a fase de composição e ir diretamente para a fase de layout. Ao transmitir com frequência mudanças de variáveis de estado em modificadores, use as versões lambda dos modificadores sempre que possível.

Confira outro exemplo dessa abordagem. Este código ainda não foi otimizado:

// Here, assume animateColorBetween() is a function that swaps between
// two colors
val color by animateColorBetween(Color.Cyan, Color.Magenta)

Box(
    Modifier
        .fillMaxSize()
        .background(color)
)

Aqui, a cor de fundo da caixa alterna rapidamente entre duas cores. Esse estado muda com muita frequência. A função de composição lê esse estado no modificador em segundo plano. Como resultado, a caixa precisa ser recomposta em cada frame, já que a cor muda em cada um.

Para melhorar isso, use um modificador baseado em lambda, neste caso, drawBehind. Isso significa que o estado da cor só é lido durante a fase de exibição. Como resultado, o Compose pode pular completamente as fases de composição e de layout. Quando a cor muda, o Compose vai direto para a fase de exibição.

val color by animateColorBetween(Color.Cyan, Color.Magenta)
Box(
    Modifier
        .fillMaxSize()
        .drawBehind {
            drawRect(color)
        }
)

Evitar gravações inversas

O Compose tem como base a suposição que você nunca vai gravar em um estado que já foi lido. Isso é conhecido como gravação inversa e pode fazer com que a recomposição ocorra em cada frame, indefinidamente.

O elemento combinável abaixo mostra um exemplo desse tipo de erro.

@Composable
fun BadComposable() {
    var count by remember { mutableIntStateOf(0) }

    // Causes recomposition on click
    Button(onClick = { count++ }, Modifier.wrapContentSize()) {
        Text("Recompose")
    }

    Text("$count")
    count++ // Backwards write, writing to state after it has been read</b>
}

Esse código atualiza a contagem no final do elemento combinável depois de lê-lo na linha anterior. Ao executar esse código, você vai notar que, depois de clicar no botão, o que causa uma recomposição, o contador aumenta rapidamente em um loop infinito. Conforme o Compose faz a recomposição desse elemento, ele encontra uma leitura de estado desatualizada e programa outra recomposição.

Nunca gravar no estado da composição evita gravações inversas. Se possível, grave sempre no estado em resposta a um evento e em uma lambda, como no exemplo onClick anterior.

Outros recursos