testing-compose-in-release-mode

Name: testing-compose-in-release-mode
Author: skydoves

454stars15forks

How to install testing-compose-in-release-mode?

skydoves/compose-performance-skills/testing-compose-in-release-mode

$npx -y skills add skydoves/compose-performance-skills --skill testing-compose-in-release-mode

Installs into the current project.

Summary

Use this skill to ensure Jetpack Compose performance numbers reflect production reality by measuring against a release variant with R8 enabled, Live Literals disabled, and Compose Compiler reports read from the release output directory. Covers why debug builds lie (interpreted Co

Files · 1

View on GitHub

SKILL.md

1	# Testing Compose in Release Mode — Debug Builds Lie About Performance
2
3	Compose ships unbundled — its UI runtime is loaded from app code, runs interpreted in debug, and the Live Literals plugin turns every constant into a getter. Debug recomposition counts, debug startup numbers, and debug compiler reports are not what users experience. This skill teaches Claude how to set up a release-with-symbols build for honest measurement before any perf claim is made.
4
5	## When to use this skill
6
7	- The developer reports a perf number ("startup is 1.4s", "this composable recomposes 50 times per scroll") that came from a debug build, Layout Inspector against debug, or `CompilationMode.None`.
8	- The developer is about to file a perf bug, open a regression report, or post benchmark numbers in a PR.
9	- A CI perf gate is being designed (Macrobenchmark, baseline-profile diff, frame-timing budget).
10	- The developer asks "why are my benchmark numbers so much worse than what I see on Play Store?".
11	- Compose Compiler reports are about to be read — they MUST come from the release output directory or every conclusion is suspect.
12
13	## When NOT to use this skill
14
15	- Feature development before perf is in scope — debug iteration speed is fine while functionality is being built.
16	- Behavior testing (correctness, integration, instrumentation tests for screens) — that is separate from perf testing and stays in debug.
17	- Build configuration of R8 itself — see `../../build/configuring-r8-for-compose/SKILL.md`.
18	- Generating a Baseline Profile from a benchmark run — see `../generating-baseline-profiles/SKILL.md`.
19	- Reading individual lines of a Compose Compiler report — see `../../stability/diagnosing-compose-stability/SKILL.md`.
20
21	## Prerequisites
22
23	- A working Android project with a Compose UI.
24	- A release signing config. A debug-signed release-mode build is acceptable for measurement (use a `signingConfig signingConfigs.debug` on the release type), but unsigned release builds will not install.
25	- Kotlin 2.0+ with the `org.jetbrains.kotlin.plugin.compose` Gradle plugin.
26	- A real physical device to run on. Emulator and Cuttlefish numbers are not interchangeable with on-device numbers.
27	- Familiarity with Macrobenchmark and Baseline Profiles helps but is not required.
28
29	## Why debug lies — the four mechanisms
30
31	Surface these to the developer when they push back on "but my numbers feel real":
32
33	1. Interpreted Compose runtime. Compose UI is a regular dependency, not part of the platform. In debug, much of the runtime executes interpreted with JIT warmup happening across the first seconds of the app. R8 in release performs lambda grouping, strips `sourceInformation()` calls, devirtualizes `ComposerImpl`, and constant-folds composable args.
34	2. Live Literals. The Live Literals compiler plugin (on by default in debug for Android Studio's live edit) wraps every literal — `0.dp`, `"Hello"`, `Color.Red` — in a getter. The recomposer treats these as dynamic, so reports flag composables as taking unstable params even when source code only uses constants.
35	3. No R8 / no full mode. Even if R8 were enabled in debug it would be configured weakly. Without R8 full mode, lambda allocations stay, `sourceInformation` strings remain, and the cost-per-frame budget is bigger than what release ships.
36	4. Layout Inspector approximations. Layout Inspector recomposition counts are approximate — they snapshot at intervals and miss intermediate work. Live Literals can also inflate them. Debug-only counts are diagnostic, not authoritative.
37
38	Cited measurement: roughly 75 percent startup gain and 60 percent frame-render gain when switching debug to release with R8. Source: Ben Trengrove, "Why should you always test Compose performance in rel

skydovesPublisher · 26 listings

Preview

skydoves/compose-performance-skills

# Testing Compose in Release Mode — Debug Builds Lie About Performance

Compose ships unbundled — its UI runtime is loaded from app code, runs interpreted in debug, and the Live Literals plugin turns every constant into a getter. De

## When to use this skill

- The developer reports a perf number ("startup is 1.4s", "this composable recomposes 50 times per scroll") that came from a debug build, Layout Inspector again

Reposkydoves/compose-performance-skills

LicenseApache-2.0

TypeSkills

CategoryTesting

UpdatedJun 2026

Repo stars454

First seenJul 22, 2026

People who liked this also viewed

6 picks

Type

testing-compose-in-release-mode

454stars15forks

View on GitHub

How to install testing-compose-in-release-mode?

skydoves/compose-performance-skills/testing-compose-in-release-mode

$npx -y skills add skydoves/compose-performance-skills --skill testing-compose-in-release-mode

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Testing Compose in Release Mode — Debug Builds Lie About Performance
2
3	Compose ships unbundled — its UI runtime is loaded from app code, runs interpreted in debug, and the Live Literals plugin turns every constant into a getter. Debug recomposition counts, debug startup numbers, and debug compiler reports are not what users experience. This skill teaches Claude how to set up a release-with-symbols build for honest measurement before any perf claim is made.
4
5	## When to use this skill
6
7	- The developer reports a perf number ("startup is 1.4s", "this composable recomposes 50 times per scroll") that came from a debug build, Layout Inspector against debug, or `CompilationMode.None`.
8	- The developer is about to file a perf bug, open a regression report, or post benchmark numbers in a PR.
9	- A CI perf gate is being designed (Macrobenchmark, baseline-profile diff, frame-timing budget).
10	- The developer asks "why are my benchmark numbers so much worse than what I see on Play Store?".
11	- Compose Compiler reports are about to be read — they MUST come from the release output directory or every conclusion is suspect.
12
13	## When NOT to use this skill
14
15	- Feature development before perf is in scope — debug iteration speed is fine while functionality is being built.
16	- Behavior testing (correctness, integration, instrumentation tests for screens) — that is separate from perf testing and stays in debug.
17	- Build configuration of R8 itself — see `../../build/configuring-r8-for-compose/SKILL.md`.
18	- Generating a Baseline Profile from a benchmark run — see `../generating-baseline-profiles/SKILL.md`.
19	- Reading individual lines of a Compose Compiler report — see `../../stability/diagnosing-compose-stability/SKILL.md`.
20
21	## Prerequisites
22
23	- A working Android project with a Compose UI.
24	- A release signing config. A debug-signed release-mode build is acceptable for measurement (use a `signingConfig signingConfigs.debug` on the release type), but unsigned release builds will not install.
25	- Kotlin 2.0+ with the `org.jetbrains.kotlin.plugin.compose` Gradle plugin.
26	- A real physical device to run on. Emulator and Cuttlefish numbers are not interchangeable with on-device numbers.
27	- Familiarity with Macrobenchmark and Baseline Profiles helps but is not required.
28
29	## Why debug lies — the four mechanisms
30
31	Surface these to the developer when they push back on "but my numbers feel real":
32
33	1. Interpreted Compose runtime. Compose UI is a regular dependency, not part of the platform. In debug, much of the runtime executes interpreted with JIT warmup happening across the first seconds of the app. R8 in release performs lambda grouping, strips `sourceInformation()` calls, devirtualizes `ComposerImpl`, and constant-folds composable args.
34	2. Live Literals. The Live Literals compiler plugin (on by default in debug for Android Studio's live edit) wraps every literal — `0.dp`, `"Hello"`, `Color.Red` — in a getter. The recomposer treats these as dynamic, so reports flag composables as taking unstable params even when source code only uses constants.
35	3. No R8 / no full mode. Even if R8 were enabled in debug it would be configured weakly. Without R8 full mode, lambda allocations stay, `sourceInformation` strings remain, and the cost-per-frame budget is bigger than what release ships.
36	4. Layout Inspector approximations. Layout Inspector recomposition counts are approximate — they snapshot at intervals and miss intermediate work. Live Literals can also inflate them. Debug-only counts are diagnostic, not authoritative.
37
38	Cited measurement: roughly 75 percent startup gain and 60 percent frame-render gain when switching debug to release with R8. Source: Ben Trengrove, "Why should you always test Compose performance in rel

skydovesPublisher · 26 listings

Preview

skydoves/compose-performance-skills

# Testing Compose in Release Mode — Debug Builds Lie About Performance

Compose ships unbundled — its UI runtime is loaded from app code, runs interpreted in debug, and the Live Literals plugin turns every constant into a getter. De

## When to use this skill

- The developer reports a perf number ("startup is 1.4s", "this composable recomposes 50 times per scroll") that came from a debug build, Layout Inspector again

Reposkydoves/compose-performance-skills

LicenseApache-2.0

TypeSkills

CategoryTesting

UpdatedJun 2026

Repo stars454

First seenJul 22, 2026

People who liked this also viewed

6 picks

Type