santimattius/performance-compose-skills/compose-views-interop

Performance First

Every Compose frame runs three phases. Cost rises left-to-right; restart scope shrinks left-to-right.

Interop boundary costs

Rule: at interop boundaries, minimize Composition-phase work; prefer stable parameters and lifecycle-correct disposal.

Performance Toolchain

WARNING: NEVER profile in debug builds. Debug disables R8, inlining, and Strong Skipping — numbers are meaningless. Always profile a release build with profileable enabled or a benchmark build type.

When to Use

Load this skill when:

• Hosting Compose inside Views (ComposeView, XML, Fragment, Dialog, RecyclerView ViewHolder, ViewPager2 page)
• Embedding Views inside Compose (AndroidView, AndroidViewBinding, legacy custom Views)
• Choosing `ViewCompositionStrategy` for Fragment, Dialog, or pooling containers
• RecyclerView or ViewPager2 mixes Compose and View children
• Single-Activity + Fragments or multi-Activity legacy navigation with partial Compose
• Auditing or fixing performance regressions during incremental migration (not greenfield Compose-only apps)

When NOT to Use

v1 exclusions (androidx only)

• No Accompanist — use androidx ViewPager2, Compose, ui-viewbinding only
• No Nav3 `AndroidFragment` / scene recipes — follow-up change
• No CMP desktop View interop

CMP Applicability

Canonical CMP rules: `../_shared/cmp-platform.md`

⚠️ This skill is Android-only. All APIs (AndroidView, ComposeView, ViewCompositionStrategy, RecyclerView, Fragment) use android.view.View. There is no CMP equivalent of this skill.

Status legend: ✅ fully supported · ⚠️ partial / version-gated · ❌ Android-only.

CMP scope: This skill covers Android View interop ONLY. For iOS embedding (UIKitView, ComposeUIViewController), desktop (SwingPanel), or web (HtmlView), see `../_shared/cmp-platform.md#7-view-interop-across-platforms`.

Interop decision tree

Need UI in a legacy View host (XML, Fragment, RV ViewHolder, Dialog)?
├── YES → ComposeView + setContent
│   ├── Fragment / Dialog? → ViewCompositionStrategy.DisposeOnViewTreeLifecycleDestroyed
│   ├── RecyclerView item? → Default or DisposeOnDetachedFromWindowOrReleasedFromPool + stable setContent (see recycler-view-interop)
│   └── Sole Activity window? → Default often OK
└── NO → Need legacy View inside Compose tree?
    ├── SDK has no Compose API (MapView, WebView, AdView, …)? → AndroidView (factory + lean update)
    ├── Small legacy XML snippet during migration? → AndroidViewBinding (not full-screen)
    ├── Custom View / View DS widget? → AndroidView short-term; plan Compose rewrite (custom-view-wrappers)
    └── UI rebuildable in Compose? → Pure Compose (do NOT use AndroidView)

Source of truth at boundary: hoist shared state in ViewModel / UDF holder; avoid two owners mutating the same View property from Compose and View code.

Critical patterns

1. AndroidView — factory once, lean update

// CORRECT — SDK gap; factory creates View once
AndroidView(
    factory = { context -> MapView(context).apply { /* one-time setup */ } },
    update = { map ->
        // Only sync when camera/bounds actually change — avoid heavy work every recomposition
        if (map.tag != targetBounds) {
            map.moveCamera(targetBounds)
            map.tag = targetBounds
        }
    },
    onRelease = { it.onDestroy() },
    modifier = Modifier.fillMaxSize(),
)
 
// WRONG — remembers View outside AndroidView; update does heavy allocation
val view = remember { MyChartView(context) }
AndroidView(factory = { view }, update = { it.rebuild(chartData) }) // rebuild every recomposition

See references/android-view-in-compose.md.

2. ComposeView — match ViewCompositionStrategy to host

composeView.setViewCompositionStrategy(
    ViewCompositionStrategy.DisposeOnViewTreeLifecycleDestroyed
)
composeView.setContent {
    MaterialTheme { ProfileContent() }
}

Anti-pattern: calling setContent { } on every onBindViewHolder — use stable content and pass state via parameters. See references/recycler-view-interop.md.

3. Lazy list AndroidView — enable reuse (Compose 1.4+)

AndroidView(
    factory = { ctx -> MyView(ctx) },
    update = { it.bind(item) },
    onReset = { it.clear() }, // required for reuse in LazyColumn/LazyRow
    onRelease = { it.dispose() },
)

4. Window insets — one consumer per hierarchy root

• View-root screen: consume insets in View layer; set ComposeView.consumeWindowInsets = false when appropriate
• Compose-root screen: consume in Compose; pad AndroidView with Modifier.windowInsetsPadding

See android docs — insets Views + Compose.

5. State across boundaries

• Compose → View: update block or SideEffect / callback from stable hoisted state
• View → Compose: listener updates ViewModel / MutableState held above interop node
• Never: duplicate source of truth on both sides without a single owner

See references/view-binding-bridge.md and compose-architecture for ViewModel scoping.

6. Dialog / BottomSheet hybrids

Use ComposeView with fragment/dialog lifecycle strategy; avoid retaining composition after dismiss. Material Compose Dialog / ModalBottomSheet can coexist during migration — pick one owner per overlay.

See references/dialog-bottomsheet-hybrids.md.

7. Topology guides

Anti-patterns (quick reference)

Commands

# Validate official interop guidance
android docs search "ComposeView ViewCompositionStrategy"
android docs fetch "kb://android/develop/ui/compose/migrate/interoperability-apis/views-in-compose"
 
# Audit signals in consumer apps
rg -n 'AndroidView\s*\(' -t kotlin
rg -n 'ComposeView|setViewCompositionStrategy' -t kotlin
rg -n 'setContent\s*\{' -t kotlin --glob '*ViewHolder*'

Related skills

Follow-up (out of v1)

Nav3 bridge: replacing Fragment/ViewPager2 Compose hosts with NavDisplay, scene strategies, and dialog scenes — coordinate with compose-navigation-nav3; do not duplicate Nav3 API docs here.

Resources