Understanding Cold, Warm, and Hot Starts
Cold start is the worst case: the system creates a new process, initializes Application, creates the Activity, inflates the layout, and draws the first frame. This is what users experience after a fresh install, a reboot, or when the system killed your process.
Warm start skips process creation but still recreates the Activity. Hot start only brings the existing Activity to the foreground. Most optimization effort should target cold start -- it has the largest absolute latency and is the first impression for new users.
Google considers a cold start acceptable under 500ms. Many production apps take 2-5 seconds. The gap is almost always caused by blocking work in Application.onCreate(), synchronous ContentProvider initialization, or heavy first-frame layout complexity.
Measuring Startup with Macrobenchmark
Before optimizing, you need a reliable baseline. The Macrobenchmark library gives you repeatable startup measurements outside your debug build, running on a real device with release-like conditions.
The key metrics are timeToInitialDisplay (TTID) -- when the first frame draws -- and timeToFullDisplay (TTFD) -- when meaningful content is visible. Always measure TTID first; it is what the system reports and what users perceive as "the app opened."
kotlin
@RunWith(AndroidJUnit4::class)
class StartupBenchmark {
@get:Rule
val benchmarkRule = MacrobenchmarkRule()
@Test
fun coldStartup() = benchmarkRule.measureRepeated(
packageName = "com.example.app",
metrics = listOf(StartupTimingMetric()),
iterations = 10,
startupMode = StartupMode.COLD,
) {
pressHome()
startActivityAndWait()
}
@Test
fun coldStartupWithBaselineProfile() =
benchmarkRule.measureRepeated(
packageName = "com.example.app",
metrics = listOf(StartupTimingMetric()),
iterations = 10,
startupMode = StartupMode.COLD,
compilationMode = CompilationMode.Partial(
baselineProfileMode =
BaselineProfileMode.Require
),
) {
pressHome()
startActivityAndWait()
}
}Baseline Profiles: The Single Biggest Win
Baseline Profiles tell the ART runtime which code paths to AOT-compile during app install. Without them, your app runs interpreted on first launch, then gradually JIT-compiles hot paths. With a Baseline Profile, critical startup code is already native when the user opens the app.
Google reports 20-40% faster cold starts from Baseline Profiles alone. It is the single highest-impact optimization you can make with the least code change. The Macrobenchmark library generates the profile automatically by running your startup flow.
kotlin
// benchmark/src/main/java/BaselineProfileGenerator.kt
@RunWith(AndroidJUnit4::class)
class BaselineProfileGenerator {
@get:Rule
val rule = BaselineProfileRule()
@Test
fun generateBaselineProfile() = rule.collect(
packageName = "com.example.app",
) {
// Cold start the app
pressHome()
startActivityAndWait()
// Navigate through critical user journeys
device.findObject(By.text("Home"))
.click()
device.waitForIdle()
device.findObject(By.text("Search"))
.click()
device.waitForIdle()
device.findObject(By.text("Profile"))
.click()
device.waitForIdle()
}
}
// app/build.gradle.kts
plugins {
id("com.android.application")
id("androidx.baselineprofile")
}
dependencies {
baselineProfile(project(":benchmark"))
}
baselineProfile {
automaticGenerationDuringBuild = true
}Lazy Initialization with the App Startup Library
Many libraries initialize eagerly via ContentProviders that run before Application.onCreate(). Each ContentProvider adds 2-10ms to cold start, and apps commonly have 10-20 of them. The App Startup library replaces this pattern with lazy, on-demand initialization.
By implementing Initializer interfaces and declaring them in a single merged ContentProvider, you eliminate duplicate providers and control initialization order. You can also defer non-critical initializers until after the first frame draws.
kotlin
// Eagerly initialized via App Startup manifest merge
class AnalyticsInitializer : Initializer<Analytics> {
override fun create(context: Context): Analytics {
return Analytics.init(context, BuildConfig.ANALYTICS_KEY)
}
override fun dependencies(): List<Class<out Initializer<*>>> =
emptyList()
}
// Deferred until after first frame
class CrashReportingInitializer : Initializer<CrashReporter> {
override fun create(context: Context): CrashReporter {
return CrashReporter.init(context)
}
// Depends on analytics being ready first
override fun dependencies(): List<Class<out Initializer<*>>> =
listOf(AnalyticsInitializer::class.java)
}
// In Application.onCreate() -- defer non-critical work
class App : Application() {
override fun onCreate() {
super.onCreate()
// Critical: initialize immediately
AppInitializer.getInstance(this)
.initializeComponent(AnalyticsInitializer::class.java)
// Deferred: initialize after first frame
val mainHandler = Handler(Looper.getMainLooper())
mainHandler.post {
AppInitializer.getInstance(this)
.initializeComponent(
CrashReportingInitializer::class.java
)
}
}
}Reducing Layout Complexity on the First Frame
The first frame your Activity draws determines TTID. A deeply nested layout hierarchy with complex views inflates slowly and triggers multiple measure/layout passes. For Compose, the equivalent problem is composables that trigger expensive computations during first composition.
Audit your launch screen's view hierarchy. Flatten nested LinearLayouts into ConstraintLayout or replace them with Compose. Avoid loading images synchronously on the first frame -- show placeholders and load asynchronously. Use ViewStub or conditional Compose blocks to defer content that is below the fold.
kotlin
// Instead of loading everything on first frame:
@Composable
fun HomeScreen(viewModel: HomeViewModel) {
val uiState by viewModel.uiState.collectAsStateWithLifecycle()
Column {
// Lightweight header -- renders immediately
TopBar(title = "Home")
when (uiState) {
is HomeState.Loading -> {
// Minimal placeholder -- fast first frame
ShimmerLoadingList(itemCount = 6)
}
is HomeState.Success -> {
// Heavy content loads after first frame
LazyColumn {
items(uiState.items) { item ->
ContentCard(item)
}
}
}
is HomeState.Error -> {
ErrorBanner(uiState.message)
}
}
}
}
// Shimmer placeholder -- renders in <1ms, no data needed
@Composable
fun ShimmerLoadingList(itemCount: Int) {
LazyColumn {
items(itemCount) {
ShimmerCard(modifier = Modifier
.fillMaxWidth()
.height(80.dp)
.padding(horizontal = 16.dp, vertical = 8.dp)
)
}
}
}Diagnosing Bottlenecks with Perfetto
When Macrobenchmark shows a slow startup but the cause is not obvious, Perfetto (the successor to systrace) gives you a timeline of every thread, every binder call, and every frame during launch.
Capture a trace during cold start, then look for long blocks on the main thread before the first frame. Common culprits: synchronous disk I/O in Application.onCreate(), class loading from dex files that have not been optimized, and blocking network calls disguised as "configuration fetches." Enabling StrictMode during development catches many of these disk and network violations on the main thread automatically.
Perfetto also shows ContentProvider initialization clearly -- each one appears as a distinct block before your Application code runs. Count them. If you see more than 3-4, investigate which libraries are registering providers and whether you can replace them with App Startup.
Key Takeaways
- 1Baseline Profiles deliver 20-40% faster cold starts with minimal code change -- implement them first.
- 2Measure with Macrobenchmark before and after every optimization to avoid regression.
- 3The App Startup library eliminates redundant ContentProviders and lets you defer non-critical initialization.
- 4Keep the first frame lightweight: show placeholders, load data asynchronously, flatten layout hierarchy.
- 5Use Perfetto to find main-thread blocking work before the first frame draws.
- 6Target under 500ms TTID for cold start -- users perceive anything longer as slow.
Frequently Asked
What's a good cold start time?
Under 500ms is excellent. 500ms-1s is acceptable. Over 1s needs optimization. Measure on mid-range devices, not just flagship phones.
How do Baseline Profiles help?
ART compiles specified methods during app installation, avoiding JIT compilation at runtime. This eliminates compilation pauses during startup.
Ready to architect your next Android app?
ANDROID-ARCHITECT generates production-ready Kotlin code, architecture blueprints, and CI/CD configurations from plain-language descriptions. Start building for free.
ANDROID-ARCHITECT · CONSOLE
S/N · AX-1A-00001
STRATEGIA-X · ENGINEERED · IN · CALIFORNIA