Developing for Android IXTools

[Previous Chapter — User Interface]

There are are many tools provided with Android to help debug and analyze problems that your app may face in trying to get the best performance. These tools range from memory analysis tools such as Allocation Tracker (in ddms and Android Studio) to on-device performance measurement tools.

It is important to not only know that these tools exist, but to actually use the tools, to verify that your application is behaving the way you want (hitting 60 fps, avoiding garbage churn, etc.). Help make Android a better platform overall by tuning what you can and improving the overall experience.

There are two types of tools commonly used to analyze performance: host and on-device. Host tools are those that run on the host computer (via command-line, DDMS, Android Studio, etc.). On-device tools are utilities that show you information in real time on the device about what is happening, usually related to performance metrics.

Host Tools

Systrace

Systrace is a powerful tool that shows the occurrence and duration of various events in the system on a timeline. You run the tool to capture data, then open the resulting trace file in a browser to analyze the results.

The tool can run from Android Studio or from the command line via $SDK_ROOT/platform-tools/systrace/systrace.py.

AllocationTracker

AllocationTracker can be run from the ddms tool or directly from inside Android Studio. It allows you to find out about all allocations that occur between the times when you start and then capture the data. This tool is invaluable for finding out whether and where you are allocating during times when you generally should not. For example, to find out whether you are allocating objects during a particular animation, start the animation on the device, then click the “Start Allocations” button, wait a few frames, and finally click the “Get Allocations” button before the animation ends (you may need to set the Animator duration scale higher than the default to have enough time to do this successfully). Any regular allocations during animation frames should be investigated. See the article Debugging Memory for more information.

Traceview

Traceview, run from either ddms or Android Studio, is a method profiler than can be run in either trace mode (which traces every method call) or sample mode (which samples at specific time intervals). Trace mode is a good way to find out the entire code path that your application took during the traced interval, along with a rough idea of the relative time that the various methods took. However, the process of instrumentation is relatively expensive, so this view can give an inflated impression of how long simple method calls took. Sample mode avoids most of that overhead since it is not measuring every call, but it will miss details of exact code flow since it only samples at specific intervals. Also, it’s important to note that sample mode intervals will not always be evenly spaced (because the runtime can only sample at GC safe points), it cannot sample in inlined methods, and it may sample JNI methods proportionally more than Java methods.

Hierarchyviewer

Hierarchyviewer, run either as a standalone tool or from Android Studio, shows the entire view hierarchy of the selected application, and allows you to see the property values for any view. This tool is a great way to see how complex your hierarchy is. Are you keeping around too many views that are not visible much of the time? Do you have a deep container hierarchy with single-purpose layouts that could be combined to avoid this complexity? Using this tool is a good way to diagnose these problems.

MAT (Memory Analysis Tool)

Sometimes you suspect there may be a leak in your activity, as its memory footprint grows without bound. There may even be a serious leak where really large objects (such as Activities) are being leaked, perhaps across configuration changes. MAT is great for chasing these problems.

First, take a heap dump using the tool in ddms or Android Studio. This will capture the state of your object hierarchy at that time. Then you can convert this data to a version usable by MAT by running the hprof-conv command-line tool (run with ‘hprof-conv -z’ to exclude non-app heaps). Finally, you can load the data into the MAT tool (a standalone tool or a plugin for Eclipse) to visualize the memory graph, allowing you to see what objects are resident in memory and why.

See the tutorial on MAT Memory Management for Android Apps from Google I/O 2011, as well as the external Debugging Memory article for more information.

Memory Monitor

Memory Monitor is a new tool inside Android Studio for visually tracking the heap usage of the selected process over time.

meminfo

Running ‘adb shell dumpsys meminfo’ will output various statistics about the system overall or a specific process. See the external Debugging Memory article for more information.

On-device tools

There are several “tools” or modes that can be enabled on the device to give you information about your application and the overall system as its running, directly on the screen. Most of these are accessible from the Developer Options settings in the Settings app.

StrictMode

Strict mode, enabled via the “Strict mode enabled” developer option, will flash the border of the screen red when there is some strict mode violation, such as doing too much work on the UI thread. Information about the StrictMode violation will be output into the log.

Profile GPU rendering

This tool, enabled via the “Profile GPU rendering” developer option, displays information about how long it takes to render each frame and how much time was spent in the four main phases of rendering: creating the DisplayList (processing of drawing commands), syncing the rendering content to the RenderThread (mostly involving Bitmap texture uploads), issuing the DisplayList (native processing of rendering commands into OpenGL commands and parameters and uploading them to the GPU), and swapping the buffers (which encompasses both the time to return a buffer and the time spent waiting for pending GPU commands to finish processing).

Debug GPU overdraw

This tool, enabled via the “Debug GPU overdraw” developer option, shows, for all pixels on the screen, how many times the pixels were drawn for that frame, which gives you an idea of how much overhead your application is creating for the GPU by rendering some areas too many times (due, usually, to views being obscured by other opaque views).

Some amount of overdraw is expected. For example, text will overdraw the background beneath it, and shadows or other translucent items will overdraw whatever is behind them. But large opaque areas that experience overdraw should be investigated.

Animator duration scale

This tool, enabled via the “Animator duration scale” developer option, slows down or speeds up animation durations. This is useful when debugging animations, so that you can see things that you would otherwise miss with the default, short durations. Note that there are two other similar duration scale settings; the other scales control different kinds of window and system animations. The “animator” scale specifically controls the animations inside of applications that use Animator objects.

Screenrecord

This tool, executed via the adb shell command (e.g., ‘adb shell screenrecord /sdcard/myscreenrecord.mp4’) is used to record frames on the device and store the resulting mpeg video of those frames. Ctrl-C to stop, then run ‘adb pull’ to retrieve the file onto the host computer. This utility is invaluable for debugging animations and other interactive situations that are difficult to analyze in real time.

Show hardware layer updates

This tool, enabled via the “Show hardware layer updates” developer option, flashes green on the screen whenever a layer is updated. Hardware layers can be a useful way to get better performance during animations of views that are not changing during the animation. But if changes occur on that layered view, or in the child hierarchy of that view, while it is layered, this can cause a significant performance penalty. Enabling this developer tool allows you to see whether unexpected layer updates are occurring in your app.

Fin
(The End)
(Last Chapter. Done. No more. Finished.)