Android - profiling a specific thread (UI thread) through DDMS

Question

I am trying to find the cause of a hang in the user interface thread in my application under certain conditions.
I am running the application through DDMS profiling. But in the lower tree view, I see all the methods called for all threads, while I would like to focus only on the main thread.

Is there a way to filter the bottom list of table methods in DDMS to include only statistics for the selected thread (UI thread in my case)?

Subquery: is there any good Android profiler?

Answer 1

The user interface does not provide a way to do this - you just need to remove the timeline and click on the busy sections.

There is a rude approach that can do what you want.

The SDK includes a tool called dmtracedump , which can be used to create reports from a .trace file. When you take the trace with DDMS, pay attention to the location of the file (mine was /tmp/ddms4176182990461128308.trace ). On Linux, you will run:

 dmtracedump -o <filename> > trace.txt 

This will give you a file that looks like this:

 VERSION: 3 Threads (13): 1 main 2 GC 3 Signal Catcher 4 JDWP ... Trace (threadID action usecs class.method signature): 4 xit 0 ..dalvik/system/VMDebug.startMethodTracingDdms (IIZI)V 4 xit 0 .android/os/Debug.startMethodTracingDdms (IIZI)V 4 xit 0 android/ddm/DdmHandleProfiling.handleMPSS (Lorg/apache/harmony/dalvik/ddmc/Chunk;)Lorg/apache/harmony/dalvik/ddmc/Chunk; ... 

As noted in the output, each line begins with a stream identifier that corresponds to the table at the top (so stream 4 identifier is a JDWP stream that processes DDMS traffic). This is followed by an action code: ent to enter the method, xit to exit the method, or unr to expand the stack due to an exception. After that, the processor’s time stamp appears on the stream (i.e., the cumulative processor time used by this stream), then the method name and signature.

If you just want to see the main thread of the user interface (thread ID 1), you can use:

 grep "^ 1 " trace.txt 

Now this is a simple output analysis question. :-)

It would be easier to handle if you could strip data for uninteresting streams from the trace file, and then just open a new file using the traceview tool (included in the SDK). If you open the .trace file, you will see that it is a piece of text followed by a piece of binary data. You will need to write a program that passes the text through, then parses the binary part and removes something with a stream identifier different from the one you are interested in. The format is simple - a collection of records of a fixed size - described in the commentary at the top of the profiling code .

(I don't know if anyone wrote this already.)

Answer 2

To view the activity of your code (hot spots with stop calls) in a specific thread (for example, the user interface), I suggest using Intel VTune from System Studio. You can collect the profile “Key hot spots” on your Android device, open the “Down” tab and select “Grouping”: “Theme / Function / Callstack”. After that, you see a hotspot profile for each theme in your application. (see details in the attached screenshot)

Here is a tutorial on using VTune: http://software.intel.com/en-us/articles/using-intel-vtune-amplifier-on-non-rooted-android-devices

Answer 3

The best android profiler is, of course, the Eclipse Memory Analyzer. This allows you to take a picture of your memory and deeply examine what is happening on it. Please see the link below to learn more about this.

http://eclipsesource.com/blogs/2013/01/21/10-tips-for-using-the-eclipse-memory-analyzer/