How do you diagnose and fix excessive recomposition in Jetpack Compose?

What's really being asked

This question tests your senior-level ability to diagnose and solve non-obvious performance problems in Jetpack Compose. It's not about basic state management, but about the core compiler optimization mechanism: stability. The interviewer wants to see if you can connect a symptom (UI jank, high recomposition) to its root cause (unstable inputs preventing recomposition skipping) and use the right tools to prove it.

The full answer

A strong answer outlines a systematic, three-step process. First, identify the problem area using the Layout Inspector in Android Studio to find composables with unexpectedly high recomposition counts. Second, diagnose the root cause by enabling Compose Compiler Metrics. This generates a report detailing which composables are skippable and restartable, and more importantly, which parameters are marked as stable or unstable. Third, solve the stability issues. This involves replacing standard collections like List with kotlinx.collections.immutable.ImmutableList, annotating custom data classes with @Immutable where appropriate, and refactoring lambdas to avoid capturing unstable variables.

The mistakes people make

A major red flag is stopping at the first step. Many candidates will mention the Layout Inspector and recomposition counts but can't explain why a composable isn't being skipped. They might guess at solutions like remember or derivedStateOf without a clear diagnosis. Another weak answer is describing stability incorrectly, for example, by claiming any val is stable. A val property of type List<String> is unstable because the list's contents can change without the object reference changing.

What usually comes next

Expect questions like: "When would you use the @Stable annotation instead of @Immutable?" (Answer: For classes that are mutable but notify Compose of changes, like a state holder using MutableState). Or, "How can a lambda function be unstable, and how do you fix it?" (Answer: If it captures an unstable variable. Fix by passing the data as a stable parameter to the composable instead of capturing it from the outer scope). Another is "What if the unstable type comes from an external library you can't modify?" (Answer: Create a stable wrapper class that holds the unstable type and exposes its data as stable properties).

A concrete example

Imagine a ContactList composable taking a List<Contact> as a parameter. The compiler metrics report this List as unstable. Even if only one contact's name changes in the parent ViewModel, the entire ContactList recomposes because Compose can't guarantee the list is the same. The fix is to change the parameter type to ImmutableList<Contact>. Now, if the list itself hasn't changed reference, Compose knows it can safely skip recomposing the ContactList. If a contact is updated, the ViewModel must create a new ImmutableList instance, which correctly and efficiently triggers recomposition.