DEV Community

Cover image for My notes on Android optimization. Part 1. Measuring startup time
Tristan Elliott
Tristan Elliott

Posted on

My notes on Android optimization. Part 1. Measuring startup time

Table of contents

  1. what this blog post is about?
  2. Startup times
  3. Cold start
  4. Time to initial display(TTID)
  5. What about time to full display(TTFD) ?

Resources

My app on the Google play store

My app's GitHub code

What this blog post is about?

  • My app on the Google play store, available HERE, has reached a development point where any new features are basically a repetition of previous features. For example, make a request, have it load and have the results populate the UI to inform the user. So I have decided to focus on optimization instead of feature development.

  • The areas of optimization I will be exploring in this blog post and future blog posts are as follows. Startup times, network usage, CPU usage, scrolling jank, battery usage, jetpack compose optimization and optimization for devices with limited ram. However, know that this will not be an exhaustive exploration of each optimization topic(read the official Android documentation if that is what your are looking for). These optimizations will be specific to my application and may ultimately be useless to you and your application.

  • With that being said here are my notes on measuring startup times

Startup times

  • Startup times, also known as Startup latency is defined in the documentation as:

Startup latency is the amount of time it takes between tapping on the app icon, notification, or other entry point, and the user's data showing on the screen.

  • Which can be summarized as, how fast does our app open

  • When we talk about startup times, we are talking about the app engaging in one of three starts, Cold start, Warm start and or Hot start. Now the documentation mentions that we should optimize for Cold starts as they are the most resource intensive. So that is what we should do.

Cold start

A cold start refers to an app's starting from scratch. This means that until this start, the system's process creates the app's process. Cold starts happen in cases such as your app launching for the first time since the device booted or since the system killed the app.

  • The documentation also states that we should aim for, Cold start in less than 500ms

  • Essentially, a cold start is when our app is closed and the device has no memory of it. Now that we know what a cold start is, lets get some measurements

Time to initial display(TTID)

  • As the title suggests the TTID is time it takes to display the first frame. Thankfully, TTID is reported automatically for every app by the Android Framework. Meaning we don't have to do any sort of configuration to get this metric(unlike compose metrics)
  • To get this metric, simply run the application's release build (all optimization measurement should be done in the release build) and look for The Displayed metric:

Image

  • It is recommended that we do this measurement 3 times and then take the average of those three times to ensure accuracy. Run the app, get the measurement, close the app and repeat 3 times. When running this on my own application I got an average TTID of 357ms which is less than the recommended 500ms.
  • So I won't be doing any sort of optimizations. However, it is still nice to have an objective measurement that we can compare future builds to

What about time to full display(TTFD) ?

  • If you read the documentation you probably came across, Time to full display. So why am I not mentioning it? TTFD seems very relative, ie, the time could change drastically depending on the implementation of your application. Also, it does not provide the cold hard metric that TTID does. While TTFD is most certainly important, it is not a metric I am looking at

Conclusion

  • Thank you for taking the time out of your day to read this blog post of mine. If you have any questions or concerns please comment below or reach out to me on Twitter.

Top comments (0)