How to improve application startup performance | Facebook application experience sharing

Author / Google and Facebook team
/ Kateryna Semenova of Google Android team and Tim Trueman, Steven Harris, Subramanian Ramaswamy of Facebook team

Profile

Shortening the startup time of an application is not a trivial matter, we must have a deep understanding of its influencing factors. This year, the Google Android team and the Facebook application team have been collaborating on quantitative indicators in this area and sharing optimization methods to improve application launching. Google Android’s public documents contain a lot of information about application launch optimization . Here we want to further share its practice in the Facebook application, and what factors help to improve application startup performance.

Now, more than 2.9 billion people use Facebook every month. Facebook helps people build communities and connect the world more closely. Users will share life moments here, understand and discuss what is happening, establish and cultivate interpersonal relationships, and work together to create income opportunities.

Facebook application developers are committed to ensuring that users enjoy the best experience and allowing applications to run smoothly on any device, any country/region, and different network conditions. The Google Android team and the Facebook team have sincerely collaborated to reach a consensus on the definition and best practices of app launch time, and share them with you here.

where to start

The first of course is to measure the startup time of the application. You can learn about the health of the user's startup experience, track the deterioration of startup time, 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 determine the priority of investment.

Android defines two metrics to measure the application startup time: fully shows the time used (TTFD) and initially shows the time used (TTID). Although you can further divide it into cold/warm start time, this article will not explain the difference between them. Facebook’s method is to measure and optimize the start time experienced by all users interacting with the app (some are cold start , Some are warm start).

Time-To-Full-Display (TTFD)

TTFD records the time required for your application to complete rendering and be available for user interaction and use, which may include the time required to display content from local storage or from the network. If the network is slow, this may take a while and will vary depending on the user's device. Therefore, it is necessary for us to show some content immediately, so that users can see the process of application startup, and this will mention TTID...

Time-To-Initial-Display (TTID)

TTID records the time it takes for your app to display background, navigation, fast-loading local content, slow-loading local or web content placeholders. The TTID should be the time required for the user to be able to navigate around and get to their goal.

Don’t change too much: One thing to pay attention to is the visual change of the application content between TTID and TTFD. For example, the cached content is displayed on the page first, and then the page content is suddenly switched after the web content is loaded. . This sudden change may make users feel uncomfortable and frustrated, so make sure your app can display meaningful enough content during TTID, and show users as much as possible what they will see during TTFD.

Achieve user goals

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

Facebook application developers focused on the fully display (TTFD), including the display of all content and images, because this represents the user's complete experience of accessing the application. Developers want to know whether it takes a long time to load content and images on the network or fails to load so that the team can improve the entire startup experience from start to finish.

What should be a good TTID and TTFD target?

Facebook set the startup time indicator as the percentage of what they consider to be "bad" application startup time, that is, any startup or startup failure portion of TTFD that exceeds 2.5 seconds (for example, the image fails to load or the application crashes). Facebook is committed to reducing the proportion of "poor" startup times by improving startup times that take more than 2.5 seconds to get rid of the "bad" state and fixing the problems that cause startup failures. 2.5 seconds was chosen because research shows that it is important for Facebook users. This is also in line with Web Vitals recommended for the website maximum content drawing (LCP) index.

Compared with TTID, providing a complete experience, especially using the network to get the most recent content, will make your TTFD startup indicators look quite slow. And this is actually a good thing! It reflects the real user experience of your application. Your improvements to this may, like Facebook, increase the user’s application usage rate and recognition of its performance.

How tricky it is to measure TTFD may vary depending on your application. If it is too difficult, you might as well start initial display of the time (TTID) from 161c3053b40e45. Although the existence of placeholders or images may make it impossible to quantify the loading performance of some content, this is still a starting point. After all, this part is also the content (although not all) of the user's daily interaction with the application.

detects TTID

In Android 4.4 (API level 19) and higher, logcat provides the " Displayed " value to record the elapsed time from the start of the process to the completion of the first frame of the corresponding Activity on the screen.

The reported log line is similar to the following example:

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

detects TTFD

reportFullyDrawn() in Activity after all your content is displayed on the screen. Be sure to include any content that replaces the placeholder, and any images you render (be sure to calculate the time the image itself is displayed, not just the time that its placeholder is displayed). After you call reportFullyDrawn(), you can see it in logcat:

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

from Facebook app developers

Over the years, Facebook app developers have been optimizing apps for billions of users across many devices, platforms, and countries/regions. This section shares some key experiences used by Facebook app developers when optimizing app launch.

• first understand, and then optimize -after defining a good startup index, you should use it to detect the specific performance of the application, which helps to understand the startup performance of the application and set the priority of improvement, which will bring more to your users Good experience. Starting with quantitative testing, one can prove that there is room for improvement, and second, the direction of key efforts can be determined, and specific improvement effects can be seen after the start of optimization.
• First fix the crash -After you check the startup status, please make sure that the application can actually be launched. Crash at startup is the most frustrating thing and the fastest way to get users to abandon your app. Please prioritize and deal with these issues.
• n't forget the functional reliability -Also, don't forget the functional reliability. Is your app able to display some content quickly, but fails to load all the content, or does it take too long to load images? Your application may start quickly, but fail to operate according to user requirements (for example, clicking a button does not work), these factors will deteriorate the user experience.
• for consistency -Inconsistent performance is more frustrating compared to performance that is consistent but takes longer than average to start. Observe the long tail of the startup time to see if there are repair measures or methods to alleviate these slow startup conditions. Be sure to check your offline and startup behaviors that impair network startup performance.
• parallel -Most contemporary mobile phones have at least 4 CPUs, so there is room for multitasking! Don't block the main thread unless you have to. Move I/O and non-critical paths to run outside of the main thread.
• Delayed execution of -After achieving a reliable and consistent startup, please review everything you did to display the content of the first visible screen. Is there some work that is unnecessary? After the application is launched, please remove, postpone, or move any work that is not directly related to the launch experience to the background (but pay attention to the responsiveness of the application and use it as a control indicator). Try to keep your application's onCreate() as lightweight as possible. You can also use the Jetpack App Startup development library to initialize the components when the application starts. When doing so, make sure that all modules required to start the activity are still loaded, and be careful not to cause flickering when the delayed-loaded modules are available.
• show progress, but not too much change the interface - Do not over-changing content to be presented to the user during startup. If the user tries to click on the content, it changes and gets the wrong result, which is very frustrating. This is similar to the cumulative layout offset (CLS) concept in Web Vitals For network-side loading with variable duration, please skip the splash screen and display a placeholder for asynchronous loading. You can consider using the less conspicuous animation in this content area to reflect the loading status. Make sure that the specific loaded content structure and the occupancy structure match as much as possible to achieve a smooth transition after the content is loaded.
• Cache -When the user opens the application for the first time, you can display loading indicators for some interface elements. When the user visits your app next time, you can display the cached content while loading more up-to-date content. Have you ever seen us display the latest content obtained from the Internet in a dynamic update of Facebook after the application is loaded? If possible, please exclude the network loading process from the startup, which can speed up and achieve a more consistent startup performance experience. However, as the next point suggests, displaying cached content is not always the best practice, so we need to measure and find elements that are more user-friendly.
• fast and slow combined with -new, relevant, but slightly slower content is better than fast-displayed outdated content. Showing the latest content directly to your users is super quicker than launching it, but refreshing the content shortly after launching is more valuable. You can evaluate whether the following practices are better: Optimize to display the latest content as quickly as possible, and set a timeout to display older content when the network is slow; display existing content directly when the network is offline .
• Consistent session start interface -After your app is in the background for a long time, you may find that resetting the user to your main content interface is a good practice. The application can remain in the device's memory for a long time.
• View the inner workings of -If you track and actually check the content executed during startup, or simply use the debugger, you may have surprising new discoveries! After you fully understand the critical path of startup, you can efficiently optimize application performance. After discovering the elements with the greatest room for improvement, invest in this area.
• ensures that the correct results can be easily achieved. -Developers sometimes use suboptimal patterns and architectures because there are too many ways to do things. Feel free to integrate the patterns used in your application and optimize them so that you can easily choose the right method to complete the task and make it run efficiently. The eager code execution mode 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 may wish to adopt a delayed execution mode, and run the code in real-time execution mode only when the critical path of startup is blocked.

Google Android Team

For suggestions from the Google Android team on measuring and optimizing application launches, please refer to the official document " Application Launch Time ".

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

• TTID and TTFD are important indicators of application startup. Google Android will Play Management Center according to TTID. TTFD is the mother set of TTID, so any improvement measures of TTID are applicable to these two indicators at the same time.
• Call reportFullyDrawn() to report TTFD and let the system know that the Activity has finished rendering. In order to improve the application startup speed, the Android system will make adjustments to prioritize the work that occurs before reportFullyDrawn() Calling this method when your application is in a fully usable state can improve the startup time of the application. Every application should use this API! Don't forget to use it to measure application performance.
• Use Android Vitals to monitor the technical performance of your app, which helps to improve the app launching experience. Through Play Management Center , you can view various data to help you understand and improve performance such as application startup time.
• We know that repair costs in a production environment are much higher than repairing errors during the development phase. This also applies to performance. You can set up your application with the help of Jetpack Macrobenchmark: Startup to use local performance tests to measure application startup in the early stage.
• As we discussed above, quantitative testing is the key to understanding and optimizing startup. Android provides the system tracking service, which can help dig deeper and diagnose application startup problems.
• Through the Jetpack App Startup development library , we can directly and efficiently initialize the components when the application starts. Developers of development libraries and applications can use this library to simplify the startup process and clearly set the initialization sequence. You can use this library to set which components are loaded at what time during startup.
• A typical problem of that affects application startup is that does too much work during initialization. For example, fill overly large or complex layouts, prevent screen drawing, load and decode bitmaps, garbage collection, etc.

summary

This article introduces some key startup time indicators and optimization best practices to improve the startup experience and help increase user engagement and usage of the Facebook Android application. This article also shares the indicators, development libraries, and tools recommended by the Google Android team. Any Android application can benefit from the strategies shared in this article. Please get started, seriously quantify the startup situation of the application, and create a fast and pleasant application startup experience for users!

Welcome to Click here to submit feedback to us, or share your favorite content, found problems. Your feedback is very important to us, thank you for your support!