Baseline Profiles

The Startup Problem

When a user installs your app, Android does not have profile data about which code paths are hot. ART (Android Runtime) must interpret code or compile it without optimization, leading to slow startup and jank during the first use.

Baseline profiles solve this by providing ART with a pre-built profile of critical code paths. When the app is installed, ART uses this profile to ahead-of-time (AOT) compile the most important methods, resulting in faster startup and smoother initial interactions.

How ART Compilation Works

Android uses a hybrid compilation strategy:

1. Interpretation: Code is interpreted initially for fast installation
2. JIT (Just-In-Time): Frequently executed methods are compiled at runtime
3. AOT (Ahead-Of-Time): At install or during idle charging, JIT profiles are used to AOT compile hot methods
4. Baseline Profile: Provides a pre-built profile to AOT compile critical code before the user even opens the app

Without baseline profile:
First launch → Interpret → JIT compile → Still slow → Eventually AOT

With baseline profile:
Install → AOT compile hot paths → First launch → Fast

What Goes in a Baseline Profile?

A baseline profile should contain:

• Startup path: The code that runs during app launch (Application.onCreate, first Activity, initial layout)
• Common user flows: The most frequent interactions (feed scrolling, navigation, search)
• Critical classes: Classes that are always loaded on startup

Do NOT include:

• Rarely used features
• Debug code
• Code paths that only run in specific conditions

Measuring Impact

You can measure the impact of baseline profiles using:

• Startup time: adb shell am start -W measures total startup time
• Frame rendering: Systrace or Perfetto shows frame times
• Compilation status: adb shell dumpsys package <pkg> shows compilation filters

The expected improvement is significant:

• Cold startup time reduction of 15-40%
• Fewer JIT compilations during first use
• Reduced jank in the first few seconds of interaction
• Lower memory usage from reduced JIT cache

Baseline Profile vs Compiler Config

The android:extractNativeLibs and compiler filter settings in build.gradle affect compilation:

android {
    buildTypes {
        release {
            isMinifyEnabled = true
            proguardFiles(
                getDefaultProguardFile("proguard-android-optimize.txt"),
                "proguard-rules.pro"
            )
        }
    }
}

Baseline profiles complement these settings by providing runtime profile data that the compiler filter alone cannot capture.

Macrobenchmark Setup

The baseline profile generator uses the Macrobenchmark library. Add it to your project:

// build.gradle.kts (project level)
plugins {
    id("com.android.library") version "8.2.0" apply false
    id("androidx.benchmark") version "1.2.0" apply false
}

// build.gradle.kts (benchmark module)
plugins {
    id("com.android.library")
    id("androidx.benchmark")
}

android {
    namespace = "com.example.benchmark"
    compileSdk = 34
    
    defaultConfig {
        minSdk = 24
    }
    
    compileOptions {
        sourceCompatibility = JavaVersion.VERSION_1_8
        targetCompatibility = JavaVersion.VERSION_1_8
    }
}

dependencies {
    implementation("androidx.test.ext:junit:1.1.5")
    implementation("androidx.test.espresso:espresso-core:3.5.1")
    implementation("androidx.benchmark:benchmark-macro-junit4:1.2.0")
    implementation("androidx.benchmark:benchmark-common:1.2.0")
}

Writing a Profile Generator

Create a benchmark test that exercises the critical startup path:

@RunWith(AndroidJUnit4::class)
class ProfileGenerator {
    
    @get:Rule
    val rule = MacrobenchmarkRule()
    
    @Test
    fun generateStartupProfile() {
        rule.measureRepeated(
            packageName = "com.example.myapp",
            metrics = listOf(StartupTimingMetric()),
            compilationMode = CompilationMode.DEFAULT,
            startupMode = StartupMode.COLD,
            iterations = 10
        ) {
            pressHome()
            startActivityAndWait()
            
            // Exercise common startup interactions
            waitForIdle()
            device.findObject(By.res("feed_list")).scroll(Direction.DOWN, 3f)
        }
    }
}

Running the Profile Generator

Execute the benchmark to generate the profile:

./gradlew :benchmark:connectedBenchmarkAndroidTest

After the benchmark runs, the profile is saved to src/main/baseline-prof.txt. This file contains rules in a specific format:

HSPLcom/example/myapp/MyApplication;->onCreate()V
Lcom/example/myapp/MyApplication;
Lcom/example/myapp/ui/MainActivity;
Lcom/example/myapp/ui/FeedFragment;

The rules are pattern-based:

• H = hot method (called frequently)
• S = startup method (called during startup)
• P = post-startup method
• L = class rule (include the entire class)

Automatic Profile Collection

For production apps, you can collect profiles from real users:

// In your Application class
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.P) {
    val profileInstaller = ProfileInstaller(context)
    profileInstaller.collectProfile()
}

Google Play also provides profile data through the Baseline Profile Gradle plugin, which can aggregate profiles from your testing and production builds.

Verifying the Impact

After generating and installing the baseline profile, verify the improvement:

# Check compilation status
adb shell dumpsys package com.example.myapp | grep -i "compilation"

# Measure cold startup time
adb shell am force-stop com.example.myapp
adb shell am start -W com.example.myapp/.MainActivity

The compilation status should show speed-profile instead of quicken or verify, indicating AOT compilation based on the profile.