☰
🔍
☰
🔍
20 พฤศจิกายน 2568
Posted by Alice Yuan - Senior Developer Relations Engineer
Welcome to day 4 of Performance Spotlight Week. Now that you've learned about some of the awesome tools and best practices we've introduced recently such as the R8 Optimizer, and Profile Guided Optimization with Baseline Profiles and Startup Profiles, you might be wondering where to start your performance improvement journey.
We've come up with a step-by-step performance leveling guide to meet your mobile development team where you are—whether you're an app with a single developer looking to get started with performance, or you have an entire team dedicated to improving Android performance.
The performance leveling guide features 5 levels. We'll start with level 1, which introduces minimal adoption effort performance tooling, and we'll go up to level 5, ideal for apps that have the resourcing to maintain a bespoke performance framework.
Feel free to jump to the level that resonates most with you:
We recommend first leveraging Android vitals within the Play Console for viewing automatically collected field monitoring data, giving you insights about your application with minimal effort.
Android vitals is Google's initiative to automatically collect and surface this field data for you.
Here's an explanation of how we deliver this data:
Collect Data: When a user opts-in, their Android device automatically logs key performance and stability events from all apps, including yours.
Aggregate Data: Google Play collects and anonymizes this data from your app's users.
Surface Insights: The data is presented to you in the Android vitals dashboard within your Google Play Console.
The Android vitals dashboard tracks many metrics, but a few are designated as Core Vitals. These are the most important because they can affect your app's visibility and ranking on the Google Play Store.
|
GOOGLE PLAY'S CORE TECHNICAL QUALITY METRICS
To maximize visibility on Google Play, keep your app below the bad behavior thresholds for these metrics. |
|
|---|---|
| User-perceived crash rate | The percentage of daily active users who experienced at least one crash that is likely to have been noticeable |
| User-perceived ANR rate | The percentage of daily active users who experienced at least one ANR that is likely to have been noticeable |
| Excessive battery usage | The percentage of watch face sessions where battery usage exceeds 4.44% per hour |
| New: Excessive partial wake locks | The percentage of user sessions where cumulative, non-exempt wake lock usage exceeds 2 hours |
The core vitals include user-perceived crash rate, ANR rate, excessive battery usage and the newly introduced metric on excessive partial wake locks.
You can use the Android Vitals ANR dashboard, to see stack traces of issues that occur in the field and get insights and recommendations on how to fix the issue.
You can drill down into a specific ANR that occurred, to see the stack trace as well as insights on what might be causing the issue.
Also, check out our ANR guidance to help you diagnose and fix the common scenarios where ANRs might occur.
Use the Android vitals crflevelash dashboard to further debug crashes and view a sample of stack traces that occur within your app.
Our documentation also has guidance around troubleshooting specific crashes. For example, the Troubleshoot foreground services guide discusses ways to identify and fix common scenarios where crashes occur.
To decrease watch face sessions with excessive battery usage on Wear OS, check out the Wear guide on how to improve and conserve battery.
We recently announced that apps that exceed the excessive partial wake locks threshold may see additional treatment starting on March 1st 2026.
For mobile devices, the Android vitals metric applies to non-exempted wake locks acquired while the screen is off and the app is in the background or running a foreground service. Android vitals considers partial wake lock usage excessive if wake locks are held for at least two hours within a 24-hour period and it affects more than 5% of your app's sessions, averaged over 28 days.
To debug and fix excessive wake lock issues, check out our technical blog post.
Consult our Android vitals documentation and continue your journey to better leverage Android vitals.
Next, move onto using the App Performance Score to find the high leverage action items to uplevel your app performance.
The Android App Performance Score is a standardized framework to measure your app's technical performance. It gives you a score between 0 and 100, where a lower number indicates more room for improvement.
To get easy wins, you should first start with the Static Performance Score first. These are often configuration changes or tooling updates that provide significant performance boosts.
The static assessment evaluates your project's configuration and tooling adoption. These are often the quickest ways to improve performance.
Navigate to the Static Score section of the scoreboard page and do the following:
Assess Android Gradle Plugin (AGP) Version.
Adopt R8 Minification incrementally or ideally, use R8 in full mode to minify and optimize the app code.
Adopt Baseline Profiles which improves code execution speed from the first launch providing performance enhancements for every new app install and every app update.
Adopt Startup Profiles to improve Dex Layout. Startup Profiles are used by the build system to further optimize the classes and methods they contain by improving the layout of code in your APK's DEX files.
Upgrade to the newest version of Jetpack Compose
Once you have applied the static easy wins, use the dynamic assessment to validate the improvements on a real device. You can first do this manually with a physical device and a stop watch.
Navigate to the Dynamic Score section of the scoreboard page and do the following:
Set up your test environment with a physical device. Consider using a lower-end device to exaggerate performance issues, making them easier to spot.
Measure startup time from the launcher. Cold start your app from the launcher icon and measure the time until it is interactive.
Measure app startup time from a notification, with the goal to reduce notification startup time to be below a couple seconds.
Measure rendering performance by scrolling through your core screens and animations.
Once you've completed these steps, you will receive a score between 1 - 100 for the static and dynamic scores, giving you an understanding of your app's performance and where to focus on.
Once you've started to assess dynamic performance, you may find it too tedious to measure performance manually. Consider automating your performance testing using performance test frameworks such as Macrobenchmarks and UiAutomator.
Think of Macrobenchmark and UiAutomator as two tools that work together: Macrobenchmark is the measurement tool. It's like a stopwatch and a frame-rate counter that runs outside your app. It is responsible for starting your app, recording metrics (like startup time or dropped frames), and stopping the app. UiAutomator is the robot user. The library lets you write code to interact with the device's screen. It can find an icon, tap a button, scroll on a list and more.
When you write a test, you wrap your UiAutomator code inside a Macrobenchmark block.
Define the Test: Use the @MacrobenchmarkRule
Start Measuring: Call benchmarkRule.measureRepeated.
Drive the UI: Inside that block, use UiAutomator code to launch your app, find UI elements, and interact with them.
Here's an example code snippet of what it looks like to test a compose list for scrolling jank.
benchmarkRule.measureRepeated(
// ...
metrics = listOf(
FrameTimingMetric(),
),
startupMode = StartupMode.COLD,
iterations = 10,
) {
// 1. Launch the app's main activity
startApp()
// 2. Find the list using its resource ID and scroll down
onElement { viewIdResourceName == "$packageName.my_list" }
.fling(Direction.DOWN)
}
Review the results: Each test run provides you with precisely measured information to give you the best data on your app's performance.
timeToInitialDisplayMs min 1894.4, median 2847.4, max 3355.6
frameOverrunMs P50 -3.2, P90 6.2, P95 10.4, P99 119.5
Macrobenchmark provides several core metrics out of the box. StartupTimingMetric allows you to accurately measure app startup. The FrameTimingMetric enables you to understand an app's rendering performance during the test.
We have a detailed and complete guide to using Macrobenchmarks and UiAutomator alongside code samples available for you to continue learning.
Trace analysis tools like Perfetto are used when you need to see beyond your own application code. Unlike standard debuggers or profilers that only see your process, Perfetto captures the entire device state—kernel scheduling, CPU frequency, other processes, and system services—giving you complete context for performance issues.
Check our Performance Debugging youtube playlist for video instructions on performance debugging using system traces, Android Studio Profiler and Perfetto.
The general workflow for debugging performance using trace analysis tools is to record, load and analyze the trace.
You can record a system trace using several methods:
Recording a trace manually on the device directly from the developer options.
Using the Android Studio CPU Profiler
Using the Perfetto UI
Once you have the trace file, you need to load it into the analysis tool.
Open Chrome and navigate to ui.perfetto.dev.
Drag and drop your .perfetto-trace (or .pftrace) file directly into the browser window.
The UI will process the file and display the timeline.
You can use Perfetto UI or Android Studio Profiler to investigate performance issues. Check out this episode of the MAD Skills series on Performance, where our performance engineer Carmen Jackson discusses the Perfetto traceviewer.
Perfetto is an expert tool and can provide information about everything that happened on the Android device while a trace was captured. This is particularly helpful when you cannot identify the root cause of a slowdown using standard logs or basic profilers.
If your app stutters while scrolling, Perfetto can show you exactly why a specific frame missed its deadline.
If it’s due to the app, you might see your main thread running for a long duration doing heavy parsing; this indicates scenarios where you should move the work into asynchronous processing.
If it’s due to the system, you might see your main thread ready to run, but the CPU kernel scheduler gave priority to a different system service, leaving your app waiting (CPU contention). This indicates scenarios where you may need to optimize usage of platform APIs.
Startup is complex, involving system init, process forking, and resource loading. Perfetto visualizes this timeline precisely.
You can see if you are waiting on Binder calls (inter-process communication). If your onCreate waits a long time for a response from the system PackageManager, Perfetto will show that blocked state clearly.
You can also see if your app is doing more work than necessary during the app startup. For example, if you are creating and laying out more views than the app needs to show, you can see these operations in the trace.
Because Perfetto sees the whole system, it's perfect for finding invisible power drains.
You can identify which processes are holding wake locks, preventing the device from sleeping under the “Device State” tracks. Learn more in our wake locks blog post. Also, use Perfetto to see if your background jobs are running too frequently or waking up the CPU unnecessarily.
The final level is for apps that have teams with resourcing to maintain a performance tracking framework.
Building a custom performance tracking framework on Android involves leveraging several system APIs to capture data throughout the application lifecycle, from startup to exit, and during specific high-load scenarios.
By using ApplicationStartInfo, ProfilingManager, and ApplicationExitInfo, you can create a robust telemetry system that reports on how your app started, detailed info on what it did while running, and why it died.
Available from Android 15 (API 35), ApplicationStartInfo provides detailed metrics about app startup in the field. The data includes whether it was a cold, warm, or hot start, and the duration of different startup phases.
This helps you develop a baseline startup metric using production data to further optimize that might be hard to reproduce locally. You can use these metrics to run A/B tests optimizing the startup flow.
The goal is to accurately record launch metrics without manually instrumenting every initialization phase.
You can query this data lazily some time after application launch.
ProfilingManager (API 35) allows your app to programmatically trigger system traces on user devices. This is powerful for catching transient performance issues in the wild that you can't reproduce locally.
The goal is to automatically record a trace when a specific highly critical user journey is detected as running slowly or experiencing performance issues.
You can register a listener that triggers when specific conditions are met or trigger it manually when you detect a performance issue such as jank, excessive memory, or battery drain.
Check our documentation on how to capture a profile, retrieve and analyze profiling data and use debug commands.
ApplicationExitInfo (API 30) tells you why your previous process died. This is crucial for finding native crashes, ANRs, or system kills due to excessive memory usage (OOM). You'll also be able to get a detailed tombstone trace by using the API getTraceInputStream.
The goal of the API is to understand stability issues that don't trigger standard Java crash reporters (like Low Memory Kills).
You should trigger this API on the next app launch.
Improving Android performance is a step-by-step journey. We're so excited to see how you level up your performance using these tools!
You have shrunk your app with R8 and optimized your runtime with Profile Guided Optimization. And measure your app's performance.
Join us tomorrow for the live Ask Android session. Ask your questions now using #AskAndroid and get them answered by the experts.
Android Developers
Google Play
