Every Favorite Tap Was Redrawing Every Visible Wallpaper — Stopping Needless Recomposition in Compose, Measured

Make the model stable — @Immutable and immutable collections

There are two ways to fix it. One is to make the model genuinely immutable and tell the compiler so. The other is to lean on strong skipping mode. I made the first my main approach. If I can guarantee the data is immutable myself, the behavior is easier to reason about.

import androidx.compose.runtime.Immutable
import kotlinx.collections.immutable.ImmutableList
import kotlinx.collections.immutable.toImmutableList
 
@Immutable
data class WallpaperItem(
    val id: String,
    val thumbnailUrl: String,
    val tags: ImmutableList<String>,   // immutable collection -> stable
    val isFavorite: Boolean,           // var becomes val; hold state outside
)
 
// Build it once, immutably
fun List<Wallpaper>.toUiItems(favorites: Set<String>): ImmutableList<WallpaperItem> =
    map { w ->
        WallpaperItem(
            id = w.id,
            thumbnailUrl = w.thumbUrl,
            tags = w.tags.toImmutableList(),
            isFavorite = w.id in favorites,
        )
    }.toImmutableList()

@Immutable is an annotation that promises the compiler "instances of this class have no observable changes after construction." If you break the promise (the contents change later), the screen stops updating, so only add it when the type really is immutable. Using ImmutableList from kotlinx.collections.immutable makes the collection type count as stable too.

Enabling strong skipping mode (Compose 2.0 and later) lets even Composables with unstable arguments skip "as long as the instance is the same reference," which softens this whole class of problem considerably. Still, I wanted the model's immutability to be explicit in the design, so I turned strong skipping on as a safety net while also stabilizing the data class itself.

Move favorite state outside the item

If you bake isFavorite into the item model, changing a single favorite means rebuilding the whole list, and every item ends up being "a different value" and recomposes anyway. I held the favorites set one level up and passed each cell only "am I a favorite?", carved out with derivedStateOf.

@Composable
fun WallpaperGrid(
    items: ImmutableList<WallpaperItem>,
    favorites: SnapshotStateMap<String, Boolean>,
    onToggleFavorite: (String) -> Unit,
) {
    LazyVerticalGrid(
        columns = GridCells.Adaptive(minSize = 108.dp),
    ) {
        items(
            items = items,
            key = { it.id },          // stable key; avoids wrong reuse on reorder/insert
            contentType = { "thumb" }, // helps same-type cell reuse
        ) { item ->
            // This derived state reads only "this item's favorite".
            // It does not recompose when other items' favorites change.
            val isFav by remember(item.id) {
                derivedStateOf { favorites[item.id] == true }
            }
            WallpaperCell(
                item = item,
                isFavorite = isFav,
                onToggleFavorite = onToggleFavorite, // pass a stable function reference
            )
        }
    }
}

Three things are doing the work here. key = { it.id } pins each cell's identity to its ID so a reorder or insert doesn't accidentally inherit another item's state. derivedStateOf subscribes only to "my own favorite" and ignores changes to other members of the favorites set. And onToggleFavorite flows down as a stable function reference instead of a freshly built lambda each time. If you rebuild the callback inside the cell as { onToggleFavorite(item.id) }, that itself tends to become a changing argument, so keep the ID captured on the cell side and call it there.

@Composable
private fun WallpaperCell(
    item: WallpaperItem,
    isFavorite: Boolean,
    onToggleFavorite: (String) -> Unit,
) {
    Box {
        AsyncImage(
            model = item.thumbnailUrl,
            contentDescription = null,
            modifier = Modifier.aspectRatio(0.62f),
        )
        FavoriteButton(
            isFavorite = isFavorite,
            onClick = { onToggleFavorite(item.id) }, // call here; the argument stays stable
        )
    }
}

Measured — recomposition counts and frame times, before and after

Instead of calling it done once it felt fixed, I ran the very first step again. With roughly 14 cells visible, here are the recomposition counts for the thumbnail Composable on a single favorite toggle. I also captured frame times while scrolling and mashing the toggle (Macrobenchmark's FrameTimingMetric). These are values on my mid-range physical device; numbers vary by hardware, but the trend reproduces.

The recomposition that had moved every visible cell now stayed on the single tapped one. With P90 frame time under the 16.7 ms budget for 60fps, mashing-while-scrolling on a slow device no longer drops frames. What mattered here was not stopping at "feels faster" but re-capturing the same numbers under the same conditions as before. Compose optimizations regress easily — forget to keep one stability annotation and you're back where you started — so it's only truly fixed when the before and after numbers line up.

One pitfall remains. If you later mutate the contents of a model you marked @Immutable somewhere, the compiler keeps trusting the skip and stops updating the screen. Moving favorite state out of the model wasn't only cosmetic; it was a design choice to avoid telling that lie.

How much to delegate to the agent, and what to keep

What I delegated to the agent was the Composition Tracing wiring, the Gradle config to emit the compiler report, and reading back "the list of classes reported as unstable." Building the measurement scaffold is boilerplate, and a machine is faster and more accurate at it.

The decision to pull isFavorite out of the model and lift state up a level, though, I kept for myself. It looks like a performance problem but is really a question of where data ownership belongs. The agent proposes the shortest path to "turn unstable into stable," but whether to change var to val and externalize the state, or to push through with strong skipping, should be decided by the person who knows the lifetime and update frequency of that app's data. Delegate the measurement, keep the design. That's my own line when pairing with an agent in solo development.

The next time you meet the same symptom, run composeCompiler.reports.destination once and look over the list of unstable classes. Most of the reasons recomposition spreads are written in the first few lines of that list.