Implementing a Pre‑Ads Initialization Process for Faster Android App Startup

Why a Pre‑Ads Process Is Needed

Before diving into the background, an experiment showed that a pre‑ads flow can shorten average startup time by about 300 ms, prompting an investigation into why this step is necessary.

Startup optimization is a long‑standing topic for the Soul App; both conventional and "black‑tech" solutions have been explored. However, a persistent pain point is that the ad‑loading process must wait until the Application finishes, causing a serial execution that harms the launch experience.

Current Situation

The linear startup flow shown in the diagram cannot fully utilize available resources.

Expectation

Ideally, the ad initialization would run in parallel with the Application. Placing the ad init at the earliest possible point seems straightforward, but the core issue is that the Application can be started by means other than a user clicking the desktop icon. For those non‑icon launches, initializing ads is unnecessary and wastes resources.

The fundamental problem is determining whether the launch originated from a user‑icon click, allowing pre‑initialization of ads without waste.

Obtaining Startup Source via System API

Initially it seemed that a system API could provide the launch source, but the required Intent object is unavailable during the Application phase, making this approach infeasible.

Exclusion‑Based Approach

Since non‑icon launches affect the pre‑ads flow, we can exclude them. The following cases are filtered out:

Despite extensive exclusion rules, two major issues remain:

After applying all exclusions, the number of qualifying samples is low, reducing overall benefit.

Even among the remaining samples, about 20 % of ad exposures are still lost, which is unacceptable.

Hooking the Handler to Retrieve Startup Information

All Android UI launches go through a Handler, so intercepting it can reveal launch details. This method works, though it has some drawbacks.

Hook ActivityThread Handler

Below is the code used to hook the handler (shown as an image for brevity):

After setting a custom callback, messages can be intercepted.

When a message is captured, the mReferrer field provides the launch source, allowing us to know where the app was started from.

Privacy‑API reflection issues must be handled, but once the caller package is obtained, a simple keyword check for "launcher" or "home" reliably identifies icon‑click launches.

However, this method still incurs a delay of about 100 ms compared to obtaining the source after the main activity is fully created, which is considered marginal gain.

Reversing Initialization Order

Inspired by the hook results, we tried initializing the Application after the main UI has started, effectively swapping the usual order.

The hook solution proved stable with no crashes.

Since launch source information depends on the main activity, we first start the UI, then quickly initialize the Application before the UI lifecycle proceeds, ensuring we have the source early enough.

The diagram shows that initProxy (the Application init logic) is deferred until after the handler hook, allowing the app to enter the main UI quickly, capture the launch source, and then execute the remaining init logic.

Edge‑case handling is essential: if an exception occurs, the init logic must still run to avoid crashes. This solution is currently running in production with a limited rollout.

Key Takeaways

The journey of pre‑ads initialization involved many false starts and refinements, but it underscores that fast startup is crucial for user experience and core business metrics, and continuous performance engineering is an endless pursuit.