Android App Start Explained

Working on Android App Start optimisation for the past 6 month at Grab (We are hiring), We did a lot of profiling and we immediately saw a lot of operations are done by the system just before you see the first frame.

This document will explain the 7 main steps requires to launch any Android App. We will also measure each steps to get the actual cost. We will use MonoClock from Kotlin to measure time delta.

This will also help you in monitoring our application start performance and detecting performance regression.

All pieces of code of the article are summarise on a github sample project (Hello world app). https://github.com/lucas34/Android-AppStart-Breakdown

We will only talk about the Cold App Start flow (app is not in memory). Also, we only focus on the app icon as entry point and not when the application is triggered by a deeplink or a push notification.

The 7 steps of the Android App Launch

1. createAppContext: Loading the application binary into memory
2. makeApplication : Create Application class and init class attributes
3. installContentProvider: Instantiate and call onCreate for content providers
4. callApplicationOnCreate: call Application onCreate method
5. newActivity: Create activity class and init class attributes
6. attach: Attach context to the activity
7. performOnCreate: call activity.onCreate method

The 7 steps of the Android App Start

Let’s now see in detail all 7 components and how we can measure them.

1. createAppContext

The very first thing the android system is doing when you tap on the icon is creating Application process and the main thread.

The main operation involved is DexFile.openDexFileNative which will load the application binary (The DEX file to simplify) into memory. This operation is pretty costly ~350ms According to Google

At this point our application is not even created yet so we don’t have control to measure it. However since everything is done in main thread, on the first line of code that will be executed by the system we will get the time since the main thread is alive. This will count all the operations happening before we had control and DEX loading is the main contributor according to the call stack.

2. makeApplication

Once our application binary is loaded into memory, the system will instantiate the application class and init all the class attributes from top down (Class attributes defined at the top of the class are init before the one at the bottom)

So if we want to measure all the attributes definition we do as follow

In this case we are measuring the time it takes for MyDatabase and MyNetwork to init. If anyone is adding a new class attribute or create an expensive object (Open the database in the constructor) we will be able to measure automatically.

3. installContentProvider

Content providers gets initialised after Application class but before Application.onCreate is called. To measure this we can do as follow

The delta between the end of the Application class attribute instantiation and the call of onCreate is measuring all content provider creation plus the onCreate call (For content provider).

Some libraries like Facebook SDK or Firebase use content provider to automatically init their library. This is pretty sneaky since adding a dependency to your project can increase your app start dramatically.

4. callApplicationOnCreate

This is the method you should be familiar with. In kotlin we can do this wrapping around the method to measure everything.

Code that will be added or modified inside the method will always be tracked and can prevent other dev to accidentally messing up with the measurement. Like for example adding code after we get the time (It happened 😥)

5. newActivity, 6. attach and 7. performOnCreate

Last 3 method measurement are pretty similar to the samples I gave before so I won’t explain more. If you want more detail please check the sample github project. (https://github.com/lucas34/Android-AppStart-Breakdown)

Here we go, we have our breakdown for each of the 7 steps with a relatively accurate metric for each of it. We can wrap all the metric under one data class. If we sum-up everything we very pretty close to the Process elapsed time which is the absolute app startup time

Talk at the MobileOptimized 2020 conference

Thanks for reading this article. Be sure to click 👏 below to recommend this article if you found it helpful. It would let others get this article in feed and spread the knowledge.