Explain Recomposition in Jetpack Compose

What's really being asked

This question tests your fundamental understanding of the declarative UI paradigm, which is the core of Jetpack Compose. The interviewer isn't looking for a textbook definition. They want to know if you understand the performance model: why Compose is efficient and how to write code that leverages its strengths. It's a test of your knowledge of state management, compiler optimizations, and performance best practices.

The full answer

First, define recomposition as the process of re-executing composable functions to update the UI when their underlying state changes. Contrast this with the imperative view system's manual invalidation.

Second, explain the trigger mechanism. When a composable function reads a State<T> object, it implicitly subscribes to updates for that state. Any write to that State object schedules a recomposition for all its subscribed readers.

Third, detail the primary optimization: skipping. The Compose compiler analyzes the parameters of your composables. If all parameters are 'stable' (unchanged since the last execution), Compose can entirely skip re-running the function and its children. Stability is key; primitives, strings, and classes marked with @Immutable are stable. Unstable types like a standard List can break this optimization.

Fourth, mention positional memoization. Compose identifies and tracks composables by their call site (source code location and parent structure), not by creating and comparing object instances. This allows it to intelligently update or skip specific sub-trees without affecting sibling composables.

The mistakes people make

A major red flag is stating that recomposition redraws the whole screen or a large portion of the UI on every state change. This demonstrates a fundamental misunderstanding of Compose's efficiency model. Another common mistake is confusing recomposition with the old View system's inflation and measure/layout/draw pass; they are very different. A senior candidate should also avoid hand-waving and calling it 'magic'—they should be able to explain the role of stability and the compiler.

What usually comes next

Expect questions like: "What makes a data class unstable, and how would you fix it?" (e.g., using a var instead of a val, or a mutable collection). "How would you debug excessive or unexpected recompositions?" (Using the Layout Inspector in Android Studio). "When should you use derivedStateOf?" (To limit recomposition when state is calculated from other state and changes less frequently).

A concrete example

Consider a simple screen with a counter. You have a count variable stored in mutableStateOf(0). A Text composable displays the count value, and a Button composable has an onClick lambda that increments it. When the user taps the button, the count state is updated. Because the Text composable reads count, it is scheduled for recomposition. However, the Button composable itself does not recompose, because its input parameters (the onClick lambda) are stable and have not changed. Compose is smart enough to re-execute only the Text function, making the update extremely efficient.