How to improve the application startup performance | Facebook application experience to share

Kateryna Semenova, Google Android team and Tim Trueman, Steven Harris, Subramanian, Facebook Team Ramaswamy

Introduction to the

Shortening app startup times is not trivial, but we need to understand the factors that contribute. This year, the Google Android team and the Facebook Apps team have been working together on quantitative metrics and sharing optimization methods to improve app launches. Google Android’s public documentation contains a lot of information about application launch optimization. Here we want to take a closer look at how it works with Facebook apps and what factors help improve app launch performance.

Now, more than 2.9 billion people use Facebook every month. Facebook helps people build communities and bring the world closer together. Users share life moments, learn and discuss what’s going on, build and nurture relationships, and work together to create revenue opportunities.

Facebook app developers are committed to making sure users have the best experience possible and that apps run smoothly on any device, in any country, and across different network conditions. The Google Android team and the Facebook team have worked together to agree on metrics and best practices for app launch times, which we share here.

Where to start

The first, of course, is measuring the startup time of the application. You can learn about the health of a user’s startup experience, track the deterioration of startup times, and calculate the amount of resources needed to make improvements. Ultimately, your startup time needs to be correlated with user satisfaction, engagement, or user growth to prioritize investment.

Android defines two metrics to measure application startup time: full display time (TTFD) and initial display time (TTID). While you can further break it down into cold/warm startup times, this article won’t explain the difference, whereas Facebook’s approach is to measure and optimize startup times experienced by all users interacting with the app (some are cold and some are warm).

Full Display of elapsed Time (time-to-full-display, TTFD)

TTFD records the time it takes for your application to be rendered and ready for user interaction and use, which may include the time it takes to display content stored locally or from the network. If the network is slow, this can take a while and will vary depending on the device the user is using. Therefore, it’s important to show the user something immediately so that they can see the process the application started, and that brings us to TTID…

Time used for Initial Display (time-to-initial-display, TTID)

TTID records how long it takes your application to display background, navigation, local content that can be loaded quickly, and placeholders for slower local or network content. The TTID should be the time it takes for the user to navigate around and get to his destination.

Don’t change too much: One thing to be aware of is the visual variation of applying content between TTID and TTFD, such as displaying cached content in the page and then suddenly switching the page content after the web content is loaded. This sudden change can be unpleasant and frustrating for users, so make sure your application displays enough meaningful content during TTID to show users as much as possible what they will see during TTFD.

Achieve user goals

Users visit your application to get content, which may take a while to load, and you want your application to present that content to them as soon as possible.

Facebook app developers focus on metrics based on full display Time (TTFD), which includes displaying all content and images, because it represents the full experience of the user accessing the app. Developers want to know if the network is taking too long to load content and graphics, or if loading fails, so that the team can improve the entire startup experience from start to finish.

What are good TTID and TTFD goals?

Facebook sets the startup time metric to the percentage of apps that they consider to be “poor” in startup time, which is any startup or startup failure with a TTFD of more than 2.5 seconds (for example, images don’t load or apps crash). Facebook is aiming to reduce the percentage of “bad” startup times by improving boot-ups that take longer than 2.5 seconds to get them out of the “bad” state, as well as fixing the issues that cause boot-ups to fail. 2.5 seconds was chosen because, according to research, it matters to Facebook users. This is also consistent with The maximum content drawing (LCP) metric recommended by Web Vitals for websites.

Compared to TTID, providing a full experience, especially getting the latest content from the web, can make your TTFD startup metrics look rather slow. And that’s actually a good thing! It reflects the real user experience of your application. What you can do to improve your application, as Facebook has done, is increase usage and recognition of its performance.

Measuring TTFD can be tricky depending on your application. If this is too difficult, start with the initial display time (TTID). While it may not be possible to quantify the loading performance of some content due to placeholders or images, it’s still a good place to start, as this is also what users interact with the application on a daily basis (though not all of it).

Detect TTID

In Android 4.4 (API level 19) and later, Logcat provides a “Displayed” value to record the time that elapsed between starting the process and finishing drawing the first frame of the Activity on the screen.

The reported log line looks like the following example:

ActivityManager: Displayed com.android.myexample/.StartupTiming: +3s534ms
Copy the code

Detection of TTFD

To detect TTFD, simply call reportFullyDrawn() in your Activity after all of your content is displayed on the screen. Be sure to include anything that replaces the placeholder, as well as any images you render (be sure to count the time the image itself displays, not just its placeholder display). You can see it in logcat after you call reportFullyDrawn() :

ActivityManager: Fully drawn {package}/.MainActivity: +1s54ms
Copy the code

Tips from Facebook app developers

For years, Facebook app developers have been optimizing apps for billions of users across multiple devices, platforms, and countries. This section shares some of the key lessons Facebook app developers can use to optimize their app launches.

• Understand first, Optimize later – Once you have defined good startup metrics, you should use them to measure your application’s performance. This helps you understand your application’s startup performance and set priorities for improvement, making it a better experience for your users. Starting from quantitative detection, on the one hand, it can prove that there is room for improvement, and on the other hand, it can determine the direction of key efforts, and the specific improvement effect can be seen after the beginning of optimization.

• Fix the crash first – after you check the startup status, make sure the application actually starts. Crashes at startup are one of the most frustrating things you can do, and one of the fastest ways to get users to abandon your app. Prioritize and address these issues.

• Don’t forget functional reliability – also, don’t forget functional reliability. Does your app display some content quickly, but not load everything, or take too long to load images? Your application may start up quickly, but not perform as the user wants it to (for example, clicking a button doesn’t work), and these factors can worsen the user experience.

• Aim for consistency – Inconsistent performance is more frustrating than consistent performance that takes longer than average to start up. Watch the long tail of startup times to see if there are fixes or ways to alleviate these slow startup conditions. Be sure to check for offline and startup behavior that degrades network startup performance.

• Work in parallel – Most modern phones have at least 4 cpus, so there’s room for multitasking! Do not block the main thread unless you absolutely have to. Move I/O and non-critical paths to run outside the main thread.

• Deferred execution – After you have a reliable and consistent startup, take a look at everything you did to display the content of the first visible screen. Was there any work that wasn’t necessary? After the app launches, remove, postpone, or move any work that is not directly related to the startup experience to the background (but watch the responsiveness of the app as a control indicator). Try to keep your onCreate() application as light as possible. You can also use the Jetpack App Startup development library to initialize components when the application starts. When doing so, be sure to still load all the modules needed to start the activity, and be careful not to flash when lazy-loaded modules are available.

• Show progress, but don’t change the interface too much – please don’t change what you want to show the user too much during startup. It can be frustrating if a user tries to click on something and it changes and gets the wrong result. This is similar to the concept of cumulative layout offset (CLS) in Web Vitals. For network loading with variable duration, skip the startup screen and display placeholders for asynchronous loading. You might consider using a less conspicuous animation in this content area to reflect the loading status. Ensure that the content structure and placeholder structure of the specific load match as closely as possible to achieve a smooth transition after the content is loaded.

• Cache – When a user opens the application for the first time, you can display load indicators for some interface elements. The next time a user accesses your application, you can display the cached content while loading more of the latest content. Have you ever seen our Facebook feed showing the latest content we’ve pulled from the web after an app has loaded? If you can, take the network loading process out of startup to speed things up and achieve a more consistent startup performance experience. However, as suggested in the following point, displaying cached content is not always the best practice, so we need to measure and find elements that are more user-friendly.

• Combination of fast and Slow – New, relevant, but slightly slower display content is better than fast display outdated content. Showing your users the latest content directly is more valuable than launching super quickly and then having to refresh the content shortly after launching. You can evaluate whether it works better to optimize to display the latest content as quickly as possible, and to set timeouts to display older content when the network is slow; When the network is offline, the existing content is displayed.

• Consistent Session start screen – After your application has been in the background for a long time, you may find it a good idea to reset the user to your main content screen. Applications can remain in the device’s memory for a long time.

• See how it works internally – If you track and actually look at what executes during startup, or just use the debugger, you might find something amazing! With a good understanding of the critical path to startup, you can effectively optimize application performance. After identifying the element with the greatest potential for improvement, invest in that area.

• Make it easy to achieve the right results – developers sometimes use patterns and architectures that are not optimal because there are too many ways to do things. Feel free to integrate the patterns you use in your application and then optimize them so that it’s easy to pick the right approach to get things done and run efficiently. The eager Code Execution pattern is a good example: If you are executing content code that needs to appear after the first full-screen drawing, performance will definitely suffer. You might want to use a delayed execution mode and run the code in just-in-time mode only when the critical path to startup is blocked.

Advice from the Google Android team

The Google Android team’s recommendations for measuring and optimizing app launches can be found in the official document “App Launch Time.”

This section summarizes some key points that apply to all Android app developers and are relevant to the Facebook recommendations above.

• TTID and TTFD are important indicators of application startup. Google Android ranks apps by TTID in the Play Admin. TTFD is the parent set of TTID, so any improvements to TTID apply to both metrics.

• Call reportFullyDrawn() to report the TTFD and let the system know that the Activity has finished rendering. To improve app startup speed, The Android system adjusts to prioritize work that occurs before reportFullyDrawn() is called. Calling this method when your application is fully available can improve application startup time. Every application should use this API! Don’t forget to use it to measure app performance.

• Monitor your app’s technical performance with Android Vitals to help improve your app launch experience. In the Play Admin center, you can view data to help you understand and improve performance, such as app startup time.

• We know that fixing bugs in production is much more expensive than fixing them in development. The same applies to performance. You can set up your application with Jetpack Macrobenchmark: Startup to measure application Startup at an early stage using native performance testing.

• As we discussed above, quantitative testing is the key to understanding and optimizing startup. Android provides system tracing services that can help you dig deeper and diagnose application startup problems.

• With the Jetpack App Startup development library, we can directly and efficiently initialize components at application Startup time. Developers of both libraries and applications can use this library to simplify the startup process and explicitly set the initialization order. You can use this library to set which components are loaded at what time during startup.

• A typical problem that affects application startup is too much work at initialization. For example, padding layouts that are too large or complex, blocking screen drawing, loading and decoding bitmaps, garbage collection, etc.

conclusion

This article introduces some key startup time metrics and optimization best practices to improve the startup experience and help increase user engagement and usage of Facebook Android apps. This article also shares metrics, development libraries, and tools suggested by the Google Android team. Any Android application can benefit from the strategies shared in this article. Start by carefully quantifying your app launch and making it a quick and enjoyable experience!

Please click here to submit your feedback to us, or share your favorite content or questions. Your feedback is very important to us, thank you for your support!