App Startup Time Quiz
PERFORMANCE › Runtime
During which launch state does the system create a brand-new process and construct the Application object?
- Hot start
- Warm start
- Cold start
- Resume from onTrimMemory
Answer: Cold start
Cold start is the only state that forks a new process and creates the Application object and main thread from scratch; warm and hot reuse the existing process.
What primarily distinguishes a warm start from a hot start?
- Warm start recreates the activity via onCreate(); hot start just resumes it
- A warm start always forks a brand-new app process first
- A hot start re-runs Application.onCreate() but a warm start skips it
- A hot start reinflates all layouts while a warm start skips inflation
Answer: Warm start recreates the activity via onCreate(); hot start just resumes it
In a warm start the process survives but the activity is recreated through onCreate(); a hot start finds the activity still in memory and just foregrounds it, skipping object init and inflation.
Which metric does the Android framework report automatically, without any app code?
- Time To Full Display (TTFD), which needs reportFullyDrawn()
- Time To Initial Display (TTID), reported automatically
- Frame jank rate, measured from dropped or stalled frames
- ANR rate, based on app-not-responding events in logs
Answer: Time To Initial Display (TTID), reported automatically
TTID is emitted automatically as the 'Displayed' logcat line when the first frame is drawn; TTFD requires the app to call reportFullyDrawn().
Why must an app call reportFullyDrawn() to get an accurate TTFD?
- Because calling it disables the app's splash screen while computing TTFD
- The framework can't otherwise know when async content finished rendering
- Because it forces a baseline profile to be generated at app launch
- Because it warms up process creation for the next app launch
Answer: The framework can't otherwise know when async content finished rendering
The system knows when the first frame draws but not when async network/disk content is fully populated, so the app must explicitly signal that point with reportFullyDrawn().
How does the AndroidX App Startup library reduce startup overhead?
- It moves all Application.onCreate() work onto a background thread
- It precompiles hot methods with ART ahead of time at install
- It replaces per-library content providers with one InitializationProvider
- It defers drawing the first frame until all data has loaded
Answer: It replaces per-library content providers with one InitializationProvider
Multiple content providers (one per library) are expensive to instantiate; App Startup replaces them with one InitializationProvider that runs Initializer components in dependency order.
In an App Startup Initializer, what is the role of the dependencies() method?
- It lists the other Initializers that must run first, setting init order
- It lists the Gradle module dependencies the build requires at build time
- It declares the runtime permissions the initializer requires
- It returns the singleton instance that the initializer creates
Answer: It lists the other Initializers that must run first, setting init order
dependencies() returns a list of Initializer classes that App Startup guarantees are initialized before this one's create() runs; create() returns the instance.
Which approach correctly precompiles an app's hot startup code paths so ART runs native code on first launch?
- Calling installSplashScreen() during onCreate setup
- Shipping a baseline profile of hot methods and classes
- Adding extra content providers to speed up app startup
- Raising the dexopt threshold at runtime for first launch
Answer: Shipping a baseline profile of hot methods and classes
A baseline profile lists the hot methods/classes that ART AOT-compiles at install time, so the critical startup path runs as compiled native code instead of being interpreted or JIT-compiled on first run.
On Android 12+ (and via the AndroidX core-splashscreen library), what is the correct way to add a splash screen, and why is it preferred over a dedicated splash Activity?
- Launch a separate SplashActivity that finishes itself after a short timer
- Call installSplashScreen() before super.onCreate(); it themes the starting window
- Set android:hasSplash="true" in the manifest to insert a splash pre-fork
- Draw the splash bitmap straight onto the window surface from Application.onCreate()
Answer: Call installSplashScreen() before super.onCreate(); it themes the starting window
installSplashScreen() hooks into the system starting window the platform already shows, so you get branding without inserting an extra Activity and its inflation/draw onto the cold-start critical path.
During a cold start, in what order do a ContentProvider's onCreate() and Application.onCreate() run?
- ContentProvider.onCreate() runs before Application.onCreate(), after attachBaseContext()
- Application.onCreate() always runs first, then each ContentProvider.onCreate() follows
- They run concurrently on separate threads with completely undefined ordering
- ContentProvider.onCreate() runs only after the first activity frame is drawn
Answer: ContentProvider.onCreate() runs before Application.onCreate(), after attachBaseContext()
The framework instantiates content providers and calls their onCreate() after attachBaseContext() but before Application.onCreate(), so libraries that auto-init via a provider execute ahead of your Application code and add to pre-first-frame work.
When measuring cold startup with the Macrobenchmark library, which setup actually produces cold-start numbers?
- Use the Microbenchmark library and annotate Application.onCreate() with @Benchmark
- Read one manual launch’s Displayed logcat line and treat it as the startup result
- Use StartupMode.COLD in MacrobenchmarkRule, then collect StartupTimingMetric
- Disable process death between iterations to cut noise in the startup measurements
Answer: Use StartupMode.COLD in MacrobenchmarkRule, then collect StartupTimingMetric
StartupMode.COLD forces each iteration to kill and relaunch the process from scratch, and StartupTimingMetric reports stable timeToInitialDisplay/timeToFullDisplay distributions across iterations rather than one noisy reading.
In Jetpack Compose, what is the idiomatic way to signal Time To Full Display once content is ready?
- Wrap the root in a SplashScreen composable to mark the first full draw.
- Call Activity.reportFullyDrawn() from a Composable body on every recomposition.
- TTFD cannot be measured in Compose; it only works with the View system.
- Use ReportDrawn, ReportDrawnWhen, or ReportDrawnAfter to report TTFD.
Answer: Use ReportDrawn, ReportDrawnWhen, or ReportDrawnAfter to report TTFD.
Compose provides ReportDrawn, ReportDrawnWhen, and ReportDrawnAfter, which call through to reportFullyDrawn() at the right moment so you do not have to manually track the Activity reference or recomposition.
How do you stop an App Startup Initializer from running automatically and instead initialize it on demand?
- Strip its <meta-data> via tools:node="remove", then call initializeComponent()
- Return null from the initializer's create() method to opt out
- Annotate the initializer class with a custom @Lazy annotation
- Run the initializer in a separate process declared via android:process
Answer: Strip its <meta-data> via tools:node="remove", then call initializeComponent()
Removing the initializer's meta-data via tools:node="remove" excludes it from the automatic InitializationProvider pass, and AppInitializer.initializeComponent() runs it (and its declared dependencies) lazily on demand.
Immediately after a cold launch begins, what does the user see before the app draws its first frame?
- Nothing; the screen stays black until the activity draws its first frame
- A system starting window, themed by the app, until the first frame
- The last frame of the previous app stays frozen until this app is ready
- A system-made screenshot of the app's saved state is shown during launch
Answer: A system starting window, themed by the app, until the first frame
The system shows a starting window immediately so the launch feels responsive while the process forks and the activity initializes; it is themed from the app (the splash screen on Android 12+) and replaced when the first real frame is drawn.
How does a baseline profile shipped inside an app's APK/AAB actually get applied so ART compiles the hot paths?
- It is JIT-compiled on first launch, just like no profile were present at all
- It rewrites the app's DEX bytecode at build time, so no runtime compile step exists
- The ProfileInstaller installs it, and ART AOT-compiles the hot methods/classes
- It triggers full-app AOT compilation, like Android's original install-time dex2oat
Answer: The ProfileInstaller installs it, and ART AOT-compiles the hot methods/classes
The bundled profile is installed by the ProfileInstaller and ART ahead-of-time compiles only the listed hot methods and classes at install time, so the critical startup path runs as compiled native code instead of being interpreted or JIT-compiled on first launch.