Improve startup times for Android apps like Facebook and Google

In a recent article, engineers from Google and Facebook provided their advice on what matters most to reduce the time it takes for an Android app to become responsive on launch and ensure an optimal user experience.

App startup is a key factor in maintaining user engagement and growing adoption, Facebook engineers say. The first step to improving app startup times is to measure them using Android’s two standard metrics: Time-To-Full-Display (TTFD), which is the time it takes for an app to be ready for user interaction, and Time-To-Initial-Display (TTID), which measures the time it takes for an application to become minimally functional, for example allowing the user to browse while downloading content.

Depending on the application, TTFD may be a more relevant metric than TTID, or vice versa, but TTID is always included in TTFD, so TTID is a good starting point for optimization. Additionally, TTID is used by Google to rank apps in Google Play listings.

Facebook’s startup metric is the percentage of app startups they consider “bad”, i.e. any startup that has a TTFD of more than 2.5 seconds OR any part of the startup that fails (for example, an image does not load or the application crashes).

TTID and TTFD can be easily instrumented using Android system calls: TTID is captured by logcat Displayed value, while TTFD can be connected to logcat using reportFullyDrawn.

Call reportFullyDrawn is a particularly important practice because it provides useful information to Android to optimize the use of resources to prioritize any work done before this call, say Google engineers.

Calling this method when your app is in a fully usable state will improve your app’s startup time. Every application should use this API! And don’t forget to measure it.

TTID and TTFD provide a solid foundation for understanding what can and should be optimized. To that end, Facebook engineers list a number of recommendations, such as being particularly zealous about startup crashes, parallelizing work by using all available cores, and deferring or sending to the background any work that isn’t related to the app startup experience.

Using a cache can be a great way to speed things up and populate your application with meaningful content, but cached content should only be used when it makes sense, i.e. say when not obsolete.

Evaluate whether it is better to optimize displaying new content as quickly as possible with a timeout to display outdated content if the network is slow, or just displaying what is available immediately if the network is offline.

Optimizing boot times requires a clear understanding of what is happening at launch, what the critical path is, and where the obstacles are. For this, Android provides a number of tools, including trace and Jetpack Macrobenchmark: Startup. These can also help understand if an application is trying to do too much at launch by trying to initialize too many things. Another useful tool is the Jetpack App startup library, which allows components to be initialized on application startup in a specified order.

There’s a whole lot more to app startup optimization that can be summarized here, so be sure to check out the original article for all the details.

Comments are closed.