Compose compiler non-skippable report conflicts with Layout Inspector recomposition counts

Static Compiler Metrics Versus Runtime Recomposition Counts

The goal is to decide which signal to trust when optimizing a Jetpack Compose recomposition bottleneck: the build-time Compose compiler report or the runtime recomposition count from Layout Inspector.

The compiler plugin classifies composables as skippable or non-skippable based on stability inference under strong skipping mode. Strong skipping defaults and inference rules vary across Compose compiler and Kotlin toolchain versions, so a composable marked non-skippable in one build may behave differently in another. The static report does not measure actual recomposition frequency.

Layout Inspector recomposition counts show observed runtime behavior but require a debuggable process and a supported toolchain configuration. The two measurements can disagree, creating uncertainty about whether a non-skippable classification is a real hotspot.

Should build-time skippability classification or runtime recomposition count take priority when they conflict? Does strong skipping mode change the weight given to static stability metrics before optimization?