Reducing Android App Startup Time

Every SDK added "just one line" to Application.onCreate(). Two years later, cold start takes three seconds on mid-range phones. Startup regressions creep in silently, so you need measurement, a budget, and a few structural fixes.

Cold, warm and hot starts

Metrics: TTID and TTFD

• Time to Initial Display (TTID): until the first frame is drawn. Logcat prints it as "Displayed …".
• Time to Full Display (TTFD): until the content the user cares about is shown. Report it by calling reportFullyDrawn(), or with Compose's ReportDrawnWhen.

@Composable
fun HomeScreen(state: HomeUiState) {
    ReportDrawnWhen { state is HomeUiState.Content }    // tells the system when real content is visible
    // ...
}

Measuring reliably

• Macrobenchmark with StartupTimingMetric on a release-like build. See the performance guide for code.
• System traces (Perfetto or the Android Studio Profiler) to see what runs during startup.
• Android vitals for real-user startup data.

The highest-impact fixes

1. Slim down Application.onCreate()

@HiltAndroidApp
class App : Application() {
    @Inject lateinit var crashReporting: CrashReporting          // keep: needed early
    @Inject lateinit var analytics: dagger.Lazy<Analytics>        // defer: created on first use
    @Inject lateinit var appScope: CoroutineScope                  // injected application scope

    override fun onCreate() {
        super.onCreate()
        crashReporting.init()
        appScope.launch(Dispatchers.Default) {
            delay(1_000)                                          // after the first screen settles
            analytics.get().init()
            RemoteConfigWarmup.fetch()
        }
    }
}

Ask of every initialiser: does the first screen need it? If not, defer it, make it lazy, or initialise it on first use.

2. Watch hidden initialisers

Some libraries initialise themselves through ContentProviders that run before Application.onCreate(). The App Startup library lets you consolidate initialisers into one provider, control dependencies between them, and disable automatic initialisation for libraries you want to start lazily.

3. Ship a Baseline Profile

Baseline Profiles pre-compile the code on your startup path. They're often one of the biggest single wins, especially for Compose apps. See Baseline Profiles.

4. Make the first screen cheap

• Render cached data or a lightweight skeleton immediately. Load the rest asynchronously.
• Avoid synchronous disk reads, such as large SharedPreferences, before the first frame.
• Keep the first composition small. Defer heavy, below-the-fold UI.

5. Use the SplashScreen API correctly

class MainActivity : ComponentActivity() {
    private val viewModel: StartupViewModel by viewModels()

    override fun onCreate(savedInstanceState: Bundle?) {
        val splash = installSplashScreen()
        super.onCreate(savedInstanceState)
        // Keep the splash only until the minimum state (e.g. auth check from local storage) is ready
        splash.setKeepOnScreenCondition { !viewModel.isReady.value }
        setContent { AppRoot() }
    }
}

Don't keep the splash visible for network calls or artificial delays. That only hides a slow start.

Typical wins

Common mistakes

• Measuring debug builds, or only on flagship phones.
• Moving work to a background thread that the first screen then waits for anyway.
• Blocking on network or remote config before showing anything.
• No regression guard. Add a startup benchmark to CI.

Frequently asked questions

Conclusion

Faster startup comes from measuring cold starts on release builds, deferring everything the first screen doesn't need, controlling library initialisers, shipping a Baseline Profile, and keeping the first screen light, then guarding it with a benchmark.

Next step: go deeper on the biggest single lever in Baseline Profiles and App Performance.