lazycolumn recomposes every visible row on scroll, layout inspector shows 400+ recomposition

You have three separate problems and they are all visible in that snippet.

1. No key. Without key, an item's identity is its index. Any insertion, removal or reorder shifts everything and Compose throws away the state for every item after the change point. Add it:

items(state.rows, key = { it.id }) { row -> ... }

While you are there add contentType if you have more than one row layout - it lets Compose reuse the right kind of slot instead of composing from scratch.

2. A new lambda per item per composition. onTap = { viewModel.select(row.id) } allocates a fresh lambda that captures row. New instance, different parameter, RowCard cannot skip. Hoist a single stable callback that takes the id:

val onSelect = remember { { id: String -> viewModel.select(id) } }

and have RowCard call onSelect(row.id) internally.

3. List<String> is an unstable type. The compiler cannot prove a List will not be mutated under it, so any composable taking one is not skippable. Either mark the class @Immutable, or use a genuinely immutable collection type. Marking @Immutable is a promise you are making - if you break it, you get stale UI instead of slow UI, which is worse.

Fix all three. Fixing one and remeasuring will disappoint you, because they compound.

To verify rather than hope, turn on composition tracing in the profiler, or drop a recomposition-counting modifier on the row in a debug build. Counts should drop to single digits for a full scroll.

Adding a fourth cause that is not in your snippet but is the most common one in real apps: reading state too high up.

If the parent of your LazyColumn reads a frequently-changing value - scroll offset, an animation, anything per-frame - the entire parent recomposes, and every child goes with it. Sixty times a second.

The fix is deferred reads. Instead of reading the value and passing the result down, pass a lambda that reads it at the point of use:

// invalidates composition every frame
Modifier.offset(x = scrollState.value.dp)

// reads during layout, skips composition entirely
Modifier.offset { IntOffset(scrollState.value, 0) }

Same for graphicsLayer. The lambda overloads exist precisely so the read happens in the layout or draw phase rather than composition. If you have a collapsing toolbar anywhere near this list, go check it, because that pattern is where I have seen this most often.

Check what compiler version you are on before you rewrite everything. Strong skipping changes the rules here - it makes composables with unstable parameters skippable when the arguments are referentially equal, and it remembers lambdas for you. That kills the lambda problem in your snippet and softens the List one.

What it does not fix is the missing key. Identity in a lazy list is not a stability question, it is a correctness question, and no compiler feature will guess your ids for you.

So: still add the key, still be deliberate about stability at your API boundaries, but do not go add @Immutable to two hundred data classes if the compiler is already handling it.

Also stop passing the ViewModel into the row. It is an unstable type by definition, and it means the row can now do anything, which makes it impossible to reason about and impossible to preview.

A row should take data and callbacks. That constraint alone prevents most of these problems by making the unstable things impossible to reach from inside the item block.

Recomposition count is a red herring most of the time - recomposition is cheap by design and 400 of them across ten seconds is nothing. If scrolling is janky I would look at your image loading and whether you are decoding on the main thread, not at the composition counts.

The favourite button on each row is doing more work than my entire previous app.