Existe uma maneira mais eficiente de atualizar propriedades de classe de dados no Jetpack Compose Kotlin?

Com Views, foi recomendado não instanciar novos objetos, especialmente em onDrawfunções que são chamadas várias vezes.

No entanto, no Jetpack Compose, sem saltos fortes , classes de dados com parâmetros mutáveis ​​são desencorajadas porque se a composição ocorrer em funções de escopo que tenham parâmetros instáveis, para classes de dados com parâmetros mutáveis ​​ou classes instáveis ​​de bibliotecas externas, ou outro módulo no seu projeto que não estenda o compilador Compose, ele acionará a recomposição para essa função.

https://developer.android.com/develop/ui/compose/performance/stability#mutable-objects

@Composable
fun ContactRow(contact: Contact, modifier: Modifier = Modifier) {
   var selected by remember { mutableStateOf(false) }

   Row(modifier) {
      ContactDetails(contact)
      ToggleButton(selected, onToggled = { selected = !selected })
   }
}

Na função acima, se você usar uma classe de dados com parâmetros mutáveis, quando a linha selecionada for alterada, o mesmo acontecerá com ContactDetails, mesmo que o contato não tenha sido alterado, porque ContactDetails tem uma entrada instável.

E não há sobrecarga de desempenho observável com a cópia de objetos como car ou mesmo datas com valores primitivos ou classes que contenham valores primitivos ou Strings. Você pode querer considerar apenas se sua classe de dados contém big data, como formato Bitmap ou Base64 de imagem, e mesmo para esse caso, tem que ser alguma cópia profunda.

Mas a função copy do Kotlin é uma cópia superficial . Ela só copia referências a objetos se você não criar novas instâncias.

class Car(
    val id: Int = 0,
    val brand: String = "",
    var model: String = "",
    val year: Int = 2020,
)


data class MyListClass(val currentCar: Car, val items: List<Car>)

    @Preview
    @Composable
    fun TestCopy() {
        var myListClass by remember {
            mutableStateOf(MyListClass(
                currentCar = Car(),
                items = List(10) {
                    Car()
                }
            ))
        }
        Button(
            onClick = {
                val temp = myListClass
    
                myListClass = myListClass.copy(
                    currentCar = Car(id = 1)
                )
    
                println("temp===myListClass ${temp === myListClass}\n" +
                        "temp car===zmyListClass car ${temp.currentCar === myListClass.currentCar}\n" +
                        "temp list===myListClass ${temp.items === myListClass.items}")
            }
        ) {
            Text("Copy...")
        }
    }

Impressões

 I  temp===myListClass false
 I  temp car===zmyListClass car false
 I  tem list===myListClass true

No entanto, se você ainda quiser otimizá-lo não criando um novo objeto de suporte, você pode usar vars com a anotação @Stable, que não é necessária com pulos fortes, o que impediria a recomposição da sua função se suas entradas não tivessem mudado quando outra Stateou uma mudança de entradas da função pai acionasse a recomposição no escopo pai.

E acione a recomposição quando as propriedades do seu carro mudarem, como

Usando outra SnapshotMutationPolicy

A política padrão do MutableState é structuralEqualityPolicy()que verifica se o novo valueque você definiu é ==para o anterior. Em classes de dados, equals é determinado por parâmetros do construtor primário.

@Suppress("UNCHECKED_CAST")
fun <T> structuralEqualityPolicy(): SnapshotMutationPolicy<T> =
    StructuralEqualityPolicy as SnapshotMutationPolicy<T>

private object StructuralEqualityPolicy : SnapshotMutationPolicy<Any?> {
    override fun equivalent(a: Any?, b: Any?) = a == b

    override fun toString() = "StructuralEqualityPolicy"
}

Ao alterar esta política, você pode acionar a recomposição mesmo com o mesmo objeto, como

@Stable
data class Car(
    val id: Int = 0,
    val brand: String = "",
    var model: String = "",
    val year: Int = 2020,
)

@Preview
@Composable
fun CarScreen() {
    var car by remember {
        mutableStateOf(
            value = Car(),
            policy = neverEqualPolicy()
        )
    }

    Column {
        TextField(
            value = car.brand,
            onValueChange = { newBrand ->
                car = car.copy(brand = newBrand) // Using `copy()`
            },
            label = { Text("Brand") }
        )

        TextField(
            value = car.model,
            onValueChange = { newModel ->
//                car = car.copy(model = newModel) // Using `copy()`

                car = car.apply {
                    model = newModel
                }
            },
            label = { Text("Model") }
        )

        Text("Car brand: ${car.brand}, model: ${car.model}")
    }
}

Como você pode ver com neverEqualPolicy()a política, você pode acionar a recomposição atribuindo o mesmo objeto.

Aplica-se a qualquer classe. Você pode acionar a recomposição definindo o valor do contador para o mesmo valor.

Usando uma classe com MutableStates

Essa abordagem é amplamente usada nas classes rememberXState e no exemplo Jetsnack do Google.

ScrollState , estado de pesquisa do jetsnack

@Stable
class CarUiState(
    brand: String = "",
    model: String = "",
) {

    var id: Int = 0
    var year: Int = 2020

    var brand by mutableStateOf(brand)
    var model by mutableStateOf(model)
}

@Preview
@Composable
fun CarScreen() {

    val carUiState = remember {
        CarUiState()
    }
    Column {
        TextField(
            value = carUiState.brand,
            onValueChange = { newBrand ->
                carUiState.brand = newBrand
            },
            label = { Text("Brand") }
        )

        TextField(
            value = carUiState.model,
            onValueChange = { newModel ->
                carUiState.model = newModel
            },
            label = { Text("Model") }
        )

        Text("Car brand: ${carUiState.brand}, model: ${carUiState.model}, year: ${carUiState.year}")
    }
}

Você simplesmente divide sua classe entre propriedades que devem acionar a recomposição e outras propriedades que não exigem isso, pois elas também seriam alteradas quando a recomposição fosse acionada.

Para habilitar o salto forte no conjunto de arquivos Gradle

composeCompiler {
    // Configure compose compiler options if required
    enableStrongSkippingMode = true
}

Portanto, as alterações acima seriam aplicadas às classes, lambdas e funções

Composables com parâmetros instáveis ​​podem ser ignorados.

Parâmetros instáveis ​​são comparados para igualdade por meio de igualdade de instância (===)

Parâmetros estáveis ​​continuam a ser comparados para igualdade com Object.equals()

Todos os lambdas em funções composable são automaticamente lembrados. Isso significa que você não precisará mais envolver lambdas em remember para garantir que um composable que use um lambda, pule.

Cuidado com as sugestões feitas nos comentários. Se você mudar valpara var, você quebrará a funcionalidade do seu aplicativo, pois o Compose não pode observar mudanças em variáveis ​​mutáveis.

data class Car(
    val id: Int = 0, var brand: String = "", val model: String = "", val year: Int = 2020
)

onValueChange = { newBrand ->
    car.brand = newBrand   // This will not work!
}

Como resultado, quando você digitar, o Jetpack Compose não acionará mais uma recomposição, e você não verá nada aparecendo no seu arquivo TextField.

No Jetpack Compose, eu consideraria absolutamente comum armazenar todos os valores de um formulário dentro de um único data class. Você não deve se preocupar com problemas de desempenho aqui até que realmente os tenha.