How to measure android app start-up time?

Measuring your Android app’s startup time is crucial for delivering a seamless user experience. If you haven’t yet tested how long your app takes to load, this guide will walk you through the process. While tools like Android Vitals in Google Play Console or Firebase Performance Monitoring provide post-release insights, measuring startup time before release allows you to optimize early and compare performance across versions.

The primary goal is to track changes in startup time between releases, ideally as a percentage. Absolute startup times vary across devices due to hardware differences, but percentage changes offer a reliable metric for assessing performance trends. For instance, if you integrate a new library, how can you ensure it doesn’t slow down your app? This article equips you with the tools to answer that question.

Startup time is a critical metric for every release, but measuring it accurately requires careful planning. Below, we outline best practices, measurement methods, and strategies to improve precision.

Measurement Guidelines

To ensure consistent and meaningful results, follow these rules:
Minimize External Factors: Network requests and dynamic content should not influence startup time.

Define the Metric: Measure from the app’s launch to the first visible frame (Time to Initial Display, or TTID).

TTID - metric measures the time it takes for an application to produce its first frame, including process initialization (if a cold start), activity creation (if cold/warm), and displaying first frame.

Avoid Blocking Operations: Refrain from executing network calls or lengthy tasks in Application.onCreate() or the first activity’s onCreate(). This is not only a measurement best practice but also a fundamental rule for Android development.

However, several device-specific factors can skew results:
CPU Frequency: Varies based on current load or power-saving modes.

Memory Speed: Impacts performance on different hardware.

System Load: Background processes can affect measurements.

Let’s explore two practical methods to measure startup time and how to enhance their accuracy.

Method 1: ActivityManager via Logcat

The simplest approach uses Logcat to capture startup times logged by Android’s ActivityTaskManager. These logs report the time taken to display an activity, such as:

03-19 13:05:20.146 523 550 I ActivityTaskManager: Displayed com.example/.MainActivity: +343ms 03-19 13:05:23.920 523 550 I ActivityTaskManager: Displayed com.example/.SplashActivity: +1s845ms 03-19 13:05:25.728 523 550 I ActivityTaskManager: Displayed com.example/.ui.SignupActivity: +381ms 

There are logs for each activity, we need to filter logs that are related only to the first app activity. Then we can launch the app a few times and calculate the average time.

For using this method we don't need anything special, only execute ADB command and check LogCat logs:

Clear LogCat logs:

adb logcat -c

Launch the app:

adb shell am start-activity -n com.example/.SplashActivity

Then you will see logs in the LogCat as was shown above. More details about this variant you can find in the documentation

You can check my full bash script and example on Github

Method 2: Android Benchmark Plugin

The Android Benchmark Plugin offers a more automated and detailed way to measure startup time, providing results directly in the command line:

Starting: Intent { cmp=com.example.MainActivity } Status: ok LaunchState: COLD Activity: com.example.MainActivity TotalTime: 2303 WaitTime: 2305 Complete 

Setup:

app/build.gradle.kts

plugins { .... id 'androidx.benchmark' } 

/build.gradle.kts

buildscript { .... dependencies { classpath("androidx.benchmark:benchmark-gradle-plugin:1.1.1") } } 

Then you can run the command:

adb shell am start-activity -W -n com.example/.MainActivity

Ok, now we found two ways how to get the time that our app spent to start. Now we can discuss how to make our results more precession. All suggestion bellow is applicable to both types of measurement.

1. Cold start and clear app data

adb shell pm clear com.example Run this command every time before measurement.

1. Run the measurement a few times and calculate the average value.

2. Run the measurement on the same device/emulator and within a short time. I mean that results are relevant only for measurements that were done in the short time period because you can't provide a guarantee that after some time the condition on the device/emulator will be the same.

3. Lock clocks (on rooted devices/emulator), more details in the documentation

4. Run the measurement on the device. In most cases, you will see the right results even on the emulator if you use the same emulator on the same laptop for measuring the difference between two APK files. However, some optimization works only on a real device, for example adding a baseline file shows results only when running measurements on the real device.

We completed the first step of measuring. Now we have the ability to compare different apk (for example different releases). As the next step we can run measuring N times and then calculate the average result in this way results will be more stable for each version of APK.

I created a few examples of bash scripts on my Github

If you have questions, please ask in the comments.