Optimizing Cold Startup Performance of Android Apps: A Case Study with Alipay

Application launch performance, especially cold start speed, forms the first impression for users and is often used by benchmark agencies to evaluate device performance, making it a key focus for both app and phone manufacturers.

Background : Recent testing revealed that Alipay’s cold start on our device is 29% slower than on the competing Honor X20, as measured by high‑speed camera from finger release to home‑page content display.

Scope : This article uses Alipay as an example to answer two questions: (1) Why does the same app version on the same configuration launch slower on our device? (2) How can we optimize launch speed on our device?

Outline

App and system perspectives on launch optimization

CPU frequency boosting

Dex2oat strategy optimization

Reducing GC frequency

I/O optimization

Post‑optimization measurement results

Conclusion

References

1. App‑side launch optimizations

Replace launch‑page themes for perceived speed (visual only).

Delay or async load heavy business logic and libraries during initialization.

Simplify layout complexity and defer loading until needed.

Proactively trigger dex2oat where possible (restricted on Android 10+).

These basic steps are often applied, but large‑scale apps may involve complex callbacks, plugins, lock contention, file I/O, reflection, and network calls, requiring careful analysis with tools such as Systrace, Traceview, or Simpleperf.

2. System‑wide launch optimizations

System engineers focus on the path from input event reporting to the first frame composition, involving input handling, frame rendering, CPU/GPU scheduling, and SurfaceFlinger composition.

CPU Boosting

The main thread’s CPU frequency during launch shows that on our device the thread runs on a little core, while on the competitor it often runs on a big core, leading to slower message handling (e.g., MessageQueue::INVALIDATE and ::REFRESH).

SurfaceFlinger on the competitor is placed in the foreground cgroup, allowing it to use big cores, whereas ours remains in the System‑background group, limiting it to cores 0‑5.

Dex2oat Strategy Optimization

Dex2oat can compile methods in several modes: verify, quicken, space‑profile, space, speed‑profile, speed, everything . Higher‑level modes increase compile time and binary size but improve runtime speed.

Both our device and the competitor use the default speed‑profile mode, which compiles hot functions based on profiling data.

Reducing GC Frequency

Frequent garbage collection can degrade launch performance. One applied change skips a GC if the heap growth since the last collection is less than ¼ of the allowable increase. Another Android R change raises the heap‑size limit during startup, reducing GC triggers, and restores it after two seconds.

cs.android.com/android/_/android/platform/art/+/a98a28262f645d100e2dee9587e7822d35ade6f9

I/O Optimization

When the kernel receives a read request, it first checks the page cache. A cache hit avoids disk access; a miss incurs a slower disk read. By rearranging files inside the APK so that startup‑critical files are placed contiguously, the app maximizes cache hits and minimizes disk I/O.

Final Optimization Results

Three main actions were taken:

Adjusted CPU resources allocated to SurfaceFlinger.

Fine‑tuned dex2oat compilation mode for different scenarios.

Reduced the number of GC events during startup.

After these changes, high‑speed camera tests show Alipay’s launch time on our device matches the Honor X20, and user‑perceived launch speed is comparable.

References

https://developer.android.google.cn/topic/performance/vitals/launch-time
https://source.android.com/devices/tech/dalvik/configure