ANR Log分析

ANR原因:

● 5s内无法响应用户输入事件(例如键盘输入, 触摸屏幕等).
● BroadcastReceiver在10s内无法结束.

● 获取不到CPU时间片(CPU太满了);

● 主线程等待未及时出现的event,不能执行下一步;

● 处理流程过于复杂。

 

ANR类型:

Key Dispach Timeout
Input event
ALPS_ICS_MP 15s
ALPS_ICS_MP 8s
Android默认5s;

Broadcast Timeout
BroadcastReceiver 未能在10s处理完
Android默认10s;

ServiceTimeout 请求服务失败20s内

主线程处理消息队列中的消息时阻塞并且没有及时处理之后的消息,超过一定时间,就发生了anr。

 

案例分析:

等待同步锁:
"main" prio=5 tid=1 Blocked
| group="main" sCount=1 dsCount=0 obj=0x75098e48 self=0xf4fb6500
| sysTid=3394 nice=0 cgrp=default sched=0/0 handle=0xf7235b34
| state=S schedstat=( 0 0 0 ) utm=168 stm=73 core=3 HZ=100
| stack=0xff3ed000-0xff3ef000 stackSize=8MB
| held mutexes=
at com.meizu.media.gallery.data.ai.b_(SourceFile:1476)
- waiting to lock <0x054dd944> (a com.meizu.media.gallery.data.ai) held by thread 36   //再去分析这个线程,我就不贴了
at com.meizu.media.gallery.fragment.AlbumGridFragment$c$1.a(SourceFile:1536)
at com.meizu.media.gallery.data.aw.f(SourceFile:197)
- locked <0x08f06a2d> (a java.util.WeakHashMap)

 

等待进程通信事务Wait Binder transaction:  
"main" prio=5 tid=1 Native
| group="main" sCount=1 dsCount=0 obj=0x752b53a8 self=0x7f8447c400
| sysTid=32144 nice=-6 cgrp=default sched=0/0 handle=0x7f882fd2c0
| state=S schedstat=( 867701473 1907646540 1027 ) utm=51 stm=35 core=5 HZ=100
| stack=0x7fdabb7000-0x7fdabb9000 stackSize=8MB
| held mutexes=
kernel: (couldn't read /proc/self/task/32144/stack)
at android.os.BinderProxy.transactNative(Native method)
at android.os.BinderProxy.transact(Binder.java:514)

 

在UI线程(主线程)等待网络数据:
""main"" prio=5 tid=3 NATIVE     
|group=""main"" sCount=1 dsCount=0 s=Yobj=0x4001b240 self=0xbda8
| sysTid=2579 nice=0 sched=0/0cgrp=unknown handle=-1343993184
atorg.apache.harmony.luni.platform.OSNetworkSystem.receiveStreamImpl(NativeMethod)  //非本应用代码,是调用第三方http请求的代码
atorg.apache.harmony.luni.platform.OSNetworkSystem.receiveStream(OSNetworkSystem.java:478)
atorg.apache.harmony.luni.net.PlainSocketImpl.read(PlainSocketImpl.java:565)

 

CPU gc:
Process:com.anly.githubapp
...
CPU usage from 3330ms to 814ms ago:
6% 178/system_server: 3.5% user + 1.4% kernel / faults: 86 minor 20 major
4.6% 2976/com.anly.githubapp: 0.7% user + 3.7% kernel /faults: 52 minor 19 major
0.9% 252/com.android.systemui: 0.9% user + 0% kernel
...

100%TOTAL: 5.9% user + 4.1% kernel + 89% iowait
最后一句表明了:
1. 当是CPU占用100%, 满负荷了.
2. 其中绝大数是被iowait即I/O操作占用了.

 

内存GC: 多个GC字眼,Heap free都为0
Heap: 0% free, 256MB/256MB; 1899604 objects
Total time spent in GC: 12.607s
Mean GC size throughput: 3MB/s
Mean GC object throughput: 25535.1 objects/s
Total number of allocations 2221526
Total bytes allocated 297MB
Total bytes freed 40MB
Free memory 0B
Free memory until GC 0B
Free memory until OOME 3GB
Total memory 256MB
Max memory 256MB
Zygote space size 1440KB
Total mutator paused time: 1.310s
Total time waiting for GC to complete: 32.254s
Total GC count: 55
Total GC time: 12.607s
Total blocking GC count: 50
Total blocking GC time: 11.202s
Histogram of GC count per 10000 ms: 0:14,1:1,3:1,4:1
Histogram of blocking GC count per 10000 ms: 0:16,3:1

 

转载于:https://www.cnblogs.com/season-xie/p/6337922.html

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
ANR Trace分析是一种通过分析ANR错误日志(或称为ANR跟踪文件)来确定ANR错误的根本原因的方法。通过分析ANR跟踪文件,您可以了解应用程序中哪些线程阻塞了主线程,并确定导致线程阻塞的原因。 在Android设备上,您可以使用命令行工具 `adb shell dumpsys activity ANR` 来获取ANR错误日志。此命令将打印出最近的ANR错误日志,其中包含了主线程的堆栈跟踪信息、CPU使用情况、线程状态等信息。 下面是一个ANR错误日志的示例: ``` ANR in com.example.myapp PID: 1234 Reason: Input dispatching timed out (Waiting to send non-key event because the touched window has not finished processing certain input events that were delivered to it over 500.0ms ago. Waited for 1.0s.) Load: 98% CPU usage from 10000ms to 0ms ago: 60% com.example.myapp: 50% user + 9.7% kernel / faults: 250 minor 4 major 39% system_server: 14% user + 24% kernel / faults: 324 minor 3 major 0.1% com.android.systemui: 0% user + 0.1% kernel / faults: 17 minor 1 major 0% com.android.phone: 0% user + 0% kernel / faults: 11 minor 0% com.android.launcher: 0% user + 0% kernel / faults: 7 minor 0% kswapd0: 0% user + 0% kernel 0% kworker/u:1: 0% user + 0% kernel ``` 通过分析上面的ANR错误日志,您可以了解以下信息: - 应用程序包名为 com.example.myapp,进程ID为 1234。 - ANR出现的原因是输入事件分发超时,即应用程序在等待某个窗口处理输入事件时超时了。 - 应用程序的CPU负载达到了98%。 - 应用程序占用了60%的CPU时间。 - 系统服务 system_server 占用了39%的CPU时间。 - 其他进程的CPU使用率非常低。 通过分析这些信息,您可以确定ANR错误的原因,并尝试采取相应的措施来解决问题,比如将耗时操作移到后台线程中执行、优化代码、调整系统配置等。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值