How We Halved App Startup Time: A Deep Dive into Android Launch Optimization

Background

App launch speed is a critical factor for user experience and retention. The "XinYu" social app, targeting young adults, required a smooth startup across a wide range of devices. Over five months the team reduced the average launch time from more than 8 seconds to about 4 seconds, a reduction of over 50%.

Optimization Scope

The focus was on cold‑start latency, which consists of three stages: Application creation, main‑thread tasks, and Activity rendering. Measurements were split into the "startup" phase (icon click to first frame) and the "first‑frame to fully visible" phase.

Application Optimization

Initially over 90 tasks ran during Application creation. The team applied four principles:

Only global baseline tasks belong here.

Minimize network requests.

Avoid strong business‑related tasks.

Reduce JSON parsing and I/O.

Task count dropped to about 60, grouped into core library initialization, feature configuration, and global UI setup. Additional techniques included:

Process‑level task placement : Separate lightweight processes (e.g., IM) from the main process to avoid unnecessary work.

Lazy loading : Split initialization and execution, using Kotlin’s by lazy where appropriate.

Process convergence : Limit the number of processes to two and merge where possible to lower memory pressure.

Thread convergence : Consolidate thread pools, avoid creating threads in third‑party SDKs, and eliminate network calls during startup.

Result: Application creation time on an Oppo A5 dropped from ~5 seconds to ~2.5 seconds.

Launch Chain Refinement

The original flow involved a loading page, optional splash page, and then the main page, requiring at least two Activity launches. By merging loading, main, and splash into a single Activity and using fragments, the team eliminated an extra Activity launch.

Implementation involved setting the main page as the launch Activity, using singleTop launchMode, and adding FLAG_ACTIVITY_NEW_TASK and FLAG_ACTIVITY_CLEAR_TOP to intents to emulate singleTask behavior while avoiding bugs.

Task Scheduling

A directed acyclic graph (DAG) manages task dependencies, dividing work into three streams:

Base stream : Minimal Application‑level tasks (network SDKs, monitoring).

Core stream : Business logic, UI rendering, data requests, and splash handling, prioritized to show the first frame quickly.

Idle stream : Low‑priority, long‑running tasks executed after a 10‑second delay via IdleHandler.

This approach allowed early data fetching and UI rendering, cutting the home page loading time on low‑end devices from ~3 seconds to under 1 second.

Home Page Optimization

Home page rendering dominated startup cost due to five Fragment instances. Strategies applied:

Lazy loading of fragments : Only the first Fragment is created initially; others are instantiated on demand. The ViewPager2 cache size was increased via

((RecyclerView)mViewPager.getChildAt(0)).setItemViewCacheSize(mFragments.size());

.

Component‑level pluginization : Heavy UI components are encapsulated as plugins (an enhanced ViewStub with fragment capabilities) and loaded based on priority.

JSON parsing acceleration : Data classes annotated with @JsonClass(generateAdapter = true) generate Moshi adapters at compile time, eliminating reflection overhead.

XML inflation optimization : Reduce layout depth, avoid custom views, and pre‑inflate critical layouts on background threads using

LayoutInflater inflater = LayoutInflater.from(context).cloneInContext(context); View view = inflater.inflate(R.layout.item_view, null, false);

.

These changes yielded a home‑page first‑frame improvement of ~3 seconds and total rendering under 1 second on the test device.

Lock Analysis

Various locks were identified as hidden performance killers:

Retrofit lock : Creating service instances serializes calls, adding ~200 ms latency per request.

Kotlin reflection lock : Metadata‑driven reflection incurs I/O and lock contention, potentially causing ANRs.

View inflation lock : LayoutInflater holds a lock tied to the context, slowing concurrent view creation.

Moshi lock : Adapter generation traverses class structures; using ThreadLocal caches mitigates contention.

Best Practices

Avoid Moshi parsing on the main thread.

Annotate Kotlin data classes with @JsonClass for generated adapters.

Never perform Retrofit operations on the UI thread.

When inflating XML asynchronously, be aware of multi‑thread lock contention.

These guidelines help prevent regressions caused by naïvely moving work to background threads without considering lock side‑effects.

Anti‑Degradation Measures

Startup optimization is an ongoing effort. The team monitors both online and offline metrics:

Online: Capture Application.attachBaseContext as start, Activity.onWindowFocusChanged as visible, and View.onViewAttachedToWindow as data‑on‑screen.

Offline: Record launch videos on devices of varying performance tiers and measure elapsed time.

Noise filtering discards outliers where process restarts or power‑saving policies distort timing. A threshold of 20 seconds is used to drop abnormal records. The following code computes interval deviation:

val intervalTime = abs(System.currentTimeMillis() - attachStartTime - SystemClock.currentThreadTimeMillis())

Code reviews focus on Application and home‑page changes, with alerts for excessive launch time.

Conclusion

The project achieved baseline launch performance but emphasizes that continuous monitoring, systematic lock analysis, and disciplined code reviews are essential to sustain gains. Simple, targeted optimizations often outperform complex, heavyweight solutions.

References

Application launch time – Android Developers documentation.

Douyin Android performance series: Startup optimization practice.