Startup Optimization

Understanding App Startup in Android

Application startup time is a critical metric for user experience. In the Android ecosystem, startup is categorized into three types:

1. Cold Start: The application process does not exist. The system must create the process from scratch (forking from Zygote), initialize the Application object, create the Activity, inflate the layout, and draw the first frame. This is the slowest and most complex scenario.
2. Warm Start: The process exists, but the Activity has been destroyed (or needs to be recreated). The overhead of forking the process and initializing the Application is skipped, but layout inflation and rendering must still occur.
3. Hot Start: The process exists, and the Activity is already in memory (usually in the background). The system simply brings the Activity to the foreground. This is the fastest startup type.

AOSP engineers focus primarily on optimizing Cold Starts, as they expose the most bottlenecks across the entire operating system stack.

Time-to-First-Frame (TTFF)

The standard metric for startup performance is "Time-to-First-Frame" (TTFF) or "Displayed Time". This is the duration from the moment the user taps the app icon to the exact moment the display hardware renders the first pixel of the application's UI.

Android logs this automatically in Logcat:

ActivityTaskManager: Displayed com.example.app/.MainActivity: +450ms

For a more accurate representation of when the app is actually usable, developers can use the reportFullyDrawn() API to log when asynchronous data (like fetching from a database) has finished loading into the UI.

App Startup Tracing with Perfetto

To optimize startup, you must trace it. Perfetto is the standard tool for this.

A typical startup trace reveals the following sequence:

1. Input: System UI detects the touch event on the launcher.
2. ActivityManager: The system server resolves the intent and requests a new process.
3. Zygote Fork: The Zygote process forks a new instance for the app.
4. bindApplication: The app's main thread starts executing. Application.onCreate() is called.
5. Activity Lifecycle: Activity.onCreate(), onStart(), and onResume() execute sequentially.
6. Choreographer: The first doFrame is scheduled. The layout is inflated (measure and layout), and drawing commands are issued.
7. RenderThread: The UI is rasterized and sent to SurfaceFlinger.

Look for long blocks (slices) in the main thread. Common offenders include:

• Heavy disk I/O in Application.onCreate() (often initializing SDKs or analytics).
• Deep view hierarchies slowing down inflation.
• Lock contention (waiting for SharedPreferences to load).

Zygote Preload Tuning

For AOSP platform engineers, optimizing startup isn't just about fixing the app; it is about optimizing the OS.

The Zygote process is the parent of all Android apps. To make forking fast, Zygote preloads hundreds of common Java classes (like View, Activity, String) and graphics resources into memory during system boot. When an app forks from Zygote, it inherits this preloaded memory via Copy-On-Write (COW).

If a class is NOT preloaded by Zygote, the app must load it from disk (APK/framework jars) during its own startup phase, causing page faults and disk I/O latency.

AOSP engineers can tune the preloaded-classes list (located in frameworks/base/config/).

• Adding a frequently used class to the list speeds up app startup.
• Removing an unused class saves system RAM.

You can profile which classes are loaded during startup and generate an optimized preload list using the WritePreloadedClassFile utility in the framework.

dexpreopt and Startup Performance

Another critical OS-level optimization is Dex Pre-optimization (dexpreopt).

Android apps are distributed as APKs containing DEX (Dalvik Executable) bytecode. If the system has to compile this bytecode to native machine code (AOT) or interpret it on the fly (JIT) during startup, it will severely impact TTFF.

To solve this, AOSP build systems employ dexpreopt. During the platform build process, the system compiles the DEX code of system apps and framework JARs into highly optimized native code (.oat or .vdex files) using dex2oat.

# In Android.bp or Android.mk
LOCAL_DEX_PREOPT := true

When the device boots, the optimized machine code is ready to execute immediately.

Furthermore, Cloud Profiles allow Google Play to aggregate the most frequently used execution paths (methods called during startup) from millions of devices. When a user installs an app, Play delivers a profile guiding dex2oat on the device to AOT-compile exactly those specific startup methods, ensuring maximum performance right out of the box.