Startup Optimization Practices for 58.com App

App startup refers to the process of entering the current app from a scenario outside the app, including cold, warm, and hot starts. Optimization mainly targets cold start to reduce the time from clicking the icon to displaying the first frame of the home page or the first frame of a business landing page.

The article introduces the team's practice of startup optimization for the 58.com app, which integrates multiple business modules and initializes many third‑party and custom SDKs during launch.

Project Background : Monitoring showed that about 20% of users experienced launch times over 5 seconds, affecting conversion rates for externally promoted content. The team was tasked with improving the startup performance.

Startup Process Analysis : The cold start flow starts from the Application’s attachBaseContext , proceeds through onCreate , launches LaunchActivity (handling splash, ads, deeplink logic), and finally reaches HomeActivity . Privacy permission checks also add overhead.

Time Attribution : Performance costs stem from excessive CPU usage, frequent thread switches, I/O waits, and lock contention. The startup was divided into three trace phases (Trace‑T1, Trace‑T2, Trace‑T3) to pinpoint task durations.

Monitoring Solution : An online visual monitoring tool was built on top of Android Profiler’s API. It records task start/end timestamps and visualizes them after the home page’s first frame is rendered.

Optimization Scheme :

Componentized startup framework: Inspired by WorkManager, tasks are defined as Workers with annotations, forming a DAG for execution and allowing process‑specific task groups.

Delayed initialization: Tasks are split into mandatory and delayed groups; delayed tasks are triggered after the home page’s first frame via DelayTaskManager .

Merging launch and home pages: Combined LaunchActivity and HomeActivity to eliminate an extra activity launch, reducing cross‑process calls and allowing concurrent loading of home‑related tasks during the splash period.

Home activity launch mode adjustment: Switched to standard and used intent flags to emulate singleTop behavior, preserving back‑stack semantics.

External launch optimization: Designed a sandbox process for business‑specific initialization and used activity‑alias and task‑stack builder techniques to handle deeplink routing efficiently.

Home layout and logic optimization: Reduced layout hierarchy with merge and ViewStub , modularized UI components, and introduced asynchronous layout inflation.

Additional improvements: Delayed sub‑process startup, increased network concurrency, and optimized header construction.

Results : The cold‑start time was reduced by about 50% on average. Tests showed significant improvements for both first‑install and subsequent launches, and visual comparisons demonstrated competitive performance against peer apps.

Conclusion and Outlook : While substantial gains were achieved, further fine‑grained optimizations (I/O, GC, lock contention) and continuous performance monitoring are needed to prevent regression and explore user‑profile‑driven startup paths.