Recomposition Scopes in Jetpack Compose

In Compose, recomposition means re-running parts of your UI when state changes. Compose skips the parts that didn't depend on the changed state.

This is the core idea behind how Compose works. It tracks state reads and re-executes only the relevant code.

Every time you write a Composable, Compose sets up a recomposition scope behind the scenes. That's a part of the UI that can be updated independently of the rest.

But it goes deeper than that.

Internally, when the Compose compiler sees your Composable, it wraps it in what's called a restart group. This group tells the Composer where recomposition should start and end. For each of these restart groups, the Composer creates a RecomposeScope.

This is the building block that allows fine-grained UI updates.

Here's a simplified version of what the Compose compiler does under the hood:

@Composable
fun A(x: Int, $composer: Composer<*>, $changed: Int) {
  $composer.startRestartGroup()
  // actual UI
  f(x)
  $composer.endRestartGroup()?.updateScope { next ->
    A(x, next, $changed or 0b1)
  }
}

• startRestartGroup() begins a recomposition scope.
• endRestartGroup() finalizes it and may return a lambda to re-execute it later if needed.
• The lambda you see in updateScope is what Compose calls again during recomposition.

This whole setup is managed by the Composer, which keeps track of which scopes were invalidated.

A recomposition scope becomes active when Compose detects reads to observable state, like this:

val name by remember { mutableStateOf("") }
Text("Hello $name")

Here, the Text Composable reads from name. That triggers Compose to mark the scope as used. Next time name changes, Compose knows that scope must recompose. It skips everything else.

While Compose usually handles recomposition automatically, you can also manually trigger it.

The Composer exposes the current recomposition scope, and you can call invalidate() on it:

val scope = currentComposer.currentRecomposeScope
scope.invalidate()

This is not frequently used but might become useful in advanced scenarios where you need more control, like when writing libraries.

Under the hood, Compose maintains a stack of invalidated scopes. These are checked and executed during the next recomposition cycle.

Here's a clean example of recomposition scopes in action using everyday Composables:

@Composable
fun MyScreen() {
    var counter by remember { mutableStateOf(0) }

    Column {
        StaticHeader()
        CounterText(counter)
        Button(onClick = { counter++ }) {
            Text("Add")
        }
    }
}

@Composable
fun StaticHeader() {
    Text("Welcome!")
}

@Composable
fun CounterText(value: Int) {
    Text("Count: $value")
}

Only CounterText will recompose when you tap the button. The rest of the UI is untouched. That's the power of recomposition scopes.

If you're learning Compose through a course or building your first Android app, recomposition scopes might sound like an internal detail—but they're key to performance.

Here's what you need to remember:

• Every Composable is wrapped in a restart group, which defines a recomposition scope.
• The Composer tracks which scopes read state and only recomposes those.
• You can manually invalidate scopes when needed, but Compose usually handles it for you.
• Smaller, well-structured Composables = better recomposition behavior.

Mastering this helps you write UI that feels fast, smooth, and scalable.