Application class and startup work

Lifecycle and app components Mid-level Kotlin 2.0+ API 24+ Reviewed 31 Oct 2026 By Best Latest Apps

Pick the fix

Cold start takes 2.1 s. Application.onCreate initialises analytics, maps, image cache warm-up and an ads SDK. What's the best first move?

OptionsMeasure each init, keep only what the first screen needs, and defer or lazy-load the restMove all of it to a background thread at onceShow a longer splash screenAdd multidex

Hint 1 of 1

What does the first screen actually need?

Choose an answer, then open Show answer below to check it.

Show answer

Answer: A Measure each init, keep only what the first screen needs, and defer or lazy-load the rest

Correct. Measure, then move non-critical init off the critical path.

Why not the others?

B Move all of it to a background thread at once. Some SDKs must be on main or ready before use; blindly moving them causes races.
C Show a longer splash screen. That hides the problem and makes start slower.
D Add multidex. Not related to startup cost in modern builds.

30-second answer

Application.onCreate runs before any Activity on every cold start, including starts for a broadcast or a job. Only put work there that every entry point needs immediately, like dependency injection setup and crash reporting. Defer everything else: initialise lazily on first use, with App Startup, or after the first frame. Every millisecond there delays the first screen.

Practise saying it · 30 s. No recording, just a timer

Explain what belongs in Application.onCreate.

Say your answer out loud, then check which of these points you covered:

Runs on every cold start
Only essential init
Defer or lazy-load the rest
Measure with Macrobenchmark

Deep dive

App Startup's Initializer lets libraries declare init order through a single provider; you can also make them lazy.

Multiple processes (for example :remote services) each run Application.onCreate.

Use Baseline Profiles and measure with Macrobenchmark's StartupTimingMetric.

Never block on disk or network in onCreate; StrictMode catches accidental disk reads.

Common mistakes

Initialising every SDK eagerly in Application.onCreate.
Doing network calls there.
Forgetting that extra processes run it too.

Senior take & follow-ups

Talk about every entry point running it, and give a measurement plan.

Follow-up questions

Think of your answer first, then open the hint.

How do you measure the effect?
Show hint
Macrobenchmark with StartupTimingMetric, before and after.
Why would a receiver start slow?
Show hint
Its cold start also runs Application.onCreate.

Suggest a fix if something here is wrong or out of date.