Android的 - 通过DDMS分析特定线程（UI线程） [英] Android - profiling a specific thread (UI Thread) via DDMS

问题描述

我试图找到UI线程冻结在我在一定的条件下应用程序的原因。
我已经运行通过DDMS分析的应用程序。但在底部的树表视图我看到所有呼吁所有线程，而我想只专注于主线程的方法。

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.

有没有办法来筛选的DDMS方法，底部树表列表以包括选定的线程（在我的情况下，UI线程）只统计？

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?

推荐答案

用户界面不提供一种方式来做到这一点 - 你只需要脱脂的时间表，然后单击行色匆匆的部分。

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.

该SDK包含了一个名为工具 dmtracedump ，可用于生成从 .trace 文件报告。当你抓的痕迹与DDMS，请注意该文件的位置（我的是 /tmp/ddms4176182990461128308.trace ）。在Linux上，你可以运行：

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;
...

正如在输出所指出的，每行以对应于该表的顶部线程ID（因此线程ID 4是JDWP螺纹，它处理DDMS流量）。其次是一个动作code：耳鼻喉科的方法进入， XIT 的方法退出，或 UNR 堆栈解开由于异常。接着是每线程的CPU时间标记（即使用由该线程的累积CPU时间），则该方法名称和签名。

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.

如果你只是想看看在主UI线程（线程ID 1），你可以使用：

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. :-)

这将是比较容易处理，如果你能带材无趣的线程中的数据进行跟踪文件，那么只需打开与 traceview 工具新的文件（包括与SDK）。如果你打开​​一个.trace文件，你可以看到它的文本块后面的二进制数据块。您需要编写一个程序，通过传递文本，然后解析二进制的一部分，滴用一个线程ID比一个你感兴趣的格式很简单其他任何东西 - 固定大小的记录的集合 - 在注释中所描述的附近分析$ C $顶部Ç。

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.)

这篇关于Android的 - 通过DDMS分析特定线程（UI线程）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！