Inspecting Performance
This MAD Skills article on inspecting performance introduces you to tools and methods that help when your code’s performance. When you inspect performance you make sure that what’s happening in your app aligns with what you expect to happen.
You can also watch this article as a MAD Skills video.
Inspecting performance is ensuring that what’s happening in your app aligns with your expectations.
We’re differentiating performance inspection in three stages: Passive, manual and automated. Each has its own place to shine and reason to be used.
Passive performance inspection
When we speak of passive performance inspection, we mean that there’s no extra work necessary to spot a performance problem, other than running it and looking at the existing output. Some problems, such as frozen frames and slow behavior can be seen when interacting with the app directly. This can help you find areas to improve your app, especially when running your app on a device with low specs such as CPU power or RAM.
Next to running the app and evaluating jank directly on screen, you can use logcat to check for slow and dropped frames, which are logged automatically for you.
Slow frames
Use the new Logcat in Android Studio to filter for the Choreographer tag and you can see dropped frames while running the app. As soon as more than 30 frames have been skipped, it’ll be logged.
Frozen frames
Frames which take longer than 700ms to render will be logged with the OpenGLRenderer tag and some more detailed information.
Non-responsive Activity
And if your app is unresponsive for more than 5 seconds, you’ll see the Activity Non-Responsive (ANR) dialog.
App launches
You can also see app launch durations in logcat, by filtering for the ActivityTaskManager tag.
Time to Initial Display (TTID) will be logged with Displayed.
Time to Full Display (TTFD) is logged with Fully Drawn.
App launch times of less than 500 ms (0.5 seconds) are desirable, as users perceive longer launch durations negatively.
You can read more about these metrics in the previous article on MAD Skills Performance Metrics.
Passive inspection is a great starting point to see if there are problems and can help you to roughly point in the right direction of a problem. To actually qualify which part of an app caused the problem, passive inspection rarely is enough. You’ll need to inspect your app’s code actively.
Manual performance inspection
When you have a rough understanding which parts of an app are not performing as you expect, it’s time to manually inspect what’s going on in depth. Android Studio ships with a suite of profilers which are ready to help you inspect what’s going on in your app.
Android Studio’s Profilers have parallels to the Debugger. What the Debugger is for stepping through code, looking at parameter and property values, the Profiler is for inspecting CPU, Memory, Network usage as well as possible sources of Jank.
The Profiler helps you get a detailed understanding of where a problem occurs.
And while you are developing an app, the debugger allows you to attach to an app during development and inspect problems in depth, using builds that are debuggable is most likely giving wrong performance data.
Always inspect release builds on real devices
Debuggable builds provide many features useful for development, like live edit, applying changes without reinstalling the app, or inspecting property values, changing data and otherwise using Android Studio’s debugging capabilities.
Builds that are marked as debuggable also add a performance overhead to your app. This makes performance metrics unreliable. Something that might look performing poorly on a debuggable build, actually can work well on a release build.
To verify whether a performance issue exists in a production environment or only during development, make sure to verify it on a release build release version of your app.
Set your build variant to release by switching the Build Variant to your most production like build. The Now in Android sample uses `prodRelease` for this.
Also, in your AndroidManifest.xml, mark the application as profileable. This allows profilers to inspect what’s going on in a production build.
<!--AndroidManifest.xml--><manifest...
<application...
<profileable android:shell=”true” tools:targetApi=”q” /
</application>
</manifest>
You need to inspect release builds on a physical device.
The Android Emulator has come a long way. It boots quickly, runs smoothly and provides a seamless experience during app development. But when it comes to measuring performance, the Android Emulator is not the right tool.
When you inspect performance on an Emulator, you’re not measuring against an Android device with physical constraints but against the host machine’s capabilities. If a host system is under heavy load, the inspected app will be less performant.
Inspecting performance on a physical device will provide you with consistently useful data.
More MAD Skills on manual performance inspection
Because manual inspection of performance is a full topic on its own, we produced an entire series which aims at helping you to get a deep understanding on manual performance debugging. You can check it out here.
Automated performance inspection
Passive and manual inspection are important steps when inspecting performance. The third way to inspect performance, and likely the most reliable one to give you consistent results, is automated performance inspection. With automated performance inspection, you can reliably run the same steps in a flow time after time.
Automated inspection can help prevent a performance issue before it is shipped to your users.
And while the automation process takes a little setup, you get peace of mind when it comes to ensuring your app’s performance is consistent. We provide the Jetpack Macrobenchmark library to help you automate performance inspection. This library allows you to automate inspecting performance of entire user flows. When using the Jetpack Macrobenchmark library, you can measure key metrics such as app startup, frame timing, and other performance metrics.
Getting Started with Jetpack Macrobenchmark
All you need to get started with Jetpack Macrobenchmark is a recent version of Android Studio. We recently released a codelab that guides you through the process of creating and running your first Macrobenchmark.
Also, the overall guidance on how to create a Macrobenchmark gives you the latest instruction on getting started.
While you wait for the next article
In the next article we’ll introduce you to a fast way to improve your app’s performance with Baseline Profiles.
Go and check out our improved developer documentation, which we have been updating with MAD guidance.
To get more hands on, check out the samples on GitHub.
Or take the Macrobenchmarking Codelab or Baseline Profiles Codelab for hands on guidance through the topics.
Also, make sure to ask your questions in the video comments or on Twitter, using #MADPerfQA to get answers directly from the Engineers working on Android Performance.
