androidtrace分析

㈠ Android ANR trace 报告怎么看

后缀名是什么是.txt吗？Log分析你还可以去data/anr的目录下把trace.txt这个文件拷贝出来，在该文件中会写了产生anr的函数堆栈可以帮助分析

㈡ 如何分析android bugreport

一、ChkBugReport介绍
ChkBugReport是一个开源工具，它可以把你得到的bugreprot解析成适合阅读的html文件。导出的html文件包含了根据bugreport数据得出的图表和分析结论。

它的源码中用到了以下开源类库： jQuery ，jsTree jquery plugin ， tablednd jQuery plugin ， tablesorter jQuery plugin ，js-hotkeys， jquery-cookie 。学习输出报告文档型html可以参考源码。

目前ChkBugReport可以从bugreport数据中抽取出如下信息：
1、Stacktraces ChkBugReport可以从bugreport中解析出输出bugreport的最后时刻、导致ANR时刻甚至更多时刻的堆栈信息。在例子中你可以看到进程的优先级和策略都已标示出来，堆栈中耗时的部分颜色是黑红，一些违反Strict Mode的部分（比如主线程中使用数据库）颜色标记为亮红。如果这个线程死锁，在报告的Errors将会出现。
2、Logs 这部分是对system、main和kernel日志的分析，在这里你可以看到每个进程内存使用图、那个程序产生的log最多、Activity的启动耗时、数据库操作耗时统计、对象被锁定时间、AIDL调用时间、Activity和Service的生命周期及其在内存中使用频率等等，详见
3、Packages ChkBugReport解析bugreport中存储的packages.xml并展示一系列的packages、user ids和 permissions。参见
4、Processes 操作app过程中产生的系统事件日志、内存使用信息等等，参见
5、Battery statistics 电池使用统计信息，参见
6、CPU Frequency statistics CPU频率统计信息，参见
7、Raw data 被分割成小段的原始数据

同时ChkBugReport也可以检测到（潜在的）错误，这些错误在输出的报告Errors部分中可以找到。你也可以在输出报告的stacktrace中找到死锁或一些违反Strict Mode的行为。

二、ChkBugReport使用

使用很简单：1 java -jar $HOME/Downloads/chkbugreport.jar $HOME/tmp/bugreport.txt

你也可以把chkbugreport.jar加到path下，然后这样使用1 chkbugreport thebugreport.txt

该工具将根据你的bugreport数据输出一个分析结果目录bugreport_out。

你可以使用如下命令取得bugreport：1 adb shell bugreport > bugreport.txt

当然你可以使用ChkBugReport分析bugreport的部分数据比如/data/anr/traces.txt1 chkbugreport -sl:the_system_log.txt -sa:traces.txt mmy

这将输出分析结果到mmy_out。
你甚至可以使用ChkBugReport分析traceview生成的数据1 chkbugreport -t something.prof

Prof数据生成方法可以参考以下方法：
1、可以使用eclipse插件traceview生成
2、也可以按如下步骤：
a.用adb shell ps列出所有进程并找出你想要trace的进程的PID
b.执行adb shell am profile PID start /data/profile.dat，开始分析
c.操作你的app
d.执行adb shell am profile PID stop ，停止分析
e.导出数据并清除临时文件：adb pull /data/profile.dat adb shell rm /data/profile.dat
f.使用ChkBugReport进行分析 chkbugreport -t profile.dat

㈢ 请教大牛怎么分析ANR文件

对于Android ANR而言，ANR发生时mp的trace.log 非常关键，ANR应用的各个线程trace代表ANR发生那一瞬间各个线程的运行状态，类似一个快照；如果你的应用因为主线程阻塞而发生ANR，通过主线程trace就可以很容易定位到阻塞点；

如果要有效通过trace分析ANR，首先第一点需要通过main.log确认是主线程阻塞或发生死循环导致的ANR，才能确认主线程的trace有参考价值，因为trace仅是某一瞬间的动作，如果主线程5秒阻塞，那这5秒内主线程的状态都是一样的，所以可以通过trace确认阻塞点；

以一下堆栈为例：
"main"位置字段代表线程名，Android各个应用主线程都叫做"main"，关键以sysTid=9816反映的这个数字区分是哪一个应用的主线程；
sysTid=表示系统中的线程号；
tid=表示本进程中线程排号；
Native位置字段表示线程状态，线程的状态通常有Blocked，Waiting，Native，Runnable,SuSpend等等。通常Blocked,Waiting两个状态表示明显阻塞，而Native，SuSpend可能是阻塞，需要具体问题具体分析，Runnable表示线程正常运行，没有阻塞；

以下堆栈，反映ThreadedRenderer.nFence没有响应ThreadedRenderer.fence调用，然后ThreadedRenderer.fence又没有响应ViewRootImpl.performDraw，所以真正阻塞点应该是ThreadedRenderer.nFence这个位置的执行的方法；ANR问题涵盖的内容非常多，需要多积累经验，才能比较舒畅的分析这类问题；
"main" prio=5 tid=1 Native
| group="main" sCount=1 dsCount=0 obj=0x74637280 self=0xa9985400
| sysTid=9816 nice=0 cgrp=default sched=0/0 handle=0xac61b534
| state=S schedstat=( 0 0 0 ) utm=150 stm=135 core=2 HZ=100
| stack=0xbe7fd000-0xbe7ff000 stackSize=8MB
| held mutexes=
native: #00 pc 000173e4 /system/lib/libc.so (syscall+28)
native: #01 pc 000b6a3d /system/lib/libart.so (__6ThreadE+92)
native: #02 pc 003f101b /system/lib/libart.so (_ZN3artL12GoToRunnableEPNS_6ThreadE+230)
native: #03 pc 003f0f0b /system/lib/libart.so (_ZN3art12JniMethodEndEjPNS_6ThreadE+8)
native: #04 pc 00e7a58f /data/dalvik-cache/arm/system@[email protected] (Java_android_view_ThreadedRenderer_nFence__J+90)
at android.view.ThreadedRenderer.nFence(Native method)
at android.view.ThreadedRenderer.fence(ThreadedRenderer.java:859)
at android.view.ViewRootImpl.performDraw(ViewRootImpl.java:2651)
at android.view.ViewRootImpl.performTraversals(ViewRootImpl.java:2228)
at android.view.ViewRootImpl.doTraversal(ViewRootImpl.java:1248)
at android.view.ViewRootImpl$TraversalRunnable.run(ViewRootImpl.java:6330)
at android.view.Choreographer$CallbackRecord.run(Choreographer.java:871)
at android.view.Choreographer.doCallbacks(Choreographer.java:683)
at android.view.Choreographer.doFrame(Choreographer.java:619)
at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:857)
at android.os.Handler.handleCallback(Handler.java:751)
at android.os.Handler.dispatchMessage(Handler.java:95)
at android.os.Looper.loop(Looper.java:154)
at android.app.ActivityThread.main(ActivityThread.java:6141)
at java.lang.reflect.Method.invoke!(Native method)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:865)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:755)

㈣ 如何分析解决androidanr

2：耗时的工作（比如数据库操作，I/O，连接网络或者别的有可能阻碍UI线程的操作）把它放入单独的线程处理
3：尽量用Handler来处理UIthread和别的thread之间的交互

如何调查并解决ANR
1：首先分析log
2: 从trace.txt文件查看调用stack.
3: 看代码
4：仔细查看ANR的成因（iowait?block?memoryleak?）

分析ANR
先看个LOG:
04-01 13:12:11.572 I/InputDispatcher( 220): Application is not responding:Window{2b263310com.android.email/com.android.email.activity.SplitScreenActivitypaused=false}. 5009.8ms since event, 5009.5ms since waitstarted
04-0113:12:11.572 I/WindowManager( 220): Input event dispatching timedout sending tocom.android.email/com.android.email.activity.SplitScreenActivity
04-01 13:12:14.123 I/Process( 220): Sending signal. PID: 21404 SIG: 3---发生ANR的时间和生成trace.txt的时间
04-01 13:12:14.123 I/dalvikvm(21404):threadid=4: reacting to signal 3
……
04-0113:12:15.872 E/ActivityManager( 220): ANR in com.android.email(com.android.email/.activity.SplitScreenActivity)
04-0113:12:15.872 E/ActivityManager( 220): Reason:keyDispatchingTimedOut
04-0113:12:15.872 E/ActivityManager( 220): Load: 8.68 / 8.37 / 8.53
04-0113:12:15.872 E/ActivityManager( 220): CPUusage from 4361ms to 699ms ago ----CPU在ANR发生前的使用情况

04-0113:12:15.872 E/ActivityManager( 220): 5.5%21404/com.android.email: 1.3% user + 4.1% kernel / faults: 10 minor
04-0113:12:15.872 E/ActivityManager( 220): 4.3%220/system_server: 2.7% user + 1.5% kernel / faults: 11 minor 2 major
04-0113:12:15.872 E/ActivityManager( 220): 0.9%52/spi_qsd.0: 0% user + 0.9% kernel
04-0113:12:15.872 E/ActivityManager( 220): 0.5%65/irq/170-cyttsp-: 0% user + 0.5% kernel
04-0113:12:15.872 E/ActivityManager( 220): 0.5%296/com.android.systemui: 0.5% user + 0% kernel
04-0113:12:15.872 E/ActivityManager( 220): 100%TOTAL: 4.8% user + 7.6% kernel + 87% iowait
04-0113:12:15.872 E/ActivityManager( 220): CPUusage from 3697ms to 4223ms later:-- ANR后CPU的使用量
04-0113:12:15.872 E/ActivityManager( 220): 25%21404/com.android.email: 25% user + 0% kernel / faults: 191 minor
04-0113:12:15.872 E/ActivityManager( 220): 16% 21603/__eas(par.hakan: 16% user + 0% kernel
04-0113:12:15.872 E/ActivityManager( 220): 7.2% 21406/GC: 7.2% user + 0% kernel
04-0113:12:15.872 E/ActivityManager( 220): 1.8% 21409/Compiler: 1.8% user + 0% kernel
04-0113:12:15.872 E/ActivityManager( 220): 5.5%220/system_server: 0% user + 5.5% kernel / faults: 1 minor
04-0113:12:15.872 E/ActivityManager( 220): 5.5% 263/InputDispatcher: 0% user + 5.5% kernel
04-0113:12:15.872 E/ActivityManager( 220): 32%TOTAL: 28% user + 3.7% kernel

从LOG可以看出ANR的类型，CPU的使用情况，如果CPU使用量接近100%，说明当前设备很忙，有可能是CPU饥饿导致了ANR
如果CPU使用量很少，说明主线程被BLOCK了
如果IOwait很高，说明ANR有可能是主线程在进行I/O操作造成的
除了看LOG，解决ANR还得需要trace.txt文件，
如何获取呢？可以用如下命令获取
$chmod 777 /data/anr
$rm /data/anr/traces.txt
$ps
$kill -3 PID
adbpull data/anr/traces.txt ./mytraces.txt
从trace.txt文件，看到最多的是如下的信息：
-----pid 21404 at 2011-04-01 13:12:14 -----
Cmdline: com.android.email

DALVIK THREADS:
(mutexes: tll=0tsl=0 tscl=0 ghl=0 hwl=0 hwll=0)
"main" prio=5 tid=1NATIVE
| group="main" sCount=1 dsCount=0obj=0x2aad2248 self=0xcf70
| sysTid=21404 nice=0 sched=0/0cgrp=[fopen-error:2] handle=1876218976
atandroid.os.MessageQueue.nativePollOnce(Native Method)
atandroid.os.MessageQueue.next(MessageQueue.java:119)
atandroid.os.Looper.loop(Looper.java:110)
at android.app.ActivityThread.main(ActivityThread.java:3688)
at java.lang.reflect.Method.invokeNative(Native Method)
atjava.lang.reflect.Method.invoke(Method.java:507)
atcom.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:866)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:624)
at dalvik.system.NativeStart.main(Native Method)
说明主线程在等待下条消息进入消息队列

㈤ android traceview在哪

1.假定采用Debug.startMethodTracing和Debug.stopMethodTracing方式录制了trace文件。如本经验中的abc.trace文件

2.启动cmd。进入到trace文件所在的目录。
执行traceview trace文件。如图，traceview E:\\abc.trace

3.在traceviwe工具中，上面的Panel是timeline Panel，如图的例子：

4.在traceviwe工具中，下面的panel是性能分析的panel，如图的例子：

5.还可以使用dmtracemp工具生成性能图

㈥ 求教，如何抓取Android trace log

Android开发中,所的有输出都在logcat中 包含System.out输出和printStackTrace()输出都在Logcat中,Android开发,建议使用android提供的Log工具类来打印信息。
找到Logcat视图的方式:
Eclipse 点击 Window
Show View会出来一个对话框
点击Ok按钮时，会在控制台窗口出现LogCat视图
android.util.Log常用的方法有以下5个：Log.v() Log.d() Log.i() Log.w() 以及 Log.e() 。根据首字母对应VERBOSE，DEBUG,INFO, WARN，ERROR。
1、Log.v 的调试颜色为黑色的，任何消息都会输出，这里的v代表verbose啰嗦的意思，平时使用就是Log.v("","");
2、Log.d的输出颜色是蓝色的，仅输出debug调试的意思，但他会输出上层的信息，过滤起来可以通过DDMS的Logcat标签来选择.
3、Log.i的输出为绿色，一般提示性的消息information，它不会输出Log.v和Log.d的信息，但会显示i、w和e的信息
4、Log.w的意思为橙色，可以看作为warning警告，一般需要我们注意优化Android代码，同时选择它后还会输出Log.e的信息。
5、Log.e为红色，可以想到error错误，这里仅显示红色的错误信息，这些错误就需要认真的分析，查看栈的信息了。

㈦ android trace文件怎么看

后缀名是什么 是.txt吗？
Log分析 你还可以去data/anr的目录下把trace.txt这个文件拷贝出来，在该文件中会写了产生anr的函数堆栈可以帮助分析

㈧ Android开发中，有哪些好方法可以检测内存泄露和性能

下面是回答的内容

内存泄露，是Android开发者最头疼的事。可能一处小小的内存泄露，都可能是毁于千里之堤的蚁穴。怎么才能检测内存泄露呢？网上教程非常多，不过很多都是使用Eclipse检测的, 其实1.3版本以后的Android Studio 检测内存非常方便, 如果结合上MAT工具,LeakCanary插件,一切就变得so easy了。

熟悉Android Studio界面工欲善其事,必先利其器。

我们接下来先来熟悉下Android Studio的界面

结果

非独占时间:某函数占用的CPU时间,包含内部调用其它函数的CPU时间。
独占时间:某函数占用CPU时间,但不含内部调用其它函数所占用的CPU时间。

我们如何判断可能有问题的方法？

通过方法的调用次数和独占时间来查看，通常判断方法是：

如果方法调用次数不多，但每次调用却需要花费很长的时间的函数，可能会有问题。

如果自身占用时间不长，但调用却非常频繁的函数也可能会有问题。

综述

上面给大家介绍了若干使用Android Studio检查程序性能的工具,工具永远是辅助,不要因为工具耽误太长时间。如果有问题，欢迎大家纠正。

㈨ android 怎么解析tra文件

对于从事Android开发的人来说，遇到ANR(Application Not Responding)是比较常见的问题。一般情况下，如果有ANR发生，系统都会在/data/anr/目录下生成trace文件，通过分析trace文件，可以定位产生ANR的原因。产生ANR的原因有很多，比如CPU使用过高、事件没有得到及时的响应、死锁等，下面将通过一次因为死锁导致的ANR问题，来说明如何通过trace文件分析ANR问题。
对应的部分trace文件内容如下：
"PowerManagerService" prio=5 tid=24 MONITOR
| group="main" sCount=1 dsCount=0 obj=0x41dd0eb0 self=0x5241b218
| sysTid=567 nice=0 sched=0/0 cgrp=apps handle=1380038664
| state=S schedstat=( 6682116007 11324451214 33313 ) utm=450 stm=219 core=1
at com.android.server.am.ActivityManagerService.broadcastIntent(ActivityManagerService.java:~13045)
- waiting to lock <0x41a874a0> (a com.android.server.am.ActivityManagerService) held by tid=12 (android.server.ServerThread)
at android.app.ContextImpl.sendBroadcast(ContextImpl.java:1144)
at com.android.server.power.PowerManagerService$DisplayBlankerImpl.unblankAllDisplays(PowerManagerService.java:3442)
at com.android.server.power.DisplayPowerState$PhotonicMolator$1.run(DisplayPowerState.java:456)
at android.os.Handler.handleCallback(Handler.java:800)
at android.os.Handler.dispatchMessage(Handler.java:100)
at android.os.Looper.loop(Looper.java:194)
at android.os.HandlerThread.run(HandlerThread.java:60)
"Binder_B" prio=5 tid=85 MONITOR
| group="main" sCount=1 dsCount=0 obj=0x42744770 self=0x58329e88
| sysTid=3700 nice=-20 sched=0/0 cgrp=apps handle=1471424616
| state=S schedstat=( 1663727513 2044643318 6806 ) utm=132 stm=34 core=1
at com.android.server.power.PowerManagerService$DisplayBlankerImpl.toString(PowerManagerService.java:~3449)
- waiting to lock <0x41a7e420> (a com.android.server.power.PowerManagerService$DisplayBlankerImpl) held by tid=24 (PowerManagerService)
at java.lang.StringBuilder.append(StringBuilder.java:202)
at com.android.server.power.PowerManagerService.mp(PowerManagerService.java:3052)
at android.os.Binder.mp(Binder.java:264)
at android.os.Binder.onTransact(Binder.java:236)
at android.os.IPowerManager$Stub.onTransact(IPowerManager.java:373)
at android.os.Binder.execTransact(Binder.java:351)
at dalvik.system.NativeStart.run(Native Method)
"android.server.ServerThread" prio=5 tid=12 MONITOR
| group="main" sCount=1 dsCount=0 obj=0x41a76178 self=0x507837a8
| sysTid=545 nice=-2 sched=0/0 cgrp=apps handle=1349936616
| state=S schedstat=( 15368096286 21707846934 69485 ) utm=1226 stm=310 core=0
at com.android.server.power.PowerManagerService.isScreenOnInternal(PowerManagerService.java:~2529)
- waiting to lock <0x41a7e2e8> (a java.lang.Object) held by tid=85 (Binder_B)
at com.android.server.power.PowerManagerService.isScreenOn(PowerManagerService.java:2522)
at com.android.server.wm.WindowManagerService.(WindowManagerService.java:7749)
at com.android.server.wm.WindowManagerService.setEventDispatching(WindowManagerService.java:7628)
at com.android.server.am.ActivityManagerService.updateEventDispatchingLocked(ActivityManagerService.java:8083)
at com.android.server.am.ActivityManagerService.wakingUp(ActivityManagerService.java:8077)
at com.android.server.power.Notifier.sendWakeUpBroadcast(Notifier.java:474)
at com.android.server.power.Notifier.sendNextBroadcast(Notifier.java:455)
at com.android.server.power.Notifier.access$700(Notifier.java:62)
at com.android.server.power.Notifier$NotifierHandler.handleMessage(Notifier.java:600)
at android.os.Handler.dispatchMessage(Handler.java:107)
at android.os.Looper.loop(Looper.java:194)
at com.android.server.ServerThread.run(SystemServer.java:1328)
从trace文件看，是因为TID为24的线程等待一个TID为12的线程持有的锁，TID为12的线程等待一个TID为85的线程持有的锁，而TID为85的线程确等待一个TID为24的线程持有的锁，导致了循环等待的现象，对应的trace文件的语句如下：
TID 24：- waiting to lock <0x41a874a0> (a com.android.server.am.ActivityManagerService) held by tid=12 (android.server.ServerThread)
TID 12： - waiting to lock <0x41a7e2e8> (a java.lang.Object) held by tid=85 (Binder_B)
TID 85：- waiting to lock <0x41a7e420> (a com.android.server.power.PowerManagerService$DisplayBlankerImpl) held by tid=24 (PowerManagerService)
既然是死锁，那么先看各线程都有那些锁。
先看TID=24的线程的栈顶，ActivityManagerService的broadcastIntent函数代码如下:
public final int broadcastIntent(IApplicationThread caller,
Intent intent, String resolvedType, IIntentReceiver resultTo,
int resultCode, String resultData, Bundle map,
String requiredPermission, boolean serialized, boolean sticky, int userId) {
enforceNotIsolatedCaller("broadcastIntent");
synchronized(this) {
intent = verifyBroadcastLocked(intent);
final ProcessRecord callerApp = getRecordForAppLocked(caller);
final int callingPid = Binder.getCallingPid();
final int callingUid = Binder.getCallingUid();
final long origId = Binder.clearCallingIdentity();
int res = broadcastIntentLocked(callerApp,
callerApp != null ? callerApp.info.packageName : null,
intent, resolvedType, resultTo,
resultCode, resultData, map, requiredPermission, serialized, sticky,
callingPid, callingUid, userId);
Binder.restoreCallingIdentity(origId);
return res;
}
可以看到TID=24需要ActivityManagerService这个锁。再看TID=12线程的栈顶，PowerManagerService的isScreenOnInternal函数代码如下：

private boolean isScreenOnInternal() {
synchronized (mLock) {
return !mSystemReady
|| mDisplayPowerRequest.screenState != DisplayPowerRequest.SCREEN_STATE_OFF;
}
}
可以看到需要PowerManagerService的mlock这个锁。最后看TID=85线程的栈顶，同样在PowerManagerService里面，内部类DisplayBlankerImpl的toString函数：

public String toString() {
synchronized (this) {
return "blanked=" + mBlanked;
}
}
这是在内部类DisplayBlankerImpl里面实现的，所以需要DisplayBlankerImpl这个锁。
对应的表格如下：
表一 各线程等待的锁情况
从表一来看，没有出现死锁现象，似乎并不是我们所想的那样。难道不是死锁？开始有点小怀疑自己了，难道别的原因导致的。也许只看调用堆栈的顶端可能不行，栈顶只能看出各线程需要的锁，不能仅看自己要什么吧！一味索取可不好！人不是这样做的！看一下整个的堆栈调用流程，看看自己拥有了那些锁。
跟踪TID=24线程的堆栈，在PowerManagerService内部类DisplayBlankerImpl的unblankAllDisplays函数中持有锁：
public void unblankAllDisplays() {
synchronized (this) {
nativeSetAutoSuspend(false);
nativeSetInteractive(true);
mDisplayManagerService.();
mBlanked = false;
///M: add for tvout and hdmi
mTvOut.tvoutPowerEnable(true);
mHDMI.hdmiPowerEnable(true);
///@}
if (DEBUG) {
Slog.d(TAG_P, "unblankAllDisplays out ...");
}
if (mBootCompleted) {
Intent intent = new Intent(ACTION_LOCK_SCREEN_SHOW);
mContext.sendBroadcast(intent);
}
}
}
最后发送广播的代码，是我们自己添加的。根据unblankAllDisplays函数和broadcastIntent函数，可以看到TID=24的线程此时持有了DisplayBlankerImpl锁(unblankAllDisplays)，等待ActivityManagerService锁(broadcastIntent)释放。
同样，跟踪TID=12线程的堆栈，在ActivityManagerService的wake_up函数中持有锁：
public void wakingUp() {
if (checkCallingPermission(android.Manifest.permission.DEVICE_POWER)
!= PackageManager.PERMISSION_GRANTED) {
throw new SecurityException("Requires permission "
+ android.Manifest.permission.DEVICE_POWER);
}
synchronized(this) {
Slog.i(TAG, "wakingUp");
mWentToSleep = false;
updateEventDispatchingLocked();
comeOutOfSleepIfNeededLocked();
}
}
根据wakingUp函数和isScreenOnInternal函数，可以看到TID=12的线程持有ActivityManagerService锁(wakingUp)，等待PowerManagerService.mLock锁(isScreenOnInternal)。到这，似乎看到了希望，迷雾要拨开了，有点小自信是死锁导致的，但还不能最终下结论。
一鼓作气，跟踪TID=85线程的堆栈，在PowerManagerService的mp有持有锁的操作：
protected void mp(FileDescriptor fd, PrintWriter pw, String[] args) {
....
synchronized (mLock) {
...
}
根据toString函数和mp函数，可以看到TID=85线程此时持有PowerManagerService.mLock锁(mp)，需要DisplayBlankerImpl(toString)。

㈩ android怎么使用rpmbuild

对于从事Android开发的人来说，遇到ANR(Application Not Responding)是比较常见的问题。一般情况下，如果有ANR发生，系统都会在/data/anr/目录下生成trace文件，通过分析trace文件，可以定位产生ANR的原因。产生ANR的原因有很多，比如CPU使用过高、事件没有得到及时的响应、死锁等，下面将通过一次因为死锁导致的ANR问题，来说明如何通过trace文件分析ANR问题。
对应的部分trace文件内容如下：
"PowerManagerService" prio=5 tid=24 MONITOR
| group="main" sCount=1 dsCount=0 obj=0x41dd0eb0 self=0x5241b218
| sysTid=567 nice=0 sched=0/0 cgrp=apps handle=1380038664
| state=S schedstat=( 6682116007 11324451214 33313 ) utm=450 stm=219 core=1
at com.android.server.am.ActivityManagerService.broadcastIntent(ActivityManagerService.java:~13045)
- waiting to lock <0x41a874a0> (a com.android.server.am.ActivityManagerService) held by tid=12 (android.server.ServerThread)