Compose Performance Optimization

"Compose is slow" usually means one of a few specific problems: testing a debug build, recomposing a large tree on every scroll frame, or doing expensive work inside composables. All of them are measurable and fixable.

Step 0: Measure correctly

• Use a release-like build (minified, non-debuggable). Debug Compose is significantly slower.
• Add a Baseline Profile. Compose ships its own profile rules, and your app's critical journeys benefit from one too. See Baseline Profiles.
• Use Macrobenchmark with FrameTimingMetric for scrolling and animation jank.
• Use Layout Inspector's recomposition counts to see which composables recompose and how often.

Understand the three phases

The fixes, in order of impact

1. Defer reads of fast-changing state

// ❌ Recomposes Header on every scroll pixel
Header(Modifier.offset(y = (-scrollState.value / 2).dp))

// ✅ Reads scroll only in the layout phase
Header(Modifier.offset { IntOffset(0, -scrollState.value / 2) })

// ✅ Alpha in the draw phase
Header(Modifier.graphicsLayer { alpha = 1f - (scrollState.value / 600f).coerceIn(0f, 1f) })

2. Use derivedStateOf when outputs change less than inputs

val showFab by remember { derivedStateOf { listState.firstVisibleItemIndex == 0 } }

3. Don't do expensive work in composition

// ❌ Sorting and formatting 1,000 items on every recomposition
val rows = transactions.sortedByDescending { it.date }.map { it.toUi() }

// ✅ Recompute only when the input changes (better still: do it in the ViewModel)
val rows = remember(transactions) { transactions.sortedByDescending { it.date }.map { it.toUi() } }

4. Tune lazy lists

• Provide key and contentType for every items call.
• Keep item composables small and parameters simple (IDs, strings, immutable UI models).
• Size images to their display size, and avoid decoding full-resolution bitmaps.

5. Stability and strong skipping

Compose skips a composable when its parameters are equal to last time and considered stable. With strong skipping mode, the default in recent Compose compiler versions, composables with unstable parameters can still be skipped, using instance equality for those parameters, and lambdas are remembered automatically. This removed many earlier stability headaches, but a few things still matter:

// Prefer immutable data classes for UI state
@Immutable
data class ProductUi(val id: String, val title: String, val priceText: String)

// A List parameter is an interface Compose can't prove immutable.
// With strong skipping, a NEW list instance on each emission means "changed".
// Avoid recreating identical lists; consider kotlinx.collections.immutable for clarity.

Use the Compose compiler's stability reports to see which classes are unstable. Fix the ones that appear on hot paths, not all of them.

6. Narrow recomposition scope

@Composable
fun PlayerScreen(state: PlayerState) {
    Column {
        AlbumArt(state.art)                       // rarely changes
        TrackInfo(state.title, state.artist)      // rarely changes
        ProgressBar(progressProvider = { state.progress })   // lambda: read deferred into ProgressBar
    }
}

Passing a () -> Float provider instead of the value lets only ProgressBar react to every progress tick.

Tools checklist

Typical fixes in the wild

Common mistakes

• Optimising stability everywhere before measuring.
• Backwards writes: writing state that was already read in the same composition, which triggers recomposition loops.
• Using derivedStateOf for cheap derivations that change as often as their inputs.
• Testing on a debug build and concluding Compose is slow.

Frequently asked questions

Conclusion

Fast Compose comes from measuring release builds, reading fast-changing state late, keeping composition cheap, tuning lazy lists and fixing stability where it matters. Baseline Profiles and Macrobenchmark prove the improvement.

Next step: build components Compose doesn't ship with in Custom Layouts and Drawing in Compose.