在5.0以上的设备无响应(ANR),这日志是什么意思?

东山少爷猪头 2015-12-02 11:24:49
最近接手一项目,之前很多人写过,所以代码比较乱.然后发现有一个页面,在其他机器上没问题,但在5.0的设备上进入该页面就非常容易出无响应(ANR),而且就算点"等待"也等不到能动的时候,真是卡死了.开始以为是多个数据库开着没关闭的原因,但导出了trace.txt和看了CPU的使用情况后发现,我感觉未必关数据库的事.但我自己又不太会看这两个log.麻烦有大神给点方向吗?
该页面SwitchActivity就只是一些控件的初始化,有根据需求的逻辑改变下状态,一些onClick的事件,有数据库的查询和发起一次网络请求(但没到这请求一般就卡死了).

CPU log
-----------------------------------------------------------------------

12-01 16:41:38.894: I/Process(553): Sending signal. PID: 1314 SIG: 3

12-01 16:41:38.895: I/art(1314): Thread[5,tid=1323,WaitingInMainSignalCatcherLoop,Thread*=0xb8ae2520,peer=0x12c000a0,"Signal Catcher"]: reacting to signal 3

12-01 16:41:39.106: E/ActivityManager(553): ANR in com.test.cs (com.test.cs/.login.module.SwitchActivity)

12-01 16:41:39.106: E/ActivityManager(553): PID: 25036

12-01 16:41:39.106: E/ActivityManager(553): 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.  Wait queue length: 11.  Wait queue head age: 5567.5ms.)

12-01 16:41:39.106: E/ActivityManager(553): Load: 0.63 / 0.96 / 0.94

12-01 16:41:39.106: E/ActivityManager(553): CPU usage from 5401ms to 0ms ago:

12-01 16:41:39.106: E/ActivityManager(553):   4% 553/system_server: 2.9% user + 1.1% kernel / faults: 89 minor

12-01 16:41:39.106: E/ActivityManager(553):   2.5% 710/com.android.systemui: 1.4% user + 1.1% kernel / faults: 3 minor

12-01 16:41:39.106: E/ActivityManager(553):   1.4% 167/logd: 1.4% user + 0% kernel

12-01 16:41:39.106: E/ActivityManager(553):   1.2% 195/mpdecision: 0% user + 1.2% kernel

12-01 16:41:39.106: E/ActivityManager(553):   0.7% 172/surfaceflinger: 0.3% user + 0.3% kernel

12-01 16:41:39.106: E/ActivityManager(553):   0.7% 198/sensors.qcom: 0.3% user + 0.3% kernel

12-01 16:41:39.106: E/ActivityManager(553):   0.5% 2072/com.internet.speed.meter.lite: 0.5% user + 0% kernel / faults: 18 minor

12-01 16:41:39.106: E/ActivityManager(553):   0.5% 11255/kworker/0:1: 0% user + 0.5% kernel

12-01 16:41:39.106: E/ActivityManager(553):   0.3% 3298/com.baofeng.mj: 0.3% user + 0% kernel / faults: 47 minor

12-01 16:41:39.106: E/ActivityManager(553):   0.3% 20557/kworker/u:4: 0% user + 0.3% kernel

12-01 16:41:39.106: E/ActivityManager(553):   0% 2/kthreadd: 0% user + 0% kernel

12-01 16:41:39.106: E/ActivityManager(553):   0.1% 141/ueventd: 0.1% user + 0% kernel

12-01 16:41:39.106: E/ActivityManager(553):   0.1% 168/healthd: 0% user + 0.1% kernel

12-01 16:41:39.106: E/ActivityManager(553):   0.1% 170/servicemanager: 0% user + 0.1% kernel

12-01 16:41:39.106: E/ActivityManager(553):   0% 171/vold: 0% user + 0% kernel

12-01 16:41:39.106: E/ActivityManager(553):   0% 194/thermald: 0% user + 0% kernel / faults: 11 minor

12-01 16:41:39.106: E/ActivityManager(553):   0.1% 202/adbd: 0% user + 0.1% kernel / faults: 36 minor

12-01 16:41:39.106: E/ActivityManager(553):   0.1% 642/MC_Thread: 0% user + 0.1% kernel

12-01 16:41:39.106: E/ActivityManager(553):   0.1% 644/RX_Thread: 0% user + 0.1% kernel

12-01 16:41:39.106: E/ActivityManager(553):   0.1% 662/wpa_supplicant: 0% user + 0.1% kernel

12-01 16:41:39.106: E/ActivityManager(553):   0.1% 971/com.android.phone: 0% user + 0.1% kernel

12-01 16:41:39.106: E/ActivityManager(553):   0.1% 1161/com.google.process.gapps: 0% user + 0.1% kernel / faults: 1 minor

12-01 16:41:39.106: E/ActivityManager(553):   0.1% 1314/com.google.android.gms.persistent: 0.1% user + 0% kernel / faults: 2 minor

12-01 16:41:39.106: E/ActivityManager(553):   0.1% 3653/com.android.vending: 0% user + 0.1% kernel / faults: 1 minor

12-01 16:41:39.106: E/ActivityManager(553):   0% 4371/com.wandoujia.phoenix2.usbproxy: 0% user + 0% kernel / faults: 3 minor

12-01 16:41:39.106: E/ActivityManager(553):   0.1% 19864/kworker/0:0: 0% user + 0.1% kernel

12-01 16:41:39.106: E/ActivityManager(553):   0.1% 20559/kworker/u:6: 0% user + 0.1% kernel

12-01 16:41:39.106: E/ActivityManager(553):   0.1% 23779/com.thinksky.itools.markets: 0% user + 0.1% kernel

12-01 16:41:39.106: E/ActivityManager(553):   0% 23964/sogou.mobile.explorer.hotwords: 0% user + 0% kernel

12-01 16:41:39.106: E/ActivityManager(553): 0% TOTAL: 0% user + 0% kernel + 0% iowait

12-01 16:41:39.106: E/ActivityManager(553): CPU usage from 3259ms to 3790ms later:

12-01 16:41:39.106: E/ActivityManager(553):   12% 553/system_server: 8.9% user + 3.5% kernel / faults: 2 minor

12-01 16:41:39.106: E/ActivityManager(553):     10% 576/ActivityManager: 5.3% user + 5.3% kernel

12-01 16:41:39.106: E/ActivityManager(553):     1.7% 575/android.bg: 1.7% user + 0% kernel

12-01 16:41:39.106: E/ActivityManager(553):     1.7% 579/android.ui: 1.7% user + 0% kernel

12-01 16:41:39.106: E/ActivityManager(553):   1.7% 195/mpdecision: 0% user + 1.7% kernel

12-01 16:41:39.106: E/ActivityManager(553):     3.5% 232/mpdecision: 0% user + 3.5% kernel

12-01 16:41:39.106: E/ActivityManager(553):   1% 643/TX_Thread: 0% user + 1% kernel

12-01 16:41:39.106: E/ActivityManager(553):   1% 1314/com.google.android.gms.persistent: 0% user + 1% kernel

12-01 16:41:39.106: E/ActivityManager(553):   1.2% 20557/kworker/u:4: 0% user + 1.2% kernel

12-01 16:41:39.106: E/ActivityManager(553): 0% TOTAL: 0% user + 0% kernel + 0% iowait


trace在二楼
...全文
4541 20 打赏 收藏 转发到动态 举报
写回复
用AI写文章
20 条回复
切换为时间正序
请发表友善的回复…
发表回复
东山少爷猪头 2016-05-27
  • 打赏
  • 举报
 回复
引用 19 楼 adg164 的回复:
楼主解决了吗
解决了,后来找了研究院的人来看,原来是数据库的名字有中文字符所以导致一打开这个数据库,就卡死了.5.0之前可能没那么严,就开得了. 真是被前人坑死....
做而论道 2016-05-20
  • 打赏
  • 举报
 回复
楼主解决了吗
david_frank 2016-02-04
  • 打赏
  • 举报
 回复
12-01 16:41:39.106: E/ActivityManager(553): ANR in com.test.cs (com.test.cs/.login.module.SwitchActivity) 12-01 16:41:39.106: E/ActivityManager(553): PID: 25036 跟你 traces.txt 的 pid 对应不上 ----- pid 553 at 2015-12-01 16:41:35 ----- Cmd line: system_server 你贴的信息不对.
东山少爷猪头 2015-12-15
  • 打赏
  • 举报
 回复
引用 16 楼 l417584711 的回复:
所有函数都加了log 还找不到耗时的函数？
找不到.耗时倒没发现哪个特别耗时,就是一到了getWritableDatabase()就卡死了.
aSysBang 2015-12-14
  • 打赏
  • 举报
 回复
所有函数都加了log 还找不到耗时的函数？
东山少爷猪头 2015-12-07
  • 打赏
  • 举报
 回复
自己顶上去,大家帮忙看看啊
东山少爷猪头 2015-12-03
  • 打赏
  • 举报
 回复
引用 11 楼 a87b01c14 的回复:
[quote=引用 10 楼 tempersitu 的回复:] [quote=引用 9 楼 a87b01c14 的回复:] [quote=引用 8 楼 tempersitu 的回复:] [quote=引用 7 楼 a87b01c14 的回复:] [quote=引用 6 楼 tempersitu 的回复:] 现在又发现另外一种情况,跟我之前怀疑的有关,进入这页面没有ANR了.点了按钮开始进行下载,下载前先查询数据库.就会卡死,每次都是卡死在SQLiteOpenHelper.getWritableDatabase()这里(换getReadableDatabase())也一样.而且可以确定的是,之前已经有其他数据库有开着,没关闭.一旦进行这里的查询,就会切换数据库并getWritableDatabase().请问这个ANR的原因是跟数据库的同步锁有关吗?
我估计 for (int i = 0; i < length; i++) { length 过长？这个值大概是多少 数据量大，循环查询数据库有点耗时 这部分动作可以放到线程里面去做 用AsyncTask[/quote] 应该不是,只是到了getWritableDatabase()这步而已,都还没到执行查询那步,就已经卡死了.因为点getWritableDatabase()进去的话,看到有个synchronized,所以怀疑是同步锁的原因.但不确定.也看不到trace.....[/quote] 嗯，那有可能，数据库操作要封装在业务方法里面，操作完毕之后要调用db.close();[/quote] 是的,正常来说肯定要close DB的.就是发现之前的代码居然都没关闭数据库,之前写的人都是所以就切换或者新开一个数据库,开着的数据库都基本没关闭.所以最初的怀疑,也是怀疑到这个数据库没关闭的问题上.但我写了个demo,一样多开几个数据库不关闭,然后同时对他们增删改查,除了会因为数据量大,出现ANR之外(而且点等待之后能等到操作完,可以继续操作,但手上的项目不会,是真卡死),没其他问题.加上这trace和CPU显示的数据,都不太像是数据库的问题.所以搞得我很头疼.[/quote] 如果你把这句getWritableDatabase() 屏蔽掉，程序OK 的话，那基本上就跟这个数据库有关系了， 还是重头检查数据库操作，方法中打开的就在方法中close掉，Activity oncreate()中打开的，在onDestroy()中肯定是要关闭的[/quote] 试过把那句getWritableDatabase()屏蔽掉,遇到后面还有getWritableDatabase()的地方,一样会卡死,把这函数里面会用到的getWritableDatabase()屏蔽掉,就没事了.那可以肯定跟数据库是有关系了. 只是问题具体出在什么地方,根源是什么,怎么解决,没个明确的答案.而且自己写的那个demo,多开不关闭也没事,也不知道这个跟这项目用了ActiveRecord有关.
sanxiaochengyu 2015-12-03
  • 打赏
  • 举报
 回复
引用 10 楼 tempersitu 的回复:
[quote=引用 9 楼 a87b01c14 的回复:] [quote=引用 8 楼 tempersitu 的回复:] [quote=引用 7 楼 a87b01c14 的回复:] [quote=引用 6 楼 tempersitu 的回复:] 现在又发现另外一种情况,跟我之前怀疑的有关,进入这页面没有ANR了.点了按钮开始进行下载,下载前先查询数据库.就会卡死,每次都是卡死在SQLiteOpenHelper.getWritableDatabase()这里(换getReadableDatabase())也一样.而且可以确定的是,之前已经有其他数据库有开着,没关闭.一旦进行这里的查询,就会切换数据库并getWritableDatabase().请问这个ANR的原因是跟数据库的同步锁有关吗?
我估计 for (int i = 0; i < length; i++) { length 过长？这个值大概是多少 数据量大，循环查询数据库有点耗时 这部分动作可以放到线程里面去做 用AsyncTask[/quote] 应该不是,只是到了getWritableDatabase()这步而已,都还没到执行查询那步,就已经卡死了.因为点getWritableDatabase()进去的话,看到有个synchronized,所以怀疑是同步锁的原因.但不确定.也看不到trace.....[/quote] 嗯，那有可能，数据库操作要封装在业务方法里面，操作完毕之后要调用db.close();[/quote] 是的,正常来说肯定要close DB的.就是发现之前的代码居然都没关闭数据库,之前写的人都是所以就切换或者新开一个数据库,开着的数据库都基本没关闭.所以最初的怀疑,也是怀疑到这个数据库没关闭的问题上.但我写了个demo,一样多开几个数据库不关闭,然后同时对他们增删改查,除了会因为数据量大,出现ANR之外(而且点等待之后能等到操作完,可以继续操作,但手上的项目不会,是真卡死),没其他问题.加上这trace和CPU显示的数据,都不太像是数据库的问题.所以搞得我很头疼.[/quote] 如果你把这句getWritableDatabase() 屏蔽掉，程序OK 的话，那基本上就跟这个数据库有关系了， 还是重头检查数据库操作，方法中打开的就在方法中close掉，Activity oncreate()中打开的，在onDestroy()中肯定是要关闭的
东山少爷猪头 2015-12-03
  • 打赏
  • 举报
 回复
引用 9 楼 a87b01c14 的回复:
[quote=引用 8 楼 tempersitu 的回复:] [quote=引用 7 楼 a87b01c14 的回复:] [quote=引用 6 楼 tempersitu 的回复:] 现在又发现另外一种情况,跟我之前怀疑的有关,进入这页面没有ANR了.点了按钮开始进行下载,下载前先查询数据库.就会卡死,每次都是卡死在SQLiteOpenHelper.getWritableDatabase()这里(换getReadableDatabase())也一样.而且可以确定的是,之前已经有其他数据库有开着,没关闭.一旦进行这里的查询,就会切换数据库并getWritableDatabase().请问这个ANR的原因是跟数据库的同步锁有关吗?
我估计 for (int i = 0; i < length; i++) { length 过长？这个值大概是多少 数据量大，循环查询数据库有点耗时 这部分动作可以放到线程里面去做 用AsyncTask[/quote] 应该不是,只是到了getWritableDatabase()这步而已,都还没到执行查询那步,就已经卡死了.因为点getWritableDatabase()进去的话,看到有个synchronized,所以怀疑是同步锁的原因.但不确定.也看不到trace.....[/quote] 嗯，那有可能，数据库操作要封装在业务方法里面，操作完毕之后要调用db.close();[/quote] 是的,正常来说肯定要close DB的.就是发现之前的代码居然都没关闭数据库,之前写的人都是所以就切换或者新开一个数据库,开着的数据库都基本没关闭.所以最初的怀疑,也是怀疑到这个数据库没关闭的问题上.但我写了个demo,一样多开几个数据库不关闭,然后同时对他们增删改查,除了会因为数据量大,出现ANR之外(而且点等待之后能等到操作完,可以继续操作,但手上的项目不会,是真卡死),没其他问题.加上这trace和CPU显示的数据,都不太像是数据库的问题.所以搞得我很头疼.
sanxiaochengyu 2015-12-03
  • 打赏
  • 举报
 回复
引用 8 楼 tempersitu 的回复:
[quote=引用 7 楼 a87b01c14 的回复:] [quote=引用 6 楼 tempersitu 的回复:] 现在又发现另外一种情况,跟我之前怀疑的有关,进入这页面没有ANR了.点了按钮开始进行下载,下载前先查询数据库.就会卡死,每次都是卡死在SQLiteOpenHelper.getWritableDatabase()这里(换getReadableDatabase())也一样.而且可以确定的是,之前已经有其他数据库有开着,没关闭.一旦进行这里的查询,就会切换数据库并getWritableDatabase().请问这个ANR的原因是跟数据库的同步锁有关吗?
我估计 for (int i = 0; i < length; i++) { length 过长？这个值大概是多少 数据量大，循环查询数据库有点耗时 这部分动作可以放到线程里面去做 用AsyncTask[/quote] 应该不是,只是到了getWritableDatabase()这步而已,都还没到执行查询那步,就已经卡死了.因为点getWritableDatabase()进去的话,看到有个synchronized,所以怀疑是同步锁的原因.但不确定.也看不到trace.....[/quote] 嗯，那有可能，数据库操作要封装在业务方法里面，操作完毕之后要调用db.close();
东山少爷猪头 2015-12-03
  • 打赏
  • 举报
 回复
引用 7 楼 a87b01c14 的回复:
[quote=引用 6 楼 tempersitu 的回复:] 现在又发现另外一种情况,跟我之前怀疑的有关,进入这页面没有ANR了.点了按钮开始进行下载,下载前先查询数据库.就会卡死,每次都是卡死在SQLiteOpenHelper.getWritableDatabase()这里(换getReadableDatabase())也一样.而且可以确定的是,之前已经有其他数据库有开着,没关闭.一旦进行这里的查询,就会切换数据库并getWritableDatabase().请问这个ANR的原因是跟数据库的同步锁有关吗?
我估计 for (int i = 0; i < length; i++) { length 过长？这个值大概是多少 数据量大，循环查询数据库有点耗时 这部分动作可以放到线程里面去做 用AsyncTask[/quote] 应该不是,只是到了getWritableDatabase()这步而已,都还没到执行查询那步,就已经卡死了.因为点getWritableDatabase()进去的话,看到有个synchronized,所以怀疑是同步锁的原因.但不确定.也看不到trace.....
sanxiaochengyu 2015-12-03
  • 打赏
  • 举报
 回复
引用 6 楼 tempersitu 的回复:
现在又发现另外一种情况,跟我之前怀疑的有关,进入这页面没有ANR了.点了按钮开始进行下载,下载前先查询数据库.就会卡死,每次都是卡死在SQLiteOpenHelper.getWritableDatabase()这里(换getReadableDatabase())也一样.而且可以确定的是,之前已经有其他数据库有开着,没关闭.一旦进行这里的查询,就会切换数据库并getWritableDatabase().请问这个ANR的原因是跟数据库的同步锁有关吗?
我估计 for (int i = 0; i < length; i++) { length 过长？这个值大概是多少 数据量大，循环查询数据库有点耗时 这部分动作可以放到线程里面去做 用AsyncTask
东山少爷猪头 2015-12-03
  • 打赏
  • 举报
 回复
引用 13 楼 RrMoon 的回复:
ANR 建议你把耗时操作放到单独的线程中进行，不要在UI主线程中做过多耗时操作（i/o 网络相关）
嗯,代码不是我写的,那是前人留下的.而且我看过,都还没做其他操作,只是打开数据库,getWritableDatabase()的时候就卡死了,都没到其他操作呢. 现在我就想看看有人能看懂这trace和CPU log没.确定引起的原因,到时要避免或者要改的话,也可以跟公司提出.我自己重新写的话,肯定会把耗时的操作放子线程里做,数据库也会关闭好的.
R小菜鸟R 2015-12-03
  • 打赏
  • 举报
 回复
ANR 建议你把耗时操作放到单独的线程中进行，不要在UI主线程中做过多耗时操作（i/o 网络相关）
东山少爷猪头 2015-12-02
  • 打赏
  • 举报
 回复
trace.txt ------------------------------------------------------------------------------------------------------------------------------ 
----- pid 553 at 2015-12-01 16:41:35 -----
Cmd line: system_server
ABI: arm
Build type: optimized
Zygote loaded classes=3593 post zygote classes=2610
Intern table: 39316 strong; 13347 weak
JNI: CheckJNI is off; globals=3122 (plus 62 weak)
Libraries: /system/lib/libandroid.so /system/lib/libandroid_servers.so /system/lib/libaudioeffect_jni.so /system/lib/libcompiler_rt.so /system/lib/libjavacrypto.so /system/lib/libjnigraphics.so /system/lib/libmedia_jni.so /system/lib/librs_jni.so /system/lib/libsoundpool.so /system/lib/libwebviewchromium_loader.so /system/lib/libwifi-service.so libjavacore.so (12)
Heap: 25% free, 30MB/40MB; 403267 objects
Dumping cumulative Gc timings
Start Dumping histograms for 4 iterations for concurrent mark sweep
ProcessMarkStack:	Sum: 387.238ms 99% C.I. 0.012ms-112.711ms Avg: 32.269ms Max: 112.711ms
SweepMallocSpace:	Sum: 109.290ms 99% C.I. 0.091ms-47.296ms Avg: 13.661ms Max: 47.337ms
MarkRootsCheckpoint:	Sum: 54.873ms 99% C.I. 0.824ms-22.066ms Avg: 6.859ms Max: 22.066ms
AllocSpaceClearCards:	Sum: 26.242ms 99% C.I. 0.030ms-6.952ms Avg: 1.640ms Max: 6.989ms
MarkConcurrentRoots:	Sum: 17.242ms 99% C.I. 0.001ms-8.788ms Avg: 2.155ms Max: 8.911ms
UpdateAndMarkImageModUnionTable:	Sum: 17.211ms 99% C.I. 1.800ms-10.444ms Avg: 4.302ms Max: 10.468ms
MarkNonThreadRoots:	Sum: 13.822ms 99% C.I. 0.366ms-4.578ms Avg: 1.727ms Max: 4.578ms
ScanGrayAllocSpaceObjects:	Sum: 13.334ms 99% C.I. 0.000ms-3.662ms Avg: 1.666ms Max: 3.662ms
MarkAllocStackAsLive:	Sum: 10.497ms 99% C.I. 0.488ms-3.967ms Avg: 2.624ms Max: 3.967ms
SweepSystemWeaks:	Sum: 4.577ms 99% C.I. 0.946ms-1.492ms Avg: 1.144ms Max: 1.495ms
(Paused)ScanGrayObjects:	Sum: 4.088ms 99% C.I. 0.824ms-1.220ms Avg: 1.022ms Max: 1.220ms
ReMarkRoots:	Sum: 3.966ms 99% C.I. 793us-1434us Avg: 991.500us Max: 1434us
EnqueueFinalizerReferences:	Sum: 2.562ms 99% C.I. 518us-763us Avg: 640.500us Max: 763us
SweepLargeObjects:	Sum: 2.073ms 99% C.I. 335us-610us Avg: 518.250us Max: 610us
ImageModUnionClearCards:	Sum: 1.919ms 99% C.I. 122us-488us Avg: 239.875us Max: 488us
SweepZygoteSpace:	Sum: 1.708ms 99% C.I. 427us-427us Avg: 427us Max: 427us
ZygoteModUnionClearCards:	Sum: 1.371ms 99% C.I. 91us-366us Avg: 171.375us Max: 366us
FinishPhase:	Sum: 1.249ms 99% C.I. 274us-335us Avg: 312.250us Max: 335us
ProcessReferences:	Sum: 548us 99% C.I. 122us-152us Avg: 137us Max: 152us
RevokeAllThreadLocalAllocationStacks:	Sum: 364us 99% C.I. 91us-91us Avg: 91us Max: 91us
ScanGrayImageSpaceObjects:	Sum: 334us 99% C.I. 61us-91us Avg: 83.500us Max: 91us
ProcessCards:	Sum: 122us 99% C.I. 0.333us-61us Avg: 15.250us Max: 61us
MarkingPhase:	Sum: 90us 99% C.I. 0.250us-30us Avg: 22.500us Max: 30us
PreCleanCards:	Sum: 60us 99% C.I. 0.250us-30us Avg: 15us Max: 30us
(Paused)PausePhase:	Sum: 30us 99% C.I. 0.250us-30us Avg: 7.500us Max: 30us
(Paused)ProcessMarkStack:	Sum: 0 99% C.I. 0ns-0ns Avg: 0ns Max: 0ns
Done Dumping histograms 
concurrent mark sweep paused:	Sum: 8.695ms 99% C.I. 1.800ms-2.807ms Avg: 2.173ms Max: 2.807ms
concurrent mark sweep total time: 675.354ms mean time: 168.838ms
concurrent mark sweep freed: 588390 objects with total size 28MB
concurrent mark sweep throughput: 871689/s / 42MB/s
Start Dumping histograms for 1 iterations for sticky concurrent mark sweep
MarkRootsCheckpoint:	Sum: 45.657ms 99% C.I. 0.854ms-44.803ms Avg: 22.828ms Max: 44.803ms
ScanGrayAllocSpaceObjects:	Sum: 40.041ms 99% C.I. 0.030ms-37.672ms Avg: 10.010ms Max: 38.333ms
FreeList:	Sum: 25.231ms 99% C.I. 30us-374.125us Avg: 121.888us Max: 396us
SweepArray:	Sum: 8.026ms 99% C.I. 8.026ms-8.026ms Avg: 8.026ms Max: 8.026ms
AllocSpaceClearCards:	Sum: 7.629ms 99% C.I. 0.001ms-5.816ms Avg: 1.907ms Max: 5.890ms
ProcessMarkStack:	Sum: 2.319ms 99% C.I. 0.500us-1770us Avg: 579.750us Max: 1770us
MarkingPhase:	Sum: 2.044ms 99% C.I. 2.044ms-2.044ms Avg: 2.044ms Max: 2.044ms
MarkConcurrentRoots:	Sum: 1.830ms 99% C.I. 30us-1800us Avg: 915us Max: 1800us
SweepSystemWeaks:	Sum: 946us 99% C.I. 946us-946us Avg: 946us Max: 946us
(Paused)ScanGrayObjects:	Sum: 732us 99% C.I. 732us-732us Avg: 732us Max: 732us
ReMarkRoots:	Sum: 610us 99% C.I. 610us-610us Avg: 610us Max: 610us
MarkNonThreadRoots:	Sum: 609us 99% C.I. 274us-335us Avg: 304.500us Max: 335us
EnqueueFinalizerReferences:	Sum: 549us 99% C.I. 549us-549us Avg: 549us Max: 549us
ImageModUnionClearCards:	Sum: 518us 99% C.I. 91us-427us Avg: 259us Max: 427us
ZygoteModUnionClearCards:	Sum: 426us 99% C.I. 91us-335us Avg: 213us Max: 335us
ResetStack:	Sum: 274us 99% C.I. 274us-274us Avg: 274us Max: 274us
ScanGrayImageSpaceObjects:	Sum: 243us 99% C.I. 91us-152us Avg: 121.500us Max: 152us
ScanGrayZygoteSpaceObjects:	Sum: 152us 99% C.I. 61us-91us Avg: 76us Max: 91us
RevokeAllThreadLocalAllocationStacks:	Sum: 122us 99% C.I. 122us-122us Avg: 122us Max: 122us
FinishPhase:	Sum: 30us 99% C.I. 30us-30us Avg: 30us Max: 30us
(Paused)PausePhase:	Sum: 0 99% C.I. 0ns-0ns Avg: 0ns Max: 0ns
Done Dumping histograms 
sticky concurrent mark sweep paused:	Sum: 1.526ms 99% C.I. 1.526ms-1.526ms Avg: 1.526ms Max: 1.526ms
sticky concurrent mark sweep total time: 138.048ms mean time: 138.048ms
sticky concurrent mark sweep freed: 210282 objects with total size 13MB
sticky concurrent mark sweep throughput: 1.52378e+06/s / 98MB/s
Total time spent in GC: 813.402ms
Mean GC size throughput: 2GB/s
Mean GC object throughput: 6.58355e+07 objects/s
Total number of allocations 53953993
Total bytes allocated 2GB
Free memory 10MB
Free memory until GC 10MB
Free memory until OOME 481MB
Total memory 40MB
Max memory 512MB
Total mutator paused time: 10.221ms
Total time waiting for GC to complete: 1.433s

DALVIK THREADS (83):
"main" prio=5 tid=1 Native
  | group="main" sCount=1 dsCount=0 obj=0x73c85000 self=0xb892a408
  | sysTid=553 nice=-2 cgrp=default sched=0/0 handle=0xb6f48bec
  | state=S schedstat=( 0 0 0 ) utm=19829 stm=7036 core=0 HZ=100
  | stack=0xbe456000-0xbe458000 stackSize=8MB
  | held mutexes=
  kernel: (couldn't read /proc/self/task/553/stack)
  native: #00 pc 0003cfec  /system/lib/libc.so (__epoll_pwait+20)
  native: #01 pc 00014339  /system/lib/libc.so (epoll_pwait+26)
  native: #02 pc 00014347  /system/lib/libc.so (epoll_wait+6)
  native: #03 pc 000123c3  /system/lib/libutils.so (android::Looper::pollInner(int)+98)
  native: #04 pc 000125ed  /system/lib/libutils.so (android::Looper::pollOnce(int, int*, int*, void**)+92)
  native: #05 pc 00081709  /system/lib/libandroid_runtime.so (android::NativeMessageQueue::pollOnce(_JNIEnv*, int)+22)
  native: #06 pc 000b3863  /data/dalvik-cache/arm/system@framework@boot.oat (Java_android_os_MessageQueue_nativePollOnce__JI+102)
  at android.os.MessageQueue.nativePollOnce(Native method)
  at android.os.MessageQueue.next(MessageQueue.java:143)
  at android.os.Looper.loop(Looper.java:122)
  at com.android.server.SystemServer.run(SystemServer.java:269)
  at com.android.server.SystemServer.main(SystemServer.java:170)
  at java.lang.reflect.Method.invoke!(Native method)
  at java.lang.reflect.Method.invoke(Method.java:372)
  at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:903)
  at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:698)
............
trace剩下的应该不是很重要,我就没贴了. 根据日志说的,是信息队列在等待,有非按键的时间超时了是吗? 还有一点奇怪的就是为什么5.0以上才有这问题的?
东山少爷猪头 2015-12-02
  • 打赏
  • 举报
 回复
现在又发现另外一种情况,跟我之前怀疑的有关,进入这页面没有ANR了.点了按钮开始进行下载,下载前先查询数据库.就会卡死,每次都是卡死在SQLiteOpenHelper.getWritableDatabase()这里(换getReadableDatabase())也一样.而且可以确定的是,之前已经有其他数据库有开着,没关闭.一旦进行这里的查询,就会切换数据库并getWritableDatabase().请问这个ANR的原因是跟数据库的同步锁有关吗?
东山少爷猪头 2015-12-02
  • 打赏
  • 举报
 回复
引用 3 楼 l417584711 的回复:
在你自己的每个函数的开始和结束加上log 看看哪个函数执行时间长
好的,我试试
东山少爷猪头 2015-12-02
  • 打赏
  • 举报
 回复
引用 2 楼 a87b01c14 的回复:
方便的话，贴下代码，方便研究
主要就是在onCreateView()的方法里面,基本都是些findViewById, 和setOnClick的事件. 除此之外就两个地方,一个调用数据库的 
public static ArrayList<HashMap<String, String>> getDbFileName2(String userName, Context context){
        
        ArrayList<HashMap<String, String>> list =  new ArrayList<HashMap<String, String>>();
        HashMap<String, String> map = null;
        File file = new File("/data/data/com.test.cs/databases/");
        File[] files = file.listFiles();
        int size = 0;
        if(files != null ){
            
            int length = files.length;
            String data = null;
            String serverTime = null;
            
            Arrays.sort(files, new CreateDbUtil.CompratorByLastModified()); // 按文件创建时间排序
            
            for (int i = 0; i < length; i++) {
                File f = files[i];
                String fileName = f.getName();
                String [] str = fileName.split("-");
                size = str.length;
                if (size > 2 && !str[size - 1].equals("journal")) {
                    if(str[1].equals("DB") && str[0].equals(userName)){
                        data = f.getName().substring(10, f.getName().length() - 3);
                        serverTime = DbService.getCount2(fileName, context);  //这里是从数据库查询结果
                        map = new HashMap<String, String>();
                        map.put("data", flightData);
                        map.put("serverTime", serverTime);
                        list.add(map);
                    }
                }
            }
        }
        return list; 
    }
还有另外一个是网络请求的 

DownloadTask downloadTask = new DownloadTask() {
			@Override
			protected void onPostExecute(String result) {
			    
				if (result != null) {
				    ArrayList<CarTask> carTasks = new ArrayList<CarTask>();

					try {
						result = result.replaceAll(",\\s*(?=])|,\\s*(?=\\})", "");
						JsonParser jsonParser = new JsonParser();
						JsonArray jsonObject = jsonParser.parse(result).getAsJsonArray();
						for (int i = 0; i < jsonObject.size(); i++) {
							//解析json
						}

						// 发送航班任务信息
						car_Tasks = carTasks;
						Message msg = new Message();
						msg.what = 20;
						handler1.sendMessage(msg);
					} catch (Exception e) {
//					    change_task_flight_tip.setVisibility(View.VISIBLE);
						Message msg = new Message();
						msg.what = ERROR;
						handler1.sendMessage(msg);
						e.printStackTrace();
					}
				}
			}
		};

		downloadTask.execute(pUser);
aSysBang 2015-12-02
  • 打赏
  • 举报
 回复
在你自己的每个函数的开始和结束加上log 看看哪个函数执行时间长
sanxiaochengyu 2015-12-02
  • 打赏
  • 举报
 回复
方便的话，贴下代码，方便研究
应用与系统稳定性第一篇---ANR问题分析的一般套路
image.png ANR（App Not Responding）基本上99%的App都有，即使是系统，也有system_anr，我相信虽然ANR问题这样的普遍，还是有很多人对ANR问题即熟悉又陌生的，ANR中log信息怎么看？发生的场景有哪些？广播会发生ANR吗？我的App啥事都没有干怎么发生了ANR了等等一些问题，今天通过三个案例总结一下ANR问题分析的一般套路，以做备忘。 一、ANR初步了解 1、发生原因 一句话总结：没有在规定的时间内，干完要干的事情，就会发生ANR。 2、AN...
面试：ANR相关---原因、源码、监控
需要注意的是，所有应用发生 ANR 的时候都会进行回调，因此需要做一些过滤与判断，如包名、进程号等。最大的困难是兼容性问题，这个方案受限于 Android 系统的 SELinux 机制，5.0 以后基本已经使低权限应用无法监听到 trace 文件了，但是可以在开发内测阶段通过 root 手机修改 app 对应的 te 文件提权进行监控。在 Message 消息分发前后，大部分的性能卡顿问题都是在这里发生的，监控这两个逻辑之间的时间差就可以得到当前主线程的卡顿状态，如果超时则获取 trace 信息并上报。
手把手教你高效监控ANR
手把手教你高效监控ANR
ANR问题分析
ANR概念 ANR(Application Not Responding) 应用程序无响应。如果应用程序在UI线程被阻塞太长时间，就会出现ANR，通常出现ANR，系统会弹出一个提示提示框，让用户知道，该程序正在被阻塞，是否继续等待还是关闭。 出现ANR必须解决 ANR类型 为什么出现ANR 1:主线程频繁进行耗时的IO操作：如数据库读写 2:多线程操作的死锁，主线程被block；held by 3:主线程被Binder 对端block； 4:System Server中WatchDog出现ANR； 5:se
安卓app测试之Monkey日志分析
转:原文：https://blog.csdn.net/a136332462/article/details/76066909 一、一般测试结果分析-搜索关键字： 1、无响应问题可以在日志中搜索 “ANR” 。 2、崩溃问题搜索 “CRASH” 。 3、内存泄露问题搜索"GC"（需进一步分析）。 4、异常问题搜索 “Exception”（如果出现空指针， NullPointerExcep...
Android

80,351

社区成员

91,288

社区内容

发帖
与我相关
我的任务
社区描述
移动平台 Android
androidandroid-studioandroidx 技术论坛（原bbs）
社区管理员
  • Android
  • yechaoa
  • 失落夏天
加入社区
  • 近7日
  • 近30日
  • 至今

加载中

查看更多榜单
社区公告
暂无公告

试试用AI创作助手写篇文章吧

+ 用AI写文章