Recomposition reruns composable functions whose observed state may have changed. It is normal and usually inexpensive; performance problems come from unnecessary invalidation, unstable inputs or expensive work performed during composition.
Practical guidance
- Read state as close as possible to where it is used.
- Pass stable values and event lambdas to reusable composables.
- Use remember for calculation caching, not as a replacement for persistent state.
- Use derivedStateOf when a frequently changing input produces a less frequently changing result.
Working example
@Composable
fun UserRow(user: User, onOpen: (Long) -> Unit) {
ListItem(
headlineContent = { Text(user.name) },
modifier = Modifier.clickable { onOpen(user.id) }
)
}
val showButton by remember { derivedStateOf { listState.firstVisibleItemIndex > 0 } }Common mistakes
- Doing sorting, parsing or allocation directly in a frequently recomposed body.
- Mutating a plain collection without observable state.
- Using a changing object as an effect key accidentally restarts work.
Key takeaway
Measure before optimizing. Correct state ownership and stable inputs usually matter more than trying to prevent every recomposition.