An app's performance has a direct impact on user experience and bounce rates. In particular, loading times and app crashes are major factors that cause users to leave.

Bounce rate based on loading time:

• Delay of 3 seconds or more: 43% of users said this was unacceptable.
• Delay of 5 seconds or more: The bounce rate increases to 90%.
• Delay of 6 seconds or more: The bounce rate increases to 106%.
• Delays of 10 seconds or more: The bounce rate increases to 123%.

In addition to slow load times, customers also have a high bounce rate when the app shuts down abruptly. According to statistics, when an app is turned off, 70% of users leave the app immediately.

These statistics show that optimizing an app's performance is linked to the user churn rate, which is one of the important points leading to revenue. Developers know they need to manage this performance, but they often wonder what metrics to focus on.

In this post, we'll look at key metrics to pay attention to in order to efficiently manage app performance using Android Vitals, which is a mobile performance indicator proposed by Google.

Android Vitals

Android Vitals is a performance metric collected by Google Play to improve the quality of apps. If you've already distributed the app to the store, performance data is probably being collected.

Android Vitals is not a standard performance indicator for mobile or Android by narrowing down the scope, but currently there are no standard indicators representing Android performance, and since it is a performance index proposed by Google, it includes key elements that improve the performance quality of apps.

Android Vitals is divided into Core Vitals, which are related to cases such as closing an app, and Other Vitals where performance may slow down or slow down. In this post, I'll introduce some of the key Android vitals developers should cover.

Note, this article has nothing to do with how to view Android Vitals on the Google Play Store. Please note that this article introduces Android Vitals as a performance indicator, and various monitoring tools support Android Vitals.

Crash

As mentioned before, if an app closes due to any issues, customers will feel uncomfortable and won't use the app anymore.

In particular, on Android, crashes can occur not only in activities, but also in Android components such as broadcast receivers and content providers running in the background. Also, crashes often occur not only in business logic developed in Java or Kotlin, but also in logic developed with native.

Above all, when a crash occurs, you need to know where the problem occurred.

On Android, you can easily find the cause of the problem by collecting Crash Stacks. If you want to find the problem when the crash occurred yourself uncaughtException Handler Errors can be easily caught by using

In addition to identifying the cause of the problem through the Crash Stack, it is also important to measure various crash statistics. Key indicators include the following items.

• Number of crashes per user per day
• Number of users with multiple crash experiences : Users who have crashed 2 or more times

Especially in the case of Google Play, if the following threshold is exceeded An alert occurredThey also do, so you need to manage Crash well.

• Overall incorrect behavior threshold: Across all device models, at least 1.09% of daily active users experience user-detectable crashes.

• Incorrect operating threshold per device: for a single device model
  ‍At least 8% of daily active users experience user-detectable crashes.

ANR

If you use an Android phone, you've probably experienced the following screen at least once. If the UI thread of an Android app works for a long time, Application Not Rejected, or ANR, will occur.

ANR is an issue caused by an app's performance issue, which can cause customers to close the app and cause issues such as Crash.

However, if the customer closes the app due to ANR, the OS forcibly terminates the process, as mentioned above uncaughtException Handler This information cannot be collected by

Let's look at a simple sample that causes ANR.

If the button is clicked and you get 10,000 sleeps, the click event thread won't respond and will wait for 10 seconds. At this point, the OS generates ANR.

In this way, ANR occurs when a thread is blocked for a certain period of time. Not all threads are targeted, but the UIThread or Main Thread, which is responsible for user reactions, is the target of ANR.

Most ANRs occur in the following pattern:

• When an app performs slow tasks related to I/O on the main thread

• When an app performs lengthy calculations on the main thread

• When the main thread makes a synchronous binder call to another process and that process takes a long time to return

• When waiting or deadlocked due to a thread different from the main thread

When ANR occurs, an ANR log is generated. If ANR occurs with the above code, the following log is recorded.

Through the last line Thread.sleepYou can confirm that the problem occurred in

App startup time

It's quite obvious, but users want the screen to pop up quickly. Conversely, it was explained earlier that users are more likely to delete the app if it starts slowly.

The most basic criterion for users to recognize that an app's performance is fast or slow is screen load time. I need to start the app and load the screen quickly, but how slow should it be, and how fast should it be fast?

Measuring screen load times isn't as simple as you might think. This is because there are various situations and cases. In particular, since there are various app launch types, they can be measured differently.

There are hot, warm, and cold start types for app startup. If the performance of a cold start that includes all of them is well improved, the performance of the rest of the warm and hot starts can also be improved.

When you first start an app, a cold start is initiated, during which the OS performs various tasks and starts a process for running the app. However, the tasks that developers can do to improve performance are done in the following order:

• application.onCreate
• MainActivity.onCreate
• MainActivity.onStart

Therefore, it is very important to accurately trace each section to shorten the time.

When the app starts, it is necessary to carefully monitor performance issues that occur in your app, such as whether the security program or various external daemons take too long to run for the first time, and whether the activity is loading too heavy and too much data initially, and reduce time through synchronous/asynchronous processing, caching/paging, etc.

Slow Rendering

Customers feel that the screen runs naturally when the frame is rendered within 60 frames, or 16 ms.

If it takes 16 ms or more, it is classified as a slow frame, if it is 700 ms or more, the frame stops, and ANR occurs when there is a delay of 5 seconds or more. If a frame is delayed, the frame is deleted rather than displayed late. Because of this, users feel that screen movement is interrupted. This is called jank.

Android Vitals allows you to monitor Jank. JankStats library (link)You can check the figures related to Jank by using.

But above all else, frame rendering is related to device performance. Problems are more likely to occur on low-performance devices, so it's a good idea to test with actual low-performance devices or lower performance through emulator options. Even during actual monitoring, it's a good idea to look at the device or network situation together instead of just checking the jank value.

battery

There is a close relationship between battery and performance. The connection is very large, especially on mobile devices. Basically, a battery is the device most related to heat generation, so when the battery is consumed excessively, heat is generated, and the OS may be forced to reduce performance in order to cool down the heat

Also, when the battery is running low, battery saving mode or low power mode is activated, which limits processing speed or graphics processing performance and may slow down the app. Therefore, apps need to manage excessive battery usage. Developers must control the following battery consumption factors:

• Incurable wakeups
• Scans Wi-Fi Scanning in the Background
• Maintains Mobile Network Usage in Background

Too many unnecessary app notifications, Wi-Fi scans, and network requests consume a lot of battery. The more the CPU or device's modules are used, the more battery is consumed. Reducing these cases as much as possible through effective business design is a way to reduce battery consumption.

Rather than monitoring battery usage itself, it's more important to monitor and optimize cases like the one above.

At the end

In this post, I looked at what metrics should be collected to manage mobile performance with Android Vitals. Since it is an Android performance indicator proposed by Google, basic metrics can be checked by distributing the app to the Google Play Store, so there is no need for developers to make an effort to collect these indicators themselves, but it is recommended to use a mobile monitoring tool if detailed analysis is required.

Most mobile monitoring tools collect metrics based on Android Vitals, so it's a good idea to use monitoring tools to improve the quality of your app. Check the quality of your app on Android Vitals.