DDMS provides Threads, VMHeap, Allocation Tracker, Emulator control and other tabs to monitor application performance. The following sections describe how to use DDMS and the various tabs and panes that are part of the DDMS GUI
Examining thread information
The Threads tab in DDMS shows you the currently running threads for a selected process.
- Select the process that you want to examine the threads for.
- Click the Update Threads button.
- In the Threads tab, you can view the thread information for the selected process.
- “main” (see name column) thread is your applications process
- Click on refresh button to view class and method information.
- If Native = false, method/class is from application, else method/class is from Android OS.
Heap and non-Heap memory
The device JVM memory consists of the following segments:
- Heap Memory, which is the storage for Java objects
- Non-Heap Memory, which is used by Java to store loaded classes and other meta-data
- JVM code itself, JVM internal structures, loaded profiler agent code and data, etc.
Viewing heap usage for a process
DDMS allows you to view how much heap memory process is using. This information is useful in tracking heap usage at a certain point of time during the execution of your application.
The Dalvik virtual machine can produce a complete dump of the contents of the virtual heap. This is very useful for debugging memory usage and looking for memory leaks.
To view heap usage for a process:
- Select the process that you want to see the heap information for.
- Click the Show Heap Updates button to enable heap information for the process.
- In the VM Heap tab, click Cause GC to invoke garbage collection, which enables the collection of heap data. When the operation completes, you will see a group of object types and the memory that has been allocated for each type. You can click Cause GC again to refresh the data.
- Click on an object type in the list to see a bar graph that shows the number of objects allocated for a particular memory size in bytes.
There are many types of objects that are identified by DVM which are categorized as below.
- Class Objects are instances of Class, e.g. what you'd get from java.lang.String.class or myObject.getClass().
- The arrays are binned by size. For example, 2-byte arrays could be short[] or char[]. 4-byte arrays include float[], int[], and all Object[].
- A non-Java Object is a piece of memory that isn't actually accessible from code written in Java. Essentially it's a blob of stuff that got stuck on the virtual heap but has no meaning to interpreted code. Shouldn't be much of that.
- Data Objects are objects that don't fall into one of the special categories. ArrayList, HashMap, whatever.
Allocation Tracker
In a performance-sensitive code path, such as the layout or drawing method of a view or the logic code of a game, any allocation comes at a price. After too many allocations, the garbage collector will kick in and stop your application to let it free some memory. Most of the time, garbage collections happen fast enough for you not to notice. However, if a collection happens while you are scrolling through a list of items or while you are trying to defeat a foe in a game, you may suddenly see a drop in performance/responsiveness of the application. It's not unusual for a garbage collection to take 100 to 200 ms. For comparison, a smooth animation needs to draw each frame in 16 to 33 ms. If the animation is suddenly interrupted for 10 frames, you can be certain that your users will notice.
Most of the time, garbage collection occurs because of tons of small, short-lived objects and some garbage collectors, like generational garbage collectors, can optimize the collection of these objects so that the application does not get interrupted too often. The Android garbage collector is unfortunately not able to perform such optimizations and the creation of short-lived objects in performance critical code paths is thus very costly for your application.
To help you avoid frequent garbage collections, the Android SDK ships with a very useful tool called allocation tracker. This tool is part of DDMS, which you must have already used for debugging purposes. To start using the allocation tracker, you must first launch the standalone version of DDMS, which can be found in the tools/ directory of the SDK. The version of DDMS included in the Eclipse plugin does not offer you ability to use the allocation tracker yet. Once DDMS is running, simply select your application process and then click the Allocation Tracker tab. In the new view, click Start Tracking and then use your application to make it execute the code paths you want to analyze. When you are ready, click Get Allocations. A list of allocated objects will be shown in the first table. By clicking on a line you can see, in the second table, the stack trace that led to the allocation. Not only you will know what type of object was allocated, but also in which thread, in which class, in which file and at which line.
File System
DDMS provides a File Explorer tab that allows you to view, copy, and delete files on the device. You can view this tab by going to the ‘Device’ menu and clicking on the ‘File Explorer’ tab. Using this feature the user can examine files that are created by your application or if you want to transfer files to and from the emulator/device to the local machine.
To work with an emulator or device's file system:
- In the File explorer tab, select the file that you want ot view.
- To copy a file from the device/emulator, locate the file in the File Explorer and click the Pull file button.
- To copy a file to the device/emulator, click the Push file button on the File Explorer tab.
