Performance and Baseline Profiles for Android Engineers (2026)

Baseline profiles: the 2026 default for senior+ Android

A baseline profile is a list of classes and methods the Android runtime ahead-of-time (AOT) compiles at install. Without one, the runtime starts in JIT-only mode and AOT-compiles methods only after they've cleared the hotness threshold. With a baseline profile, the methods on the critical startup path are AOT-compiled before the user opens the app.

The measured impact is large. Google's internal data (published in the Android baseline profiles guide) shows 20-40% cold-startup wins and similar wins for first-frame jank. Compose-heavy apps see the largest improvements because Compose runtime is the dominant startup cost in modern UI.

The AGP 8 + AndroidX Baseline Profile Gradle Plugin pipeline is the standard 2026 setup. The plugin adds a :baselineProfile module that runs a Macrobenchmark test, captures the methods executed during a representative journey, and writes a baseline-prof.txt bundled into the APK or AAB:

// app/build.gradle.kts
plugins {
    id("com.android.application")
    id("org.jetbrains.kotlin.android")
    id("androidx.baselineprofile")
}

android {
    defaultConfig {
        // R8 must be enabled to use baseline profiles in release.
        // The plugin writes the profile to src/release/generated/baselineProfiles.
    }
    buildTypes {
        release {
            isMinifyEnabled = true
            isShrinkResources = true
            // R8 full-mode is the senior bar (default in AGP 8.0+).
        }
    }
}

dependencies {
    "baselineProfile"(project(":baselineProfileGenerator"))
    implementation("androidx.profileinstaller:profileinstaller:1.4.0")
}

// baselineProfileGenerator/src/main/java/com/example/BaselineProfileGenerator.kt
@RunWith(AndroidJUnit4::class)
@LargeTest
class BaselineProfileGenerator {
    @get:Rule val rule = BaselineProfileRule()

    @Test
    fun generate() = rule.collect(
        packageName = "com.example.app",
        includeInStartupProfile = true,
    ) {
        // Cold start the app and walk through the most-used screens.
        startActivityAndWait()
        // Scroll the main feed (the typical first user action).
        device.findObject(By.res("main_feed")).fling(Direction.DOWN)
        device.waitForIdle()
        // Open the second-most-used surface (e.g., search).
        device.findObject(By.res("search_tab")).click()
        device.wait(Until.hasObject(By.res("search_input")), 5_000)
    }
}

What this gets right: includeInStartupProfile = true generates both a baseline profile (full session) and a startup profile (first-launch path with a tighter runtime budget); the generator walks an actual user journey; device.waitForIdle() ensures full capture. The senior taste call is what to include: cold start, the most-used scroll, the second-most-used surface. Skip rare paths (settings, debug screens) — they bloat the profile and reduce the AOT budget for hot paths. Re-run on every release where the startup path changed; stale profiles lose most of their win. The Chris Banes baseline-profile writeups are the canonical practitioner reference.

Compose performance: recomposition tracing + Layout Inspector

Compose recomposition is the dominant performance cost in modern Android UI. The mental model: when state changes, Compose re-invokes any composable whose inputs are not provably equal to the previous invocation. "Provably equal" means stable — a stable type with equal inputs skips; an unstable type forces the composable to recompose every time its parent does, even if nothing meaningful changed.

The senior bar in 2026 is fluency in three things: the Stable / Immutable annotation contract; the Layout Inspector recomposition counts (Android Studio Hedgehog+); and the Compose compiler's stability inference rules. The canonical fix is to mark a data class @Immutable when the compiler cannot infer it (typically because a property type is from another module):

// BEFORE: kotlin.List has mutable subtypes, so the compiler does NOT
// infer ViewItem as stable. Every parent recomposition forces
// ViewItemRow to recompose even when items are identical.
data class ViewItem(
    val id: String,
    val title: String,
    val tags: List,
)

// AFTER: @Immutable is a contract with the compiler — "this value
// never changes after construction." The compiler trusts the annotation.
@Immutable
data class ViewItem(
    val id: String,
    val title: String,
    val tags: ImmutableList,  // kotlinx.collections.immutable
)

@Composable
fun ViewItemRow(item: ViewItem, onClick: (String) -> Unit) {
    // Now skips recomposition when item and onClick are referentially equal.
}

What this code gets right: @Immutable is a stronger contract than @Stable — Immutable promises the value never changes after construction; ImmutableList from kotlinx-collections-immutable is inferred as stable; the lambda parameter onClick stays stable as long as it's remembered or passed from a remembered source.

The diagnostic loop: run the app under Layout Inspector, enable "Show recomposition counts", and look for composables whose count climbs faster than meaningful state changes. A row that recomposes 50 times during a scroll where its data hasn't changed is the smoking gun — find the unstable parameter, annotate it or replace it with a stable equivalent. The Compose performance guide covers the full pattern; Chris Banes's composable-metrics writeup is the canonical reference for the compiler's stability reports. Two more high-value patterns: derivedStateOf for state derived from other state (recomposes only when the derived value flips), and key() in lazy lists to give Compose a stable identity for items that move.

Startup performance: cold/warm/hot + App Startup library

Android distinguishes three startup states, each with a different baseline cost and a different fix:

• Cold start — the process does not exist. The system forks Zygote, instantiates Application, runs every ContentProvider's onCreate(), runs every initializer in the App Startup library, inflates the first Activity, and runs first frame. This is the slowest and the one users notice — the Play Store badges apps that exceed the cold-start threshold.
• Warm start — the process exists but the Activity does not. The system reuses the Application instance, recreates the Activity, and runs first frame. Warm start is roughly 30-50% of cold start time on a well-tuned app.
• Hot start — the process and Activity both exist (the user backgrounded then resumed). The system brings the Activity to foreground and re-runs onResume + first frame. Hot start should be sub-100ms.

The Android Vitals launch-time thresholds (developer.android.com/topic/performance/vitals/launch-time) are the official bar: cold start under 5 seconds (Excessive at 5+), warm under 2, hot under 1.5. The senior bar is much tighter: cold under 1.5s on a P50 device (Pixel 6a-class), warm under 800ms, hot under 200ms.

The canonical Macrobenchmark test for cold startup, written against AndroidX Macrobenchmark 1.3+:

@RunWith(AndroidJUnit4::class)
@LargeTest
class StartupBenchmark {
    @get:Rule val rule = MacrobenchmarkRule()

    @Test
    fun coldStartupCompilationBaselineProfile() = rule.measureRepeated(
        packageName = "com.example.app",
        metrics = listOf(
            StartupTimingMetric(),
            FrameTimingMetric(),
            TraceSectionMetric("Application.onCreate"),
        ),
        iterations = 10,
        startupMode = StartupMode.COLD,
        compilationMode = CompilationMode.Partial(
            baselineProfileMode = BaselineProfileMode.Require,
        ),
    ) {
        pressHome()
        startActivityAndWait()
        device.wait(Until.hasObject(By.res("main_feed")), 5_000)
    }
}

What this test gets right: 10 iterations (Macrobenchmark reports p50/p95/p99 — one run is noise); explicit StartupMode.COLD (kills the process before each iteration); BaselineProfileMode.Require (fails the test if the profile is missing — prevents silent regression); StartupTimingMetric (canonical metric, reports time-to-initial-display and time-to-fully-drawn); TraceSectionMetric for a custom trace section (you instrument the code with Trace.beginSection / endSection and it surfaces in the trace and as a measured metric).

The companion API — App Startup library (androidx.startup) — is the modern replacement for the abused ContentProvider initialization pattern. Every third-party SDK that initialized via a stealth ContentProvider was paying the cold-start cost on every launch. App Startup consolidates them into one ContentProvider with a dependency graph; you control which initializers run eagerly and which run lazily. The senior pattern: defer everything that isn't needed for the first frame to a lazy initializer or a coroutine started from Application.onCreate, and instrument the eager path with Trace sections so you see it in Perfetto.

Perfetto + Macrobenchmark for production-perf debugging

Perfetto is the canonical Android system-trace tool in 2026 (perfetto.dev). It replaced Systrace and reads atrace events, ftrace events, Perfetto SDK events, and Android Choreographer frame events. Macrobenchmark captures Perfetto traces automatically — every test run produces a .perfetto-trace file you can drag into ui.perfetto.dev.

The senior reading pattern:

• Frame track — the Choreographer row shows every frame with its category (App, GPU, Display). A red frame is a missed deadline; the segments inside show where the time went.
• Main thread — long slices (longer than the frame budget) are jank candidates. Common offenders: synchronous I/O, JSON parsing, bitmap decoding, view inflation that should have been async.
• Binder transactions — synchronous binder calls on the main thread are silent jank multipliers; a 5ms IPC blocks the next frame.
• GPU work — if the main thread is fine but the frame still misses deadline, look at the GPU track for over-draw or shader compilation stalls.

The mid-tier P50 device matters more than the flagship. Senior teams ship a Macrobenchmark device matrix with a Pixel 6a-class mid-tier and a Pixel 8/9 Pro flagship. A regression invisible on the flagship is often what users see — flagship CPU and GPU mask code that's 4x slower on the P50.

The 120Hz frame budget tightens this further. At 60Hz the budget is 16.67ms; at 90Hz, 11.11ms; at 120Hz, 8.33ms. The senior pattern: profile the 120Hz budget on flagships (the OS refreshes at 120Hz when the app declares it can handle the rate via setFrameRate); profile the 60Hz budget on the P50. A composable taking 10ms is fine at 60Hz and dropping every other frame at 120Hz.

R8 full-mode (android.enableR8.fullMode=true, default in AGP 8.0+) is the senior bar for release builds — cross-module method inlining, class merging, aggressive enum-to-int conversion. The pairing with baseline profiles compounds: R8 produces smaller, faster bytecode, and the baseline profile pre-compiles the hottest of it. APK Analyzer is the canonical verification — open the release APK, check dex method count and resource sizes, confirm shrinking and obfuscation. The Macrobenchmark overview and the Chris Banes blog are the references for the full loop.