Composer applier and runtime phases

← Back to Compose

Composer, Applier, and Runtime Phases Deep Dive

Overview

Composer computes structural updates, while Applier executes those updates on the target UI tree.

Core Concepts

• composition phase (compute changes)
• layout phase (measure/place)
• draw phase (render)
• applier operations (insert/move/remove/update)

Runtime Internals

Compiler-generated composable code emits operations through Composer. Applier-specific implementations map operations to concrete UI nodes.

Composition / Recomposition Flow

• invalidated groups are recomposed
• composer records mutations
• applier commits node operations
• layout/draw run as required by invalidations

State Management

State changes can trigger different phase costs depending on whether they affect structure, layout constraints, or only drawing properties.

Code Examples

@Composable
fun AlphaChip(text: String, enabled: Boolean) {
    Text(
        text = text,
        modifier = Modifier.alpha(if (enabled) 1f else 0.5f)
    )
}

Common Interview Questions

• Q: Is recomposition equivalent to layout + draw every time? A: Explain runtime behavior: what invalidates state, how recomposition is scoped, where side effects live, and how to verify frame stability with profiler traces.
• Q: What responsibilities belong to composer vs applier? A: Explain runtime behavior: what invalidates state, how recomposition is scoped, where side effects live, and how to verify frame stability with profiler traces.

Production Considerations

• optimize based on phase bottleneck, not assumptions
• profile structure/layout/draw costs separately

Performance Insights

A change limited to draw properties is usually cheaper than one causing full layout recalculation.

Senior-Level Insights

Senior engineers explain phase-specific invalidation and use that model to pick targeted optimizations.