13 Essential Jetpack Compose Tricks Every Senior Android Developer Should Master in 2026

Most Jetpack Compose performance problems aren’t caused by Compose.

They’re caused by developers treating a declarative UI framework like a shorter way to write XML.

The code compiles. The screen renders. The pull request passes review. Then the application grows, state begins flowing through six layers of composables, scrolling starts dropping frames, and nobody can explain why changing one Boolean recomposes half the screen.

That’s where the difference between knowing Compose syntax and engineering a production Compose application becomes obvious.

A senior Android developer doesn’t obsess over eliminating every recomposition. Recomposition is a normal part of Compose. The real objective is to control:

• Where state is owned
• Where state is read
• Which parts of the UI become invalid
• How much work each phase performs
• Whether performance improvements are measurable

Compose in 2026 also isn’t the Compose many teams adopted several years ago. The compiler has stronger skipping behavior, Material 3 has matured significantly, edge-to-edge is now a platform expectation, and adaptive layouts can no longer be dismissed as “tablet support.”

Here are 13 Jetpack Compose tricks that matter in real production code.

1. Model Each Screen as State Plus Events

One of the fastest ways to create an unmaintainable Compose screen is to pass ten unrelated values and eight callback lambdas into it.

@Composable
fun FeedScreen(
    posts: List<Post>,
    isLoading: Boolean,
    errorMessage: String?,
    selectedPostId: String?,
    query: String,
    onQueryChanged: (String) -> Unit,
    onPostClicked: (String) -> Unit,
    onRetryClicked: () -> Unit,
    onRefresh: () -> Unit,
)

This may be manageable initially, but it becomes fragile as the feature grows. Parameters get duplicated, impossible state combinations emerge, and previews become tedious to construct.

A stronger approach is to model the rendered screen as a single immutable value and represent user interactions as events.

@Immutable
data class FeedUiState(
    val posts: ImmutableList<PostUiModel> = persistentListOf(),
    val query: String = "",
    val isLoading: Boolean = false,
    val errorMessage: String? = null,
)

sealed interface FeedEvent {
    data class QueryChanged(val value: String) : FeedEvent
    data class PostClicked(val postId: String) : FeedEvent
    data object RetryClicked : FeedEvent
    data object RefreshRequested : FeedEvent
}

The route-level composable connects this state to the ViewModel.

@Composable
fun FeedRoute(
    viewModel: FeedViewModel = hiltViewModel(),
) {
    val uiState by viewModel.uiState.collectAsStateWithLifecycle()
FeedScreen(
        uiState = uiState,
        onEvent = viewModel::onEvent,
    )
}

The screen itself remains independent of dependency injection, repositories, navigation controllers, and lifecycle ownership.

@Composable
fun FeedScreen(
    uiState: FeedUiState,
    onEvent: (FeedEvent) -> Unit,
    modifier: Modifier = Modifier,
) {
    FeedContent(
        posts = uiState.posts,
        query = uiState.query,
        isLoading = uiState.isLoading,
        errorMessage = uiState.errorMessage,
        onQueryChanged = {
            onEvent(FeedEvent.QueryChanged(it))
        },
        onPostClicked = {
            onEvent(FeedEvent.PostClicked(it))
        },
        onRetryClicked = {
            onEvent(FeedEvent.RetryClicked)
        },
        modifier = modifier,
    )
}

This pattern provides a predictable contract:

The UI renders a state and reports events. It doesn’t secretly mutate business state.

That makes the screen easier to preview, test, reuse, and reason about.

There is one caveat: don’t turn every tiny component into a miniature Redux implementation. A reusable checkbox still benefits from checked and onCheckedChange. Screen-level state machines are useful; ceremony at every level is not.

2. Hoist State to the Lowest Correct Owner

“Hoist all state into the ViewModel” is not a Compose best practice.

It’s an overcorrection.

State should be owned by the lowest component that needs to control it, while still being high enough to coordinate all consumers.

Consider whether a search field is expanded:

@Composable
fun SearchToolbar(
    query: String,
    onQueryChanged: (String) -> Unit,
    modifier: Modifier = Modifier,
) {
    var expanded by rememberSaveable {
        mutableStateOf(false)
    }
// ...
}

The search query may affect repository filtering and therefore belongs in screen or business state. Whether the toolbar is temporarily expanded is usually local presentation state.

Moving expanded into a ViewModel would add persistence, events, and architectural coupling without providing meaningful value.

A practical ownership model is:

Business state belongs in a ViewModel or another business-layer state holder.

Screen coordination state belongs in a screen-level state holder when multiple UI elements depend on it.

Ephemeral UI state belongs close to the composable that uses it.

Examples of ephemeral UI state include:

• Whether a dropdown is expanded
• The active tab in a self-contained component
• A local animation target
• Focus state
• A temporary drag offset

Use rememberSaveable when losing the state during activity recreation would damage the user experience.

var selectedTab by rememberSaveable {
    mutableIntStateOf(0)
}

Use remember when the value only needs to survive recomposition.

val interactionSource = remember {
    MutableInteractionSource()
}

The senior-level decision isn’t “Where can I store this state?”

It’s “Who should be allowed to change it?”

3. Collect Flows with Lifecycle Awareness

A StateFlow is an excellent source for Compose state, but it should normally be collected through collectAsStateWithLifecycle() in Android applications.

@Composable
fun ProfileRoute(
    viewModel: ProfileViewModel = hiltViewModel(),
) {
    val uiState by viewModel.uiState.collectAsStateWithLifecycle()
ProfileScreen(
        uiState = uiState,
        onAction = viewModel::onAction,
    )
}

This stops collection when the associated lifecycle falls below the active state. That matters for flows backed by databases, network streams, sensors, location updates, or expensive transformations.

Plain collectAsState() is still valid in lifecycle-independent Compose environments, but Android UI collection usually needs lifecycle awareness.

Also avoid collecting the same upstream flow repeatedly across multiple descendants.

// Avoid scattering this throughout the tree.
val user by viewModel.user.collectAsStateWithLifecycle()
val permissions by viewModel.permissions.collectAsStateWithLifecycle()
val preferences by viewModel.preferences.collectAsStateWithLifecycle()

Prefer assembling coherent screen state before it reaches the UI.

val uiState: StateFlow<ProfileUiState> =
    combine(
        userRepository.user,
        permissionsRepository.permissions,
        preferencesRepository.preferences,
    ) { user, permissions, preferences ->
        ProfileUiState(
            user = user,
            canEdit = permissions.canEditProfile,
            useCompactLayout = preferences.compactProfile,
        )
    }.stateIn(
        scope = viewModelScope,
        started = SharingStarted.WhileSubscribed(5_000),
        initialValue = ProfileUiState(),
    )

This centralizes transformation logic and prevents the composable tree from becoming an accidental data orchestration layer.

4. Understand Stability Instead of Sprinkling @Stable

Compose performance discussions often reduce stability to a simplistic rule:

Add @Stable, and recomposition disappears.

That is dangerous advice.

@Stable and @Immutable are contracts you make with the Compose compiler. They are not runtime validation tools. If you mark a mutable type as immutable, Compose may skip work that was actually required, leaving the UI stale.

This is a lie:

@Immutable
data class CartUiState(
    val products: MutableList<Product>,
)

The list can change without replacing the CartUiState instance or notifying Compose correctly.

A safer model uses genuinely immutable data.

@Immutable
data class CartUiState(
    val products: ImmutableList<ProductUiModel>,
    val totalPrice: Money,
)

In modern Kotlin and Compose projects, strong skipping substantially improves how composables with unstable parameters are handled. It also means developers no longer need to wrap every captured lambda in remember merely to make it stable.

But strong skipping does not make stability irrelevant.

An unstable collection recreated on every emission still produces a new instance. A large object graph that changes identity on every update can still invalidate expensive work. Strong skipping improves compiler behavior; it doesn’t repair poor state modeling.

When performance genuinely points toward a stability problem, enable compiler reports.

composeCompiler {
    reportsDestination =
        layout.buildDirectory.dir("compose_compiler")
metricsDestination =
        layout.buildDirectory.dir("compose_compiler")
}

Then inspect the reports from a release build.

Do not attempt to make every composable skippable. That is usually optimization theatre. Investigate the components that appear in measured hot paths.

5. Defer Rapidly Changing State Reads

Where you read state determines which Compose phase becomes invalid.

Compose updates UI through three major phases:

1. Composition
2. Layout
3. Drawing

Suppose a header moves based on scroll position.

This implementation reads the scroll value during composition:

@Composable
fun CollapsingHeader(
    scrollOffset: Int,
    modifier: Modifier = Modifier,
) {
    Header(
        modifier = modifier.offset(
            y = -scrollOffset.dp,
        ),
    )
}

Every scroll update may now invalidate composition. It also incorrectly treats a pixel-based scroll offset as density-independent pixels.

Instead, pass a provider and read the value in the layout phase.

@Composable
fun CollapsingHeader(
    scrollOffset: () -> Int,
    modifier: Modifier = Modifier,
) {
    Header(
        modifier = modifier.offset {
            IntOffset(
                x = 0,
                y = -scrollOffset(),
            )
        },
    )
}

Usage:

val scrollState = rememberScrollState()

CollapsingHeader(
    scrollOffset = { scrollState.value },
)

The lambda-based offset modifier can read the value during layout, allowing Compose to skip composition for those updates.

The same principle applies to drawing.

val animatedColor by animateColorAsState(
    targetValue = targetColor,
    label = "backgroundColor",
)

Box(
    modifier = Modifier
        .fillMaxSize()
        .drawBehind {
            drawRect(animatedColor)
        },
)

Because the color is read inside drawBehind, Compose can invalidate drawing without necessarily repeating composition and layout.

This is one of the most valuable Jetpack Compose performance techniques, but don’t apply it blindly. Deferred reads make code less obvious. Use them for frequently changing values in measured hot paths, not for ordinary state that updates twice per screen session.

6. Use derivedStateOf Only When Input Changes Faster Than Output

derivedStateOf is not Compose’s version of a calculated property.

Its purpose is to avoid invalidating readers when underlying state changes more frequently than the value the UI actually cares about.

A classic example is a “scroll to top” button.

val listState = rememberLazyListState()

val showScrollToTop by remember(listState) {
    derivedStateOf {
        listState.firstVisibleItemIndex > 0
    }
}

The scroll position changes continuously, but showScrollToTop changes only when the first visible item crosses the threshold.

AnimatedVisibility(
    visible = showScrollToTop,
) {
    ScrollToTopButton(
        onClick = {
            coroutineScope.launch {
                listState.animateScrollToItem(0)
            }
        },
    )
}

That is a useful frequency mismatch.

This is not:

val fullName by remember {
    derivedStateOf {
        "$firstName $lastName"
    }
}

Whenever firstName or lastName changes, fullName should change too. There is no reduction in update frequency.

Write the obvious code:

val fullName = "$firstName $lastName"

derivedStateOf has overhead. Use it when the derived result changes materially less often than its inputs.

7. Choose Effect APIs by Lifecycle Semantics

Effect APIs are not interchangeable coroutine launchers.

Each one expresses a different relationship with composition.

Use LaunchedEffect for suspend work tied to keys

LaunchedEffect(userId) {
    analytics.trackProfileViewed(userId)
}

When userId changes, the existing coroutine is cancelled and a new one starts.

The keys are part of the behavior. A wrong key can either restart expensive work too often or preserve stale work for too long.

Use rememberUpdatedState to access current callbacks without restarting

@Composable
fun SessionTimeoutEffect(
    onTimeout: () -> Unit,
) {
    val currentOnTimeout by rememberUpdatedState(onTimeout)
LaunchedEffect(Unit) {
        delay(30_000)
        currentOnTimeout()
    }
}

The delay should not restart every time the parent supplies a new lambda instance, but the latest callback must run when the timer completes.

Use DisposableEffect for registration and cleanup

@Composable
fun LifecycleAnalytics(
    onStart: () -> Unit,
    onStop: () -> Unit,
) {
    val lifecycleOwner = LocalLifecycleOwner.current

DisposableEffect(lifecycleOwner) {
        val observer = LifecycleEventObserver { _, event ->
            when (event) {
                Lifecycle.Event.ON_START -> onStart()
                Lifecycle.Event.ON_STOP -> onStop()
                else -> Unit
            }
        }
        lifecycleOwner.lifecycle.addObserver(observer)
        onDispose {
            lifecycleOwner.lifecycle.removeObserver(observer)
        }
    }
}

Use snapshotFlow to observe Compose state as a Flow

LaunchedEffect(listState) {
    snapshotFlow {
        listState.firstVisibleItemIndex
    }
        .map { index -> index > 0 }
        .distinctUntilChanged()
        .filter { it }
        .collect {
            analytics.trackScrolledBeyondFirstItem()
        }
}

A common production mistake is launching work directly in a composable body:

@Composable
fun BrokenScreen() {
    viewModel.loadData()
}

Composable functions can run repeatedly, in different orders, or be skipped. Side effects need controlled lifecycle semantics.

8. Give Lazy Layouts Stable Keys and Content Types

A LazyColumn cannot correctly preserve item identity if the only identity you give it is position.

LazyColumn {
    items(posts) { post ->
        PostRow(post)
    }
}

Suppose the list is sorted by modification time and one item moves from the bottom to the top. Without keys, Compose has less information for distinguishing moved content from replaced content.

Provide a stable, unique key.

LazyColumn {
    items(
        items = posts,
        key = { post -> post.id },
    ) { post ->
        PostRow(post)
    }
}

Keys also help remembered item state move with the corresponding item.

Never use a changing field as the key.

// Bad: title can change.
key = { post -> post.title }

Never generate a key during composition.

// Very bad: new identity on every execution.
key = { UUID.randomUUID() }

For heterogeneous lists, provide contentType.

sealed interface FeedRow {
    val id: String
data class Article(
        override val id: String,
        val title: String,
    ) : FeedRow
    data class Advertisement(
        override val id: String,
        val campaignId: String,
    ) : FeedRow
}
LazyColumn {
    items(
        items = rows,
        key = FeedRow::id,
        contentType = { row ->
            when (row) {
                is FeedRow.Article -> "article"
                is FeedRow.Advertisement -> "advertisement"
            }
        },
    ) { row ->
        when (row) {
            is FeedRow.Article -> ArticleRow(row)
            is FeedRow.Advertisement -> AdvertisementRow(row)
        }
    }
}

contentType helps Compose reuse compatible item compositions instead of treating every row shape as interchangeable.

Also remember that lazy layouts are not automatically fast. Large images, expensive formatting, unstable item models, nested scrolling containers, and synchronous data transformation can still make them janky.

9. Use remember for Expensive UI Work—with Correct Keys

Composable bodies may execute frequently. Repeating expensive calculations inside them wastes frame time.

@Composable
fun ProductList(
    products: List<Product>,
    query: String,
) {
    val filteredProducts = products
        .filter { product ->
            product.name.contains(
                other = query,
                ignoreCase = true,
            )
        }
        .sortedBy(Product::name)
// ...
}

If this work is genuinely appropriate in the UI layer, remember the result using every dependency that affects it.

val filteredProducts = remember(products, query) {
    products
        .filter { product ->
            product.name.contains(
                other = query,
                ignoreCase = true,
            )
        }
        .sortedBy(Product::name)
}

The keys matter. Omitting query would return stale results.

remember is also useful for allocating helper objects.

val currencyFormatter = remember(locale) {
    NumberFormat.getCurrencyInstance(locale)
}

For drawing objects dependent on size, use drawWithCache.

Box(
    modifier = Modifier
        .fillMaxWidth()
        .height(180.dp)
        .drawWithCache {
            val brush = Brush.linearGradient(
                colors = listOf(
                    startColor,
                    endColor,
                ),
                start = Offset.Zero,
                end = Offset(size.width, size.height),
            )

onDrawBehind {
                drawRect(brush)
            }
        },
)

The cached drawing objects are recalculated only when relevant inputs, including size or observed state, change.

But remember is not a substitute for architecture.

Don’t perform repository queries, business decisions, or large data transformations in composition merely because you can cache them. Move expensive domain work upstream into the appropriate layer.

10. Separate Route Composables from Reusable Screens

A route composable knows about application infrastructure.

A screen composable knows how to render a screen.

Mixing both responsibilities creates components that are difficult to preview, test, and reuse.

@Composable
fun CheckoutRoute(
    viewModel: CheckoutViewModel = hiltViewModel(),
    navigator: CheckoutNavigator,
) {
    val uiState by viewModel.uiState.collectAsStateWithLifecycle()

CheckoutScreen(
        uiState = uiState,
        onPay = viewModel::submitPayment,
        onBack = navigator::navigateBack,
    )
}

The screen receives ordinary values and callbacks.

@Composable
fun CheckoutScreen(
    uiState: CheckoutUiState,
    onPay: () -> Unit,
    onBack: () -> Unit,
    modifier: Modifier = Modifier,
) {
    // Pure UI.
}

This creates several advantages:

• Previews don’t need a fake dependency injection graph.
• Tests don’t need a real NavController.
• Components can be rendered with deterministic state.
• Navigation remains an application concern rather than a visual component concern.

At the reusable component level, follow Compose API conventions.

@Composable
fun UserCard(
    user: UserUiModel,
    onClick: () -> Unit,
    modifier: Modifier = Modifier,
    trailingContent: @Composable RowScope.() -> Unit = {},
) {
    Row(
        modifier = modifier
            .fillMaxWidth()
            .clickable(
                onClick = onClick,
                role = Role.Button,
            )
            .padding(16.dp),
        verticalAlignment = Alignment.CenterVertically,
    ) {
        UserAvatar(user.avatarUrl)
UserDetails(
            user = user,
            modifier = Modifier
                .weight(1f)
                .padding(horizontal = 12.dp),
        )
        trailingContent()
    }
}

Notice the details:

modifier is accepted and applied to the root.

The caller controls outer layout behavior.

The component exposes a slot instead of accumulating Boolean configuration flags.

The custom interaction exposes an accessibility role.

A composable API is part of your architecture. Poor component contracts spread faster than almost any other form of UI debt.

11. Treat Material 3 as a Design System, Not a Component Catalogue

Using Button, Card, and Scaffold from Material 3 doesn’t mean your application has a coherent design system.

Senior teams centralize design decisions through semantic tokens.

@Composable
fun ProductTheme(
    darkTheme: Boolean = isSystemInDarkTheme(),
    content: @Composable () -> Unit,
) {
    val colorScheme = if (darkTheme) {
        DarkProductColorScheme
    } else {
        LightProductColorScheme
    }
override fun onCreate(
        savedInstanceState: Bundle?,
    ) {
        super.onCreate(savedInstanceState)
        enableEdgeToEdge()
        setContent {
            ProductTheme {
                App()
            }
        }
    }
}

Feature code should prefer semantic theme values:

Text(
    text = product.name,
    color = MaterialTheme.colorScheme.onSurface,
    style = MaterialTheme.typography.titleMedium,
)

Avoid scattering raw values throughout the application.

// Hard to maintain across themes and redesigns.
Text(
    text = product.name,
    color = Color(0xFF202124),
    fontSize = 17.sp,
)

Material 3 Expressive expands the design system with richer motion, component behavior, typography, and visual expression. That doesn’t mean every new component belongs in your product.

Adopt expressive APIs where they support product hierarchy and interaction. Don’t convert the app into a catalogue of animated shapes because a new dependency made it possible.

Also verify whether the specific APIs you adopt are stable or experimental. “Available in the library” is not the same as “safe to standardize across a five-year codebase.”

12. Build Edge-to-Edge and Adaptive Layouts by Default

Edge-to-edge is no longer an optional visual enhancement. Applications targeting modern Android versions must handle system bars and display cutouts correctly.

Enable it at the activity level.

class MainActivity : ComponentActivity() {
override fun onCreate(
        savedInstanceState: Bundle?,
    ) {
        super.onCreate(savedInstanceState)
        enableEdgeToEdge()
        setContent {
            ProductTheme {
                App()
            }
        }
    }
}

Then consume insets intentionally.

@Composable
fun HomeScreen() {
    Scaffold(
        contentWindowInsets = WindowInsets.safeDrawing,
        topBar = {
            HomeTopAppBar()
        },
    ) { innerPadding ->
        HomeContent(
            modifier = Modifier
                .fillMaxSize()
                .padding(innerPadding)
                .consumeWindowInsets(innerPadding),
        )
    }
}

Don’t stack inset modifiers without understanding which component already consumes them. Double-applied status bar or navigation bar padding is a common migration bug.

Adaptive layout is the second half of this responsibility.

Don’t ask:

Is this device a tablet?

Ask:

How much space does this window currently provide?

A foldable can change posture. A tablet can enter split-screen mode. A desktop window can be resized. Device categories are poor proxies for available layout space.

Compose’s adaptive APIs can change navigation presentation according to the current window.

@Composable
fun AdaptiveAppNavigation(
    destinations: List<AppDestination>,
    selectedDestination: AppDestination,
    onDestinationSelected: (AppDestination) -> Unit,
    content: @Composable () -> Unit,
) {
    NavigationSuiteScaffold(
        navigationSuiteItems = {
            destinations.forEach { destination ->
                item(
                    selected = destination == selectedDestination,
                    onClick = {
                        onDestinationSelected(destination)
                    },
                    icon = {
                        Icon(
                            imageVector = destination.icon,
                            contentDescription = null,
                        )
                    },
                    label = {
                        Text(destination.label)
                    },
                )
            }
        },
        content = content,
    )
}

Depending on window conditions and configuration, adaptive navigation can present a navigation bar, rail, or drawer-style interface.

The same principle applies to screen content. A list-detail workflow should not merely stretch a phone layout across a large display. It should use the additional space to present more useful information.

Adaptive design is not a separate tablet project. It is part of modern Android UI engineering.

13. Measure Release Performance Instead of Guessing

The most important Compose trick is refusing to optimize based on intuition.

Debug builds distort performance. Live Edit distorts performance. Logging every recomposition distorts performance. Watching the emulator while Android Studio indexes the project is not a benchmark.

Use tooling to answer specific questions.

Layout Inspector can reveal unexpected recomposition and skip patterns during development. Composition tracing can show where Compose work appears inside a system trace. Compiler reports can help diagnose stability.

For user-facing performance, use Macrobenchmark.

@RunWith(AndroidJUnit4::class)
class FeedBenchmark {
@get:Rule
    val benchmarkRule = MacrobenchmarkRule()
    @Test
    fun scrollFeed() {
        benchmarkRule.measureRepeated(
            packageName = "com.example.app",
            metrics = listOf(
                FrameTimingMetric(),
            ),
            iterations = 10,
            startupMode = StartupMode.WARM,
            setupBlock = {
                startActivityAndWait()
            },
        ) {
            device
                .findObject(By.res("feed_list"))
                .fling(Direction.DOWN)
        }
    }
}

Benchmark complete user journeys:

• Cold startup
• Opening a heavy screen
• Scrolling an image feed
• Switching major destinations
• Expanding a complex detail panel
• Completing checkout or onboarding

Then generate an application-specific Baseline Profile covering the critical journeys.

Compose libraries ship with optimizations for Compose itself, but they cannot know which parts of your application users execute. Your Baseline Profile should include your own startup and interaction paths.

Most importantly, establish a before-and-after measurement.

Without that, statements such as “this avoids recomposition” or “this should be faster” are engineering guesses.

Sometimes an optimization reduces recomposition but increases allocations. Sometimes a more stable model makes code dramatically harder to maintain while producing no visible frame-time improvement. Sometimes the actual bottleneck is image decoding, database paging, or a blocking call — not Compose.

Senior engineers optimize the system that measurements reveal, not the framework concept currently trending on social media.

The Real Senior-Level Compose Mindset

The difference between junior and senior Compose code isn’t the number of advanced APIs it uses.

It’s whether the code makes state ownership, invalidation, lifecycle behavior, and performance costs explicit.

Strong production Compose code usually follows a few durable principles:

State has a clear owner.

Business state and ephemeral UI state aren’t mixed indiscriminately.

Composable functions render values and report events.

Frequently changing state is read as late as practical.

Effects have intentional keys and cleanup behavior.

Lazy content has stable identity.

Stability annotations describe reality rather than wishful thinking.

Material components are governed by a design system.

Layouts respond to window conditions rather than device labels.

Performance decisions are supported by release-build measurements.

That is how you avoid recomposition problems without turning the codebase into a pile of premature micro-optimizations.

Jetpack Compose already handles a significant amount of work for you. Your job isn’t to outsmart its runtime. Your job is to give the runtime clean state boundaries, truthful data models, and predictable component contracts.

Master those fundamentals, and most so-called Compose tricks stop feeling like tricks.

They become normal engineering practice.

Building a Compose application that renders correctly is easy. Building one that remains smooth, testable, and understandable after several years of feature development is a different problem.

Download **my free Jetpack Compose Performance Checklist** to audit your state ownership, recomposition boundaries, lazy layouts, stability configuration, effects, and release-performance workflow before these problems reach production.