Question


I'm trying to find a cause of freezes on UI thread in my app in certain conditions.
I have run the app through DDMS profiling. But in the bottom tree-table view I see all the methods called on all threads, whereas I would like to focus only on main thread.

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

A sub-question: is there some good Android profiler out there?

Was it helpful?

Solution

The UI doesn't provide a way to do this -- you just have to skim the timeline and click on busy-looking sections.

There's a rough approach that may do what you want.

The SDK includes a tool called dmtracedump that can be used to generate reports from the .trace file. When you grab the trace with DDMS, note the file's location (mine was /tmp/ddms4176182990461128308.trace). On Linux, you would run:

dmtracedump -o <filename> > trace.txt

This will give you a file that looks like:

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 thread ID that corresponds to the table at the top (so thread ID 4 is the JDWP thread, which handles DDMS traffic). This is followed by an action code: ent for method entry, xit for method exit, or unr for stack unroll due to an exception. After that comes the per-thread CPU time stamp (i.e. the cumulative CPU time used by this thread), then the method name and signature.

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

grep "^ 1 " trace.txt

Now it's a simple matter of parsing the output. :-)

It would be easier to handle if you could strip the data for the uninteresting threads out of the trace file, then just open the new file with the traceview tool (included with the SDK). If you open a .trace file you can see that it's a chunk of text followed by a chunk of binary data. You would need to write a program that passes the text through, then parses the binary part and drops anything with a thread ID other than the one you're interested in. The format is simple -- a collection of fixed-size records -- described in a comment near the top of the profiling code.

(I don't know if somebody has written this already.)

OTHER TIPS

To view your code activity (hotspots with call-stacks) on certain thread (UI for example) I propose to use Intel VTune from System Studio. You could collect Basic hotspots profile on your Android device, open Bottom-up tab in and select Grouping : Thread / Function / Callstack. After that you see per-thread hotspot-profile of your application. (see details in attached screenshot) enter image description here

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

The best android profiler is certainly "Eclipse Memory Analyzer". It allow you to take a snapshot of your memory and look in deep what's happening on it. Please take a look on the link below to learn more about it.

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

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top