Explain Recomposition in Jetpack Compose

WHAT THIS TESTS: This question probes your fundamental understanding of the declarative UI paradigm in Compose. The interviewer wants to see if you grasp how Compose efficiently updates the UI, which is a stark contrast to the imperative View system. It's a test of your knowledge of state management, the Compose compiler's role, and performance optimization principles like skipping.

A GOOD ANSWER COVERS: A strong answer explains four key points in order. First, define recomposition as the process of calling your composable functions again when their inputs change. Second, specify that the trigger is a change to a State<T> object that was read during a previous composition. Third, explain the primary optimization is "smart recomposition" or "scoped recomposition," where Compose only re-runs the specific composables that read the changed state, not the entire UI tree. Fourth, describe "skipping," where the runtime avoids re-running a composable altogether if its parameters are stable and have not changed since the last composition, even if its parent recomposes.

COMMON WRONG ANSWERS: A major red flag is describing recomposition as a full UI redraw, similar to invalidate() in the old View system. Another common mistake is being vague about the trigger, for example, saying "when data changes" instead of specifically "when a State object that was read is updated." Candidates also often fail to mention "skipping" as a distinct and critical optimization. Finally, confusing recomposition (re-running the function) with the subsequent measure, layout, and draw phases shows a shallow understanding.

LIKELY FOLLOW-UPS: Expect questions like: "What makes a type 'stable' versus 'unstable' and why does it matter for skipping?" or "How would you debug unnecessary or excessive recompositions?" (Answer: Use the Layout Inspector in Android Studio). They might also ask about the role of remember in preserving state across recompositions or how to handle side effects using LaunchedEffect.

ONE CONCRETE EXAMPLE: Imagine a ProfileScreen composable holding a name state variable. It contains two children: UserName(name = name) and a static ProfileHeader(title = "User Details"). When the name state changes, ProfileScreen and UserName will recompose because they read the state. However, ProfileHeader will be skipped by the Compose runtime because its input ("User Details") is stable and has not changed, saving rendering work.