Android App Startup Speed Optimization Practices at JD Finance

1. Background of the Startup Optimization Project

In 2018 JD Digital established a middle‑platform department to promote technology reuse and cost reduction. The mPaaS platform was created to decouple components and improve capabilities, and the speed of Android app startup became a key focus. This article shares the practical experience of optimizing the JD Finance mobile app launch.

2. Detailed Analysis of the Startup Process

2.1 Startup Type Analysis

Android app launch can be divided into four types: cold start, hot start, warm start, and custom start. Cold start creates a new process, loads resources, and initializes the main thread and activity. Hot start brings a background process to the foreground. Warm start lies between cold and hot start. Custom start defines a business‑specific endpoint.

2.2 Cold Start Process Analysis

The cold‑start flow includes clicking the app icon, showing a blank preview window, creating the process, creating the Application object, starting the main thread, creating the MainActivity, loading the layout, arranging the screen, and finally drawing the first frame. Steps 1‑3 are system‑controlled and cannot be directly optimized. The first frame drawing marks the end of the launch.

The Application’s attachBaseContext is called first, followed by onCreate . The Activity lifecycle then runs, where onCreate usually dominates the loading time because it constructs views and initializes objects.

3. Startup Speed Measurement and Monitoring Tools

3.1 Logcat

Filter the "Displayed" tag in logcat to obtain launch timing.

3.2 ADB Command

// The full path of AppstartActivity can omit the package name
adb shell am start -W [packageName]/[AppstartActivityFullPath]

The command returns ThisTime, TotalTime, and WaitTime; TotalTime reflects the overall launch duration (process creation + Application init + Activity init + UI rendering).

3.3 Manual Logging (Instrumentation)

Insert logging points at key lifecycle nodes, heavy initialization methods, and time‑consuming algorithms to pinpoint bottlenecks.

3.4 Video Frame Analysis

Record the launch process, then analyze frame‑by‑frame to measure perceived latency.

3.5 SGM‑Mobile (APM)

JD Digital’s self‑developed APM solution provides distributed service monitoring, tracing, and alerting for mobile apps, enabling real‑time performance analysis and early detection of issues.

4. Practical Startup Speed Optimizations

4.1 Theme Switching

Replace the default blank launch background with the JD Finance splash screen to eliminate white‑screen and click‑no‑response issues.

4.2 Application Code Reduction

Remove deprecated, redundant, or unnecessary initialization code from the Application class, and avoid heavy tasks during startup.

4.3 Thread Optimization

Move non‑UI‑critical tasks to background threads and use a unified task manager to avoid thread contention and reduce the number of active threads during launch.

4.4 Fallback and Pre‑loading

Implement a fallback mechanism to guarantee execution of essential tasks and pre‑load long‑latency data (e.g., images, files) into memory during Application start.

4.5 Data Lazy Loading

Defer non‑essential tasks (e.g., ad display, home‑page data) until after the splash screen, using the task manager to respect dependencies and avoid circular waits.

4.6 Network Optimization (Server‑Side)

Reduce DNS, TCP, and TLS round‑trips by reusing DNS results, enabling HTTP keep‑alive, and minimizing the number of HTTP requests during launch.

4.7 Reducing Startup Processes and IPC

Separate the main process from auxiliary processes, applying different initialization flows to avoid duplicated work.

4.8 Activity Optimization

Merge activities, move heavy operations off the UI thread, optimize layout files, improve view rendering, and fine‑tune custom views to speed up Activity creation.

4.9 Other Techniques

Additional measures such as MultiDex, file reordering, and CPU frequency locking were also applied.

5. Results of the Startup Speed Optimization

After two months and three iteration cycles, launch time on mid‑range devices dropped from 2.4 s to 1.2 s, and high‑end devices achieved sub‑1 s launches—a 45 % improvement that meets the original performance goals.

The optimization effort is ongoing, requiring a long‑term mechanism that includes entry standards, code‑maintenance governance, and continuous performance testing and monitoring to keep the app consistently fast.