After you release an Android application, you need to ensure a smooth, engaging experience for users. Poor performance and heavy resource consumption can cause your application to rank lower for prospective users in the Google Play Store, and existing users can become frustrated and even uninstall your application. All of this can spell trouble for business-related performance indicators like engagement and discoverability. To help ensure a positive experience for mobile users, Datadog now monitors Mobile Vitals for Android, metrics that track fundamental health and performance indicators from your applications (based on Android vitals). You can view these metrics in the context of RUM events, crash logs, and backend application request traces in Datadog, giving you comprehensive visibility into mobile app performance.
In this post, we will introduce the following Mobile Vitals metrics:
- Slow rendering
- Frozen frames
- Application not responding
- Crash-free sessions
- CPU utilization
- Memory utilization
Key metrics for Android application performance
Slow rendering
When slow rendering takes place, each frame within a view appears on the screen with a delay, causing an application to be choppy or unresponsive. Datadog measures slow rendering in terms of refresh rate—the number of frames rendered over time—which has an industry benchmark of 60 frames per second. Slow rendering indicates that the CPU or GPU is doing more work than necessary to render a frame, which leads to unhealthy battery usage.
Mobile Vitals lets you track the percentage of views with an average refresh rate of 45 frames per second or less so you can gauge your application’s responsiveness to user interactions. Since devices can have different maximum refresh rates, Mobile Vitals scales this metric to a value between zero and 60, allowing you to track your application’s refresh rate regardless of hardware-specific restrictions.
Datadog also tracks the average refresh rate during the lifetime of a particular view, starting from when a user first loaded the view. In the example below, we can see that one view has an average refresh rate of 25.84 frames per second, slow enough for users to perceive flickers.
Frozen frames
A frozen frame occurs when a particular UI frame is taking longer than 700 ms to render. Frozen frames make your application appear temporarily unresponsive to users, which not only causes frustration, but can also lead to ANRs when they extend beyond five seconds. Mobile Vitals shows you if a view has run into any frozen frames, and how long those frozen frames lasted, so you can focus your efforts on problematic parts of your application code.
Application not responding
The application not responding (ANR) metric indicates when your application takes longer than five seconds to respond to a user interaction. When this happens, Android will display an ANR dialog giving users the option to exit an application. In terms of user experience, ANRs are as serious as crashes (which Datadog also lets you track), since they signal that your users can no longer interact with your application. Using this metric, you can see precisely when an ANR takes place during the course of a view, giving you the context you need to troubleshoot.
In the view below, we can see that an ANR took place in the middle of two long tasks, which occur when the main thread is blocked for longer than a user-configured duration (100 ms by default). Since the ANR and the long tasks appear related, we can see which tasks take place after rendering the “Load Screen” view and investigate ways to alleviate them.
Crash-free sessions
To ensure that your applications provide a smooth experience for users, you’ll want a baseline assurance that user sessions tend to run without crashes or ANR messages. Mobile Vitals lets you track the percentage of sessions in a given timeframe that run without a crash or ANR, grouped by application version.
If the percentage of crash-free sessions is lower than usual for a specific version, you should release a patch as soon as possible. But if your application is crashing more frequently than usual across multiple recent versions, the issue may have to do with unexpected responses from your backend infrastructure. For example, an API endpoint may be returning 5xx errors, or may have recently been updated to send response payloads in a new format. To investigate further, you can use the RUM Explorer to see if your application views have run into errors, and inspect related APM traces for any errors on the backend.
CPU utilization
Mobile Vitals tracks the average number of CPU ticks per second over the course of a single view within a user session. The higher the number, the more frequently your application used the CPU during a session. High CPU utilization affects battery consumption on user devices, so staying on top of this metric ensures that your users can sustainably use your application—and will not uninstall it to preserve their battery. This example shows a view with particularly poor CPU consumption.
You can also use Mobile Vitals to track CPU utilization across an entire user session, making it easier to spot view loads that are particularly hard on battery life. Below, we can see that the “Cart” view uses an outsize proportion of CPU time.
Memory utilization
If an Android application cannot allocate an object in memory, it throws an OutOfMemoryError that causes the runtime to suddenly crash and display a notification that your application “has stopped,” creating a poor user experience. For each user session, Datadog measures the amount of physical memory currently being used by your application, in bytes, over the lifetime of each view.
With Mobile Vitals, you can also track memory utilization for all views within a single session, helping you identify memory leaks, problem areas, and opportunities for optimization. In the example below, we can see that, while seven views loaded at the end of the session each used a moderate amount of memory, in total these views used over 1 GB. Since this much memory usage can pose issues for user devices running other applications, we investigate ways to reduce the memory footprint of these views.
If your Android applications are using high levels of memory and running into OOM errors, you should consider designing them to detect low-memory conditions via the OS and adjust their memory utilization accordingly. You can also use Datadog’s dashboards and Error Tracking view to get even more insights about OOM errors and other Android crashes.
All your vitals in one place
In this post, we have shown you how to monitor Mobile Vitals to ensure that your Android applications are providing a smooth experience for users. To start collecting Mobile Vitals, edit your build.gradle file to include the Datadog RUM gradle plugin and SDK. Then use the Datadog UI to generate a client token and application ID, and add these to your Android application when you initialize the SDK.
The Mobile Vitals metrics provide a layer of visibility into your mobile application performance on top of Mobile RUM, which supports iOS, Android, and React Native. You can also jump straight from errors in mobile RUM to Datadog Error Tracking, so you can see all of your mobile application errors in the context of broader trends—and know which ones to address first.
If you are not yet a Datadog customer, you can sign up for a free trial.
