Recomposition concept in Android Kotlin - Deep Dive

Overview - Recomposition concept

What is it?

Recomposition is the process where the user interface updates itself when the data it depends on changes. In Android development with Jetpack Compose, the UI is described by functions that can be re-run to reflect new data. This means the screen redraws only the parts that need to change, making apps efficient and responsive.

Why it matters

Without recomposition, apps would have to redraw the entire screen every time something changes, wasting battery and making the app feel slow. Recomposition helps apps update smoothly and quickly, improving user experience and saving device resources.

Where it fits

Before learning recomposition, you should understand basic Kotlin programming and how Jetpack Compose builds UI with composable functions. After mastering recomposition, you can explore state management, side effects, and performance optimization in Compose apps.

Mental Model

Core Idea

Recomposition is like refreshing only the parts of a painting that have changed, instead of repainting the whole canvas every time.

Think of it like...

Imagine a newspaper where only the weather section updates daily, so the rest of the pages stay the same. Recomposition updates just the changed parts of the UI, not the entire screen.

┌─────────────────────────────┐
│       UI Screen             │
│ ┌───────────────┐           │
│ │ Part A        │           │
│ ├───────────────┤           │
│ │ Part B (data) │ ← Changes │
│ ├───────────────┤           │
│ │ Part C        │           │
│ └───────────────┘           │
└─────────────────────────────┘

Only Part B recomposes and redraws when its data changes.

Build-Up - 7 Steps

1

Foundation

What is Recomposition in Compose

Concept: Recomposition means re-running composable functions to update the UI when data changes.

In Jetpack Compose, UI is built with composable functions. When the data these functions use changes, Compose automatically calls them again to update the screen. This process is called recomposition.

Result

The UI updates smoothly to show the latest data without rebuilding everything manually.

Understanding recomposition is key to building dynamic and responsive UIs in Compose.

2

Foundation

How Compose Detects Data Changes

Concept: Compose tracks state variables to know when to trigger recomposition.

Compose uses special state holders like mutableStateOf to watch data. When this data changes, Compose knows which composables depend on it and recomposes only those parts.

Result

Only UI parts that use changed data are refreshed, saving work and improving performance.

Knowing how Compose tracks state helps you write efficient UI that updates correctly.

3

Intermediate

State and Recomposition Relationship

🤔Before reading on: do you think changing any variable triggers recomposition or only special state variables? Commit to your answer.

Concept: Only state variables wrapped in Compose's state holders trigger recomposition when changed.

Regular Kotlin variables do not cause recomposition. You must use Compose state types like mutableStateOf or remember to hold data that should trigger UI updates.

Result

UI updates only when intended, avoiding unnecessary redraws.

Understanding this prevents bugs where UI does not update or updates too often.

4

Intermediate

Recomposition Scope and Granularity

🤔Before reading on: do you think recomposition refreshes the whole screen or just parts? Commit to your answer.

Concept: Recomposition happens only for composables that read changed state, not the entire UI tree.

Compose tracks which composables read which state. When state changes, only those composables re-run. This fine-grained control makes UI updates efficient.

Result

Apps feel faster and use less battery because only necessary UI parts update.

Knowing recomposition scope helps you design composables that minimize unnecessary updates.

5

Intermediate

Remember and Recomposition Optimization

Concept: Using remember helps Compose keep values across recompositions and avoid repeating expensive work.

The remember function stores a value during recomposition so it doesn't get recreated every time. This is useful for caching or holding objects that don't change often.

Result

UI updates faster and uses less memory by avoiding repeated calculations.

Using remember wisely improves app performance and user experience.

6

Advanced

Side Effects and Recomposition Control

🤔Before reading on: do you think recomposition can cause side effects like network calls? Commit to your answer.

Concept: Recomposition can re-run code multiple times, so side effects must be managed carefully with effect handlers.

Compose provides side effect APIs like LaunchedEffect and DisposableEffect to run code only when needed, avoiding repeated side effects during recomposition.

Result

Apps behave correctly without unwanted repeated actions during UI updates.

Understanding side effects prevents bugs and performance issues in Compose apps.

7

Expert

Recomposition Internals and Skipping

🤔Before reading on: do you think Compose always re-runs composables on state change or can it skip some? Commit to your answer.

Concept: Compose uses smart algorithms to skip recomposition when inputs haven't changed, improving efficiency.

Compose compares parameters and state reads to decide if recomposition is needed. If nothing changed, it skips re-running the composable, saving CPU and battery.

Result

Highly optimized UI updates that feel instant and smooth even in complex apps.

Knowing how Compose skips recomposition helps you write composables that cooperate with this optimization.

Under the Hood

Jetpack Compose uses a runtime that tracks which composable functions read which pieces of state. When a state changes, Compose schedules recomposition for only those composables. It uses a slot table to store UI state and compares inputs to decide if recomposition can be skipped. This incremental update model avoids redrawing the entire UI tree.

Why designed this way?

Traditional UI frameworks redraw entire screens or views on changes, causing inefficiency. Compose was designed to be declarative and reactive, updating only what changed. This design improves performance, reduces boilerplate, and fits modern app needs for smooth, dynamic interfaces.

┌───────────────┐
│ State Change  │
└──────┬────────┘
       │ triggers
┌──────▼────────┐
│ Compose Runtime│
│ tracks reads  │
│ and schedules │
│ recomposition │
└──────┬────────┘
       │ recomposes
┌──────▼────────┐
│ Composable    │
│ functions run │
│ update UI     │
└───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: does changing any Kotlin variable trigger recomposition? Commit yes or no.

Common Belief: Changing any variable in a composable causes recomposition automatically.

Reality: Only changes to Compose state variables (like mutableStateOf) trigger recomposition.

Why it matters: Using regular variables for UI data means UI won't update, causing stale or incorrect displays.

Quick: does recomposition mean the whole screen redraws? Commit yes or no.

Common Belief: Recomposition always redraws the entire UI screen.

Reality: Recomposition only re-runs composables that read changed state, not the whole UI.

Why it matters: Thinking recomposition is expensive may lead to unnecessary optimization or complex code.

Quick: can side effects safely run inside composables during recomposition? Commit yes or no.

Common Belief: You can run side effects like network calls directly inside composables without issues.

Reality: Side effects must be managed with effect APIs; otherwise, they may run multiple times causing bugs.

Why it matters: Ignoring this causes repeated network calls or resource leaks, harming app stability.

Quick: does Compose always re-run composables on every state change? Commit yes or no.

Common Belief: Compose always re-runs all composables that read state when any state changes.

Reality: Compose can skip recomposition if inputs haven't changed, optimizing performance.

Why it matters: Not knowing this may lead to overcomplicated code trying to manually prevent recomposition.

Expert Zone

1

Compose's slot table stores UI state efficiently, enabling fast recomposition without rebuilding the entire UI tree.

2

Parameter equality checks during recomposition use smart heuristics, so passing stable data types improves skipping.

3

Recomposition can be triggered by indirect state changes, so understanding state flow is crucial to avoid unexpected UI updates.

When NOT to use

Recomposition is core to Compose and always used for UI updates. However, for very static screens or performance-critical animations, consider using remember or derivedStateOf to minimize recomposition. For legacy Android Views, recomposition does not apply; use View system updates instead.

Production Patterns

In real apps, developers split UI into small composables to limit recomposition scope. They use state hoisting to control data flow and remember to cache expensive calculations. Side effects are handled with LaunchedEffect to avoid repeated actions. Profiling tools help identify unnecessary recompositions for optimization.

Connections

React Virtual DOM

Both use a declarative UI model with efficient updates by comparing previous and current UI states.

Understanding React's Virtual DOM helps grasp how Compose minimizes UI work by recomposing only changed parts.

Functional Programming

Recomposition relies on pure functions (composables) that produce UI from data, similar to functional programming principles.

Knowing functional programming concepts clarifies why composables are designed to be side-effect free and easily recomposable.

Incremental Compilation in Software Build Systems

Both recomposition and incremental compilation avoid redoing work by only updating changed parts.

Seeing recomposition like incremental compilation helps understand the efficiency gains from partial updates.

Common Pitfalls

#1 UI does not update when data changes.

Wrong approach:

var count = 0

@Composable
fun Counter() {
Text(text = "Count: $count")
}

// Later
count++

Correct approach:

var count by mutableStateOf(0)

@Composable
fun Counter() {
Text(text = "Count: $count")
}

// Later
count++

Root cause:

Using regular variables instead of Compose state means Compose doesn't know to recompose.

#2 Side effects run multiple times causing repeated network calls.

Wrong approach:

@Composable
fun LoadData() {
// This runs on every recomposition
fetchDataFromNetwork()
Text("Loading")
}

Correct approach:

@Composable
fun LoadData() {
LaunchedEffect(Unit) {
fetchDataFromNetwork()
}
Text("Loading")
}

Root cause:

Running side effects directly in composables causes them to repeat on every recomposition.

#3 Unnecessary recompositions slow down the app.

Wrong approach:

@Composable
fun Greeting(name: String) {
Text("Hello, $name!")
}

// Called with new String instance each time
Greeting(name = "John" + "")

Correct approach:

val stableName = remember { "John" }
Greeting(name = stableName)

Root cause:

Passing new objects or unstable parameters causes Compose to think data changed, triggering recomposition.

Key Takeaways

Recomposition is the process where Jetpack Compose updates only the parts of the UI that depend on changed data.

Compose tracks special state variables to know when to re-run composable functions, making UI updates efficient and smooth.

Using remember and side effect APIs properly helps control recomposition and avoid bugs or performance issues.

Compose's smart skipping of recomposition based on input equality is a powerful optimization to write fast apps.

Understanding recomposition deeply enables building responsive, maintainable, and high-performance Android apps with Compose.

Practice

1. What does recomposition mean in Jetpack Compose?

easy

A. The app restarts when the user rotates the screen

B. The UI updates automatically when data changes

C. The app saves data to the database

D. The UI is drawn only once at app launch

Solution

1. Step 1: Understand recomposition meaning

   Recomposition means the UI redraws when the data it depends on changes.

2. Step 2: Compare options with definition

   Only The UI updates automatically when data changes describes this automatic UI update behavior.

3. Final Answer:

   The UI updates automatically when data changes -> Option B

4. Quick Check:

   Recomposition = UI updates on data change [OK]

Hint: Recomposition means UI changes with data changes [OK]

Common Mistakes:

• Confusing recomposition with app restart
• Thinking recomposition saves data
• Believing UI draws only once

2. Which of the following is the correct way to declare a state variable in Jetpack Compose to trigger recomposition?

easy

A. var count = 0

B. val count = 0

C. var count = mutableListOf(0)

D. val count = remember { mutableStateOf(0) }

Solution

1. Step 1: Identify state declaration for recomposition

   In Compose, state variables use remember { mutableStateOf() } to trigger recomposition.

2. Step 2: Check options for correct syntax

   Only val count = remember { mutableStateOf(0) } uses remember { mutableStateOf(0) } correctly.

3. Final Answer:

   val count = remember { mutableStateOf(0) } -> Option D

4. Quick Check:

   State variable uses remember + mutableStateOf [OK]

Hint: Use remember { mutableStateOf() } for state [OK]

Common Mistakes:

• Using plain variables without remember
• Using val without state wrapper
• Using mutableList instead of mutableStateOf

3. Given this code snippet, what will be displayed when the button is clicked once?

var count by remember { mutableStateOf(0) }
Button(onClick = { count++ }) {
  Text("Clicked: $count")
}

medium

A. Clicked: 0

B. Clicked: null

C. Clicked: 1

D. Clicked: 2

Solution

1. Step 1: Understand initial state and click effect

   Initial count is 0. Clicking the button increments count by 1.

2. Step 2: Determine displayed text after one click

   After one click, count becomes 1, so text shows "Clicked: 1".

3. Final Answer:

   Clicked: 1 -> Option C

4. Quick Check:

   State increments on click, text updates [OK]

Hint: Count starts 0, increments by 1 on click [OK]

Common Mistakes:

• Thinking count stays 0 after click
• Assuming count increments twice
• Confusing null with zero

4. What is wrong with this code that prevents recomposition when the button is clicked?

var count = 0
Button(onClick = { count++ }) {
  Text("Count: $count")
}

medium

A. count is not a state variable, so UI won't update

B. Button onClick syntax is incorrect

C. Text composable cannot display variables

D. count should be a val, not var

Solution

1. Step 1: Identify state usage in code

   Variable count is a plain var, not wrapped in state, so Compose won't track changes.

2. Step 2: Understand recomposition trigger

   Without state, UI does not recompose on count change, so text stays the same.

3. Final Answer:

   count is not a state variable, so UI won't update -> Option A

4. Quick Check:

   State needed for recomposition [OK]

Hint: Use state variables to trigger UI updates [OK]

Common Mistakes:

• Thinking var alone triggers recomposition
• Believing onClick syntax is wrong
• Assuming Text can't show variables

5. You want to create a counter that resets to zero when it reaches 5, updating the UI automatically. Which code snippet correctly uses recomposition to achieve this?

@Composable
fun Counter() {
  var count by remember { mutableStateOf(0) }
  Button(onClick = {
    count = if (count == 5) 0 else count + 1
  }) {
    Text("Count: $count")
  }
}

hard

A. Correct: count resets at 5 and UI updates

B. Incorrect: count never resets to zero

C. Incorrect: count is not a state variable

D. Incorrect: Button onClick syntax is invalid

Solution

1. Step 1: Analyze state and logic in code

   Variable count is a state variable with remember and mutableStateOf, so UI updates on change.

2. Step 2: Check reset logic correctness

   When count reaches 5, it resets to 0; otherwise, it increments by 1. This logic is correct.

3. Final Answer:

   Correct: count resets at 5 and UI updates -> Option A

4. Quick Check:

   State + reset logic triggers recomposition [OK]

Hint: Use state and conditional update for reset [OK]

Common Mistakes:

• Not using state variable for count
• Missing reset condition
• Incorrect Button onClick syntax