Google I/O 2009: Debugging. With Nunchucks.

google_io_091Next on Android at Google I/O 2009, we have Justin Mattson and “Debugging Arts of the Ninja Masters”. Despite the title, this is not about using the Eclipse debugger, but rather other tools that can help developers diagnose problems, such as poor performance.

He started off with logcat, which gives you access to the logs emitted by Android. Of course, you can use logcat to view Java stack traces, which will come up whenever your application crashes or when you use the Log class to dump a stack trace to the log. But logcat also gives you access to lots of system messages which can help in finding out what is going wrong. For example, Justin illustrated that when your device switches between Internet providers (e.g., from WiFi to 3G), all your sockets reset, which may cause “unexpected” networking errors.

The logcat utility (standalone in the SDK, in DDMS, or in the Eclipse DDMS perspective) helps you deal with the firehose of messages via filters, such as for a specific severity level or for a specific tag. When logging your own messages, he recommends using tags that can help you with filtering for those messages, such as choosing a tag pattern that is both informative and something that can be easily filtered via a regex. However, at the same time, since logging is also done on production devices, be sure not to log information that might be privacy-sensitive, from passwords to bank account numbers.

He then moved onto traceview, which is the Android equivalent for the tracing tools you may have used in other platforms. It will record every method call and duration, offering you a timeline or tree view to see who is taking up all the processing time, so you know where to spend time on optimization. Tracing can be enabled or disabled from code (via the Debug class) or via the command line. The results are logged to a file you specify, which traceview can interpret and display in developer-friendly terms.

Justin then moved into a discussion of hierarchyviewer, discussed previously in this blog. You can use this tool to inspect a running activity to see what widgets and containers are in use, in a hierarchical fashion. This can be helpful to figure out why some widgets seem like they are not showing up (e.g., they were not inflated, they are beyond the edge of the screen). It can also help you see if you have too deep of a hierarchy that might cause problems in terms of running out of stack space.

Next, he covered a series of war stories. For example, he helped out with the Google Finance app, trying to figure out why it started up so slowly. Using traceview, he discovered that it was the result of formatting a simple date and time, inexplicably tying up the main UI thread. By moving it to a background low-priority thread, he chopped a couple of seconds off the app’s startup time. In another case, he used hierarchyviewer to help convert a Google Scoreboard UI from using a bunch of nested LinearLayouts into a RelativeLayout, eliminating a few layers in the view stack and saving a bunch of time when inflating the layouts.

He also briefly covered the Allocation Tracker component of DDMS. With this tool, you can start and stop tracking allocations, then take a look at what was allocated where and how frequently. You can use this to identify places where you may be redundantly allocating memory, causing excessive garbage collection and resulting slowdowns of the device.