ANR keyDispatchingTimedOut [英] ANR keyDispatchingTimedOut

问题描述

我遇到与应用程序冻结一些问题。它看起来像它的东西做的hardwarerenderer，也许我使用的线程数量。我很想有人来看看日志，并告诉我，如果有什么明显的指出。谢谢你。

  DALVIK主题：
（互斥：TLL = 0 TSL = 0 TSCL = 0 GHL = 0和黄= 0 hwll = 0）
主PRIO = 5 TID = 1的原生
  |组=主SCOUNT = 1 dsCount = 0的obj = 0x401f6600自我= 0x125f8
  | sysTid = 15811漂亮= 0 sched的= 0/0 CGRP =默认的手柄= -1345129368
  | schedstat =（0 0 0）UTM = 2495 STM = 1172芯= 0
  在com.google.android.gles_jni.EGLImpl.eglSwapBuffers（本机方法）
  在android.view.HardwareRenderer $ GlRenderer.draw（HardwareRenderer.java:648）
  在android.view.ViewRoot.draw（ViewRoot.java:1594）
  在android.view.ViewRoot.performTraversals（ViewRoot.java:1410）
  在android.view.ViewRoot.handleMessage（ViewRoot.java:2040）
  在android.os.Handler.dispatchMessage（Handler.java:99）
  在android.os.Looper.loop（Looper.java:132）
  在android.app.ActivityThread.main（ActivityThread.java:4123）
  在java.lang.reflect.Method.invokeNative（本机方法）
  在java.lang.reflect.Method.invoke（Method.java:491）
  在com.android.internal.os.ZygoteInit $ MethodAndArgsCaller.run（ZygoteInit.java:841）
  在com.android.internal.os.ZygoteInit.main（ZygoteInit.java:599）
  在dalvik.system.NativeStart.main（本机方法）

线程811PRIO = 5 TID = 31 VMWAIT
  |组=主SCOUNT = 1 dsCount = 0的obj = 0x412479c0自我= 0x45e478
  | sysTid = 17073漂亮= 0 sched的= 0/0 CGRP =默认的手柄= 2020736
  | schedstat =（0 0 0）UTM = 4 STM = 0核心= 1

线程810PRIO = 5 TID = 29 VMWAIT
  |组=主SCOUNT = 1 dsCount = 0的obj = 0x41296560自我= 0x4d2f​​38
  | sysTid = 17072漂亮= 0 sched的= 0/0 CGRP =默认的手柄= 10050328
  | schedstat =（0 0 0）UTM = 3 STM = 1芯= 1

线程809PRIO = 5 TID = 28 VMWAIT
  |组=主SCOUNT = 1 dsCount = 0的obj = 0x4129b490自我= 0x45e710
  | sysTid = 17071漂亮= 0 sched的= 0/0 CGRP =默认的手柄= 5146952
  | schedstat =（0 0 0）UTM = 3 STM = 0核心= 0

线程808PRIO = 5 TID = 27 VMWAIT
  |组=主SCOUNT = 1 dsCount = 0的obj = 0x412d6008自我= 0x44aa48
  | sysTid = 17070漂亮= 0 sched的= 0/0 CGRP =默认的手柄= 3737640
  | schedstat =（0 0 0）UTM = 2 STM = 0核心= 0

线程807PRIO = 5 TID = 26 VMWAIT
  |组=主SCOUNT = 1 dsCount = 0的obj = 0x41352300自我= 0x3abee0
  | sysTid = 17069漂亮= 0 sched的= 0/0 CGRP =默认的手柄= 5418280
  | schedstat =（0 0 0）UTM = 3 STM = 0核心= 1

线程806PRIO = 5 TID = 25 VMWAIT
  |组=主SCOUNT = 1 dsCount = 0的obj = 0x41352a00自我= 0x4d0a00
  | sysTid = 17068漂亮= 0 sched的= 0/0 CGRP =默认的手柄= 5327520
  | schedstat =（0 0 0）UTM = 3 STM = 0核心= 1

线程805PRIO = 5 TID = 24 VMWAIT
  |组=主SCOUNT = 1 dsCount = 0的obj = 0x41352ef0自我= 0x49bec8
  | sysTid = 17067漂亮= 0 sched的= 0/0 CGRP =默认的手柄= 6587488
  | schedstat =（0 0 0）UTM = 3 STM = 0核心= 1

线程804PRIO = 5 TID = 23 VMWAIT
  |组=主SCOUNT = 1 dsCount = 0的obj = 0x4138be18自我= 0x4e2c18
  | sysTid = 17066漂亮= 0 sched的= 0/0 CGRP =默认的手柄= 9299592
  | schedstat =（0 0 0）UTM = 3 STM = 0核心= 1

线程803PRIO = 5 TID = 22 VMWAIT
  |组=主SCOUNT = 1 dsCount = 0的obj = 0x4138e5e0自我= 0x483e58
  | sysTid = 17065漂亮= 0 sched的= 0/0 CGRP =默认的手柄= 8949624
  | schedstat =（0 0 0）UTM = 4 STM = 0核心= 0

线程802PRIO = 5 TID = 21 VMWAIT
  |组=主SCOUNT = 1 dsCount = 0的obj = 0x4151b210自我= 0x4b23d0
  | sysTid = 17064漂亮= 0 sched的= 0/0 CGRP =默认的手柄= 4798984
  | schedstat =（0 0 0）UTM = 3 STM = 0核心= 0

线程801PRIO = 5 TID = 20 VMWAIT
  |组=主SCOUNT = 1 dsCount = 0的obj = 0x4151d118自我= 0x492bd0
  | sysTid = 17063漂亮= 0 sched的= 0/0 CGRP =默认的手柄= 10231792
  | schedstat =（0 0 0）UTM = 3 STM = 0核心= 0

线程800PRIO = 5 TID = 19 VMWAIT
  |组=主SCOUNT = 1 dsCount = 0的obj = 0x416cf1f8自我= 0x482808
  | sysTid = 17062漂亮= 0 sched的= 0/0 CGRP =默认的手柄= 1742184
  | schedstat =（0 0 0）UTM = 4 STM = 0核心= 1

线程799PRIO = 5 TID = 18 VMWAIT
  |组=主SCOUNT = 1 dsCount = 0的obj = 0x416daed8自我= 0x488218
  | sysTid = 17061漂亮= 0 sched的= 0/0 CGRP =默认的手柄= 4954264
  | schedstat =（0 0 0）UTM = 3 STM = 1芯= 0

线程798PRIO = 5 TID = 17 VMWAIT
  |组=主SCOUNT = 1 dsCount = 0的obj = 0x40850ce8自我= 0x4a9a28
  | sysTid = 17060漂亮= 0 sched的= 0/0 CGRP =默认的手柄= 5096688
  | schedstat =（0 0 0）UTM = 5 STM = 0核心= 0

线程797PRIO = 5 TID = 16 VMWAIT
  |组=主SCOUNT = 1 dsCount = 0的obj = 0x40870490自我= 0x39e6e8
  | sysTid = 17059漂亮= 0 sched的= 0/0 CGRP =默认的手柄= 6489784
  | schedstat =（0 0 0）UTM = 6 STM = 0核心= 0

线程796PRIO = 5 TID = 15 VMWAIT
  |组=主SCOUNT = 1 dsCount = 0的obj = 0x40941f78自我= 0x399aa8
  | sysTid = 17058漂亮= 0 sched的= 0/0 CGRP =默认的手柄= 8600264
  | schedstat =（0 0 0）UTM = 6 STM = 0核心= 0

线程795PRIO = 5 TID = 14 VMWAIT
  |组=主SCOUNT = 1 dsCount = 0的obj = 0x4102be68自我=​​ 0x1700b8
  | sysTid = 17057漂亮= 0 sched的= 0/0 CGRP =默认的手柄= 9814600
  | schedstat =（0 0 0）UTM = 5 STM = 0核心= 1

线程794PRIO = 5 TID = 13 VMWAIT
  |组=主SCOUNT = 1 dsCount = 0的obj = 0x41082f70自我= 0x1f78d0
  | sysTid = 17056漂亮= 0 sched的= 0/0 CGRP =默认的手柄= 7060200
  | schedstat =（0 0 0）UTM = 4 STM = 0核心= 1

线程793PRIO = 5 TID = 12 VMWAIT
  |组=主SCOUNT = 1 dsCount = 0的obj = 0x410dcbf0自我= 0x2ef6a0
  | sysTid = 17055漂亮= 0 sched的= 0/0 CGRP =默认的手柄= 7993768
  | schedstat =（0 0 0）UTM = 4 STM = 0核心= 0

线程792PRIO = 5 TID = 11 VMWAIT
  |组=主SCOUNT = 1 dsCount = 0的obj = 0x4113a620自我= 0x5edf28
  | sysTid = 17054漂亮= 0 sched的= 0/0 CGRP =默认的手柄= 7291408
  | schedstat =（0 0 0）UTM = 6 STM = 0核心= 0

线程791PRIO = 5 TID = 10 VMWAIT
  |组=主SCOUNT = 1 dsCount = 0的obj = 0x4084c0a0自我= 0x5c6b28
  | sysTid = 17053漂亮= 0 sched的= 0/0 CGRP =默认的手柄= 6171632
  | schedstat =（0 0 0）UTM = 6 STM = 0核心= 0

AsyncTask的＃5PRIO = 5 TID = 767等待
  |组=主SCOUNT = 1 dsCount = 0的obj = 0x410cbcb0自我= 0x85fca0
  | sysTid = 16758漂亮= 10 sched的= 0/0 CGRP = bg_non_interactive手柄= 10617808
  | schedstat =（0 0 0）UTM = 12 STM = 0核心= 0
  在java.lang.Object.wait（本机方法）
   - 等待＆LT; 0x410cbe80＆GT; （一java.lang.VMThread）TID = 767
  在java.lang.Thread.parkFor（Thread.java:1425）
  在java.lang.LangAccessImpl.parkFor（LangAccessImpl.java:48）
  在sun.misc.Unsafe.park（Unsafe.java:329）
  在java.util.concurrent.locks.LockSupport.park（LockSupport.java:157）
  在java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2022)
  在java.util.concurrent.LinkedBlockingQueue.take（LinkedBlockingQueue.java:413）
  在java.util.concurrent.ThreadPoolExecutor.getTask（ThreadPoolExecutor.java:1014）
  在java.util.concurrent.ThreadPoolExecutor.runWorker（ThreadPoolExecutor.java:1074）
  在java.util.concurrent.ThreadPoolExecutor中的$ Worker.run（ThreadPoolExecutor.java:574）
  在java.lang.Thread.run（Thread.java:1020）

AsyncTask的＃4PRIO = 5 TID = 766等待
  |组=主SCOUNT = 1 dsCount = 0的obj = 0x4101c710自我= 0x9e6ca8
  | sysTid = 16757漂亮= 10 sched的= 0/0 CGRP = bg_non_interactive手柄= 10383448
  | schedstat =（0 0 0）UTM = 36 STM = 0核心= 0
  在java.lang.Object.wait（本机方法）
   - 等待＆LT; 0x41079430＆GT; （一java.lang.VMThread）TID = 766
  在java.lang.Thread.parkFor（Thread.java:1425）
  在java.lang.LangAccessImpl.parkFor（LangAccessImpl.java:48）
  在sun.misc.Unsafe.park（Unsafe.java:329）
  在java.util.concurrent.locks.LockSupport.park（LockSupport.java:157）
  在java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2022)
  在java.util.concurrent.LinkedBlockingQueue.take（LinkedBlockingQueue.java:413）
  在java.util.concurrent.ThreadPoolExecutor.getTask（ThreadPoolExecutor.java:1014）
  在java.util.concurrent.ThreadPoolExecutor.runWorker（ThreadPoolExecutor.java:1074）
  在java.util.concurrent.ThreadPoolExecutor中的$ Worker.run（ThreadPoolExecutor.java:574）
  在java.lang.Thread.run（Thread.java:1020）

AsyncTask的＃5PRIO = 5 TID = 765等待
  |组=主SCOUNT = 1 dsCount = 0的obj = 0x410a9788自我= 0x7c0cd0
  | sysTid = 16738漂亮= 10 sched的= 0/0 CGRP = bg_non_interactive手柄= 2062320
  | schedstat =（0 0 0）UTM = 5 STM = 0核心= 1
  在java.lang.Object.wait（本机方法）
   - 等待＆LT; 0x41352368＆GT; （一java.lang.VMThread）TID = 765
  在java.lang.Thread.parkFor（Thread.java:1425）
  在java.lang.LangAccessImpl.parkFor（LangAccessImpl.java:48）
  在sun.misc.Unsafe.park（Unsafe.java:329）
  在java.util.concurrent.locks.LockSupport.park（LockSupport.java:157）
  在java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2022)
  在java.util.concurrent.LinkedBlockingQueue.take（LinkedBlockingQueue.java:413）
  在java.util.concurrent.ThreadPoolExecutor.getTask（ThreadPoolExecutor.java:1014）
  在java.util.concurrent.ThreadPoolExecutor.runWorker（ThreadPoolExecutor.java:1074）
  在java.util.concurrent.ThreadPoolExecutor中的$ Worker.run（ThreadPoolExecutor.java:574）
  在java.lang.Thread.run（Thread.java:1020）

AsyncTask的＃4PRIO = 5 TID = 411等待
  |组=主SCOUNT = 1 dsCount = 0的obj = 0x415f0098自我= 0x779eb8
  | sysTid = 16372漂亮= 10 sched的= 0/0 CGRP = bg_non_interactive手柄= 7993152
  | schedstat =（0 0 0）UTM = 47 STM = 2芯= 0
  在java.lang.Object.wait（本机方法）
   - 等待＆LT; 0x4113ed48＆GT; （一java.lang.VMThread）TID = 411
  在java.lang.Thread.parkFor（Thread.java:1425）
  在java.lang.LangAccessImpl.parkFor（LangAccessImpl.java:48）
  在sun.misc.Unsafe.park（Unsafe.java:329）
  在java.util.concurrent.locks.LockSupport.park（LockSupport.java:157）
  在java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2022)
  在java.util.concurrent.LinkedBlockingQueue.take（LinkedBlockingQueue.java:413）
  在java.util.concurrent.ThreadPoolExecutor.getTask（ThreadPoolExecutor.java:1014）
  在java.util.concurrent.ThreadPoolExecutor.runWorker（ThreadPoolExecutor.java:1074）
  在java.util.concurrent.ThreadPoolExecutor中的$ Worker.run（ThreadPoolExecutor.java:574）
  在java.lang.Thread.run（Thread.java:1020）

AsyncTask的＃3PRIO = 5 TID = 410等待
  |组=主SCOUNT = 1 dsCount = 0的obj = 0x411276c8自我= 0x66bb20
  | sysTid = 16371漂亮= 10 sched的= 0/0 CGRP = bg_non_interactive手柄= 7590640
  | schedstat =（0 0 0）UTM = 125 STM = 1芯= 1
  在java.lang.Object.wait（本机方法）
   - 等待＆LT; 0x41127860＆GT; （一java.lang.VMThread）TID = 410
  在java.lang.Thread.parkFor（Thread.java:1425）
  在java.lang.LangAccessImpl.parkFor（LangAccessImpl.java:48）
  在sun.misc.Unsafe.park（Unsafe.java:329）
  在java.util.concurrent.locks.LockSupport.park（LockSupport.java:157）
  在java.util.concurrent.locks.AbstractQueuedSynchronizer中的$ ConditionObj ...
 

解决方案

ANR是众所周知的问题。请确保你做的所有的昂贵的操作中的AsyncTask，不覆土的onCreate，ONSTART或onResume活动。

看响应，获取更多信息。

  

在具体地，活动应该做尽可能少设置在键生命周期方法如的onCreate（）和onResume（）。可能长时间运行的操作，例如网络或数据库操作，或者在计算上昂贵的计算，例如调整大小位图应在一个子线程（通过异步请求或在数据库中操作的情况下，）来完成。但是，这并不意味着你的主线程应该阻塞在等待子线程来完成 - 也不应该叫Thread.wait（）或视频下载（）。而不是阻塞在等待一个子线程来完成的，你的主线程应该提供一个处理程序后子线程回完成后。设计你的应用程序以这种方式可以让你的主线程保持响应输入，从而避免由于5秒输入事件的超时ANR对话框。这些相同的做法，应遵循该显示用户界面的任何其他线程，因为它们也受到同样的超时。

I'm experiencing some issues with application freezes. It looks like it has something to do with the hardwarerenderer and perhaps the amount of threads I'm using. I'd love for someone to have a look at the logs and tell me if there's anything obvious pointing out. Thanks.

    DALVIK THREADS:
(mutexes: tll=0 tsl=0 tscl=0 ghl=0 hwl=0 hwll=0)
"main" prio=5 tid=1 NATIVE
  | group="main" sCount=1 dsCount=0 obj=0x401f6600 self=0x125f8
  | sysTid=15811 nice=0 sched=0/0 cgrp=default handle=-1345129368
  | schedstat=( 0 0 0 ) utm=2495 stm=1172 core=0
  at com.google.android.gles_jni.EGLImpl.eglSwapBuffers(Native Method)
  at android.view.HardwareRenderer$GlRenderer.draw(HardwareRenderer.java:648)
  at android.view.ViewRoot.draw(ViewRoot.java:1594)
  at android.view.ViewRoot.performTraversals(ViewRoot.java:1410)
  at android.view.ViewRoot.handleMessage(ViewRoot.java:2040)
  at android.os.Handler.dispatchMessage(Handler.java:99)
  at android.os.Looper.loop(Looper.java:132)
  at android.app.ActivityThread.main(ActivityThread.java:4123)
  at java.lang.reflect.Method.invokeNative(Native Method)
  at java.lang.reflect.Method.invoke(Method.java:491)
  at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:841)
  at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:599)
  at dalvik.system.NativeStart.main(Native Method)

"Thread-811" prio=5 tid=31 VMWAIT
  | group="main" sCount=1 dsCount=0 obj=0x412479c0 self=0x45e478
  | sysTid=17073 nice=0 sched=0/0 cgrp=default handle=2020736
  | schedstat=( 0 0 0 ) utm=4 stm=0 core=1

"Thread-810" prio=5 tid=29 VMWAIT
  | group="main" sCount=1 dsCount=0 obj=0x41296560 self=0x4d2f38
  | sysTid=17072 nice=0 sched=0/0 cgrp=default handle=10050328
  | schedstat=( 0 0 0 ) utm=3 stm=1 core=1

"Thread-809" prio=5 tid=28 VMWAIT
  | group="main" sCount=1 dsCount=0 obj=0x4129b490 self=0x45e710
  | sysTid=17071 nice=0 sched=0/0 cgrp=default handle=5146952
  | schedstat=( 0 0 0 ) utm=3 stm=0 core=0

"Thread-808" prio=5 tid=27 VMWAIT
  | group="main" sCount=1 dsCount=0 obj=0x412d6008 self=0x44aa48
  | sysTid=17070 nice=0 sched=0/0 cgrp=default handle=3737640
  | schedstat=( 0 0 0 ) utm=2 stm=0 core=0

"Thread-807" prio=5 tid=26 VMWAIT
  | group="main" sCount=1 dsCount=0 obj=0x41352300 self=0x3abee0
  | sysTid=17069 nice=0 sched=0/0 cgrp=default handle=5418280
  | schedstat=( 0 0 0 ) utm=3 stm=0 core=1

"Thread-806" prio=5 tid=25 VMWAIT
  | group="main" sCount=1 dsCount=0 obj=0x41352a00 self=0x4d0a00
  | sysTid=17068 nice=0 sched=0/0 cgrp=default handle=5327520
  | schedstat=( 0 0 0 ) utm=3 stm=0 core=1

"Thread-805" prio=5 tid=24 VMWAIT
  | group="main" sCount=1 dsCount=0 obj=0x41352ef0 self=0x49bec8
  | sysTid=17067 nice=0 sched=0/0 cgrp=default handle=6587488
  | schedstat=( 0 0 0 ) utm=3 stm=0 core=1

"Thread-804" prio=5 tid=23 VMWAIT
  | group="main" sCount=1 dsCount=0 obj=0x4138be18 self=0x4e2c18
  | sysTid=17066 nice=0 sched=0/0 cgrp=default handle=9299592
  | schedstat=( 0 0 0 ) utm=3 stm=0 core=1

"Thread-803" prio=5 tid=22 VMWAIT
  | group="main" sCount=1 dsCount=0 obj=0x4138e5e0 self=0x483e58
  | sysTid=17065 nice=0 sched=0/0 cgrp=default handle=8949624
  | schedstat=( 0 0 0 ) utm=4 stm=0 core=0

"Thread-802" prio=5 tid=21 VMWAIT
  | group="main" sCount=1 dsCount=0 obj=0x4151b210 self=0x4b23d0
  | sysTid=17064 nice=0 sched=0/0 cgrp=default handle=4798984
  | schedstat=( 0 0 0 ) utm=3 stm=0 core=0

"Thread-801" prio=5 tid=20 VMWAIT
  | group="main" sCount=1 dsCount=0 obj=0x4151d118 self=0x492bd0
  | sysTid=17063 nice=0 sched=0/0 cgrp=default handle=10231792
  | schedstat=( 0 0 0 ) utm=3 stm=0 core=0

"Thread-800" prio=5 tid=19 VMWAIT
  | group="main" sCount=1 dsCount=0 obj=0x416cf1f8 self=0x482808
  | sysTid=17062 nice=0 sched=0/0 cgrp=default handle=1742184
  | schedstat=( 0 0 0 ) utm=4 stm=0 core=1

"Thread-799" prio=5 tid=18 VMWAIT
  | group="main" sCount=1 dsCount=0 obj=0x416daed8 self=0x488218
  | sysTid=17061 nice=0 sched=0/0 cgrp=default handle=4954264
  | schedstat=( 0 0 0 ) utm=3 stm=1 core=0

"Thread-798" prio=5 tid=17 VMWAIT
  | group="main" sCount=1 dsCount=0 obj=0x40850ce8 self=0x4a9a28
  | sysTid=17060 nice=0 sched=0/0 cgrp=default handle=5096688
  | schedstat=( 0 0 0 ) utm=5 stm=0 core=0

"Thread-797" prio=5 tid=16 VMWAIT
  | group="main" sCount=1 dsCount=0 obj=0x40870490 self=0x39e6e8
  | sysTid=17059 nice=0 sched=0/0 cgrp=default handle=6489784
  | schedstat=( 0 0 0 ) utm=6 stm=0 core=0

"Thread-796" prio=5 tid=15 VMWAIT
  | group="main" sCount=1 dsCount=0 obj=0x40941f78 self=0x399aa8
  | sysTid=17058 nice=0 sched=0/0 cgrp=default handle=8600264
  | schedstat=( 0 0 0 ) utm=6 stm=0 core=0

"Thread-795" prio=5 tid=14 VMWAIT
  | group="main" sCount=1 dsCount=0 obj=0x4102be68 self=0x1700b8
  | sysTid=17057 nice=0 sched=0/0 cgrp=default handle=9814600
  | schedstat=( 0 0 0 ) utm=5 stm=0 core=1

"Thread-794" prio=5 tid=13 VMWAIT
  | group="main" sCount=1 dsCount=0 obj=0x41082f70 self=0x1f78d0
  | sysTid=17056 nice=0 sched=0/0 cgrp=default handle=7060200
  | schedstat=( 0 0 0 ) utm=4 stm=0 core=1

"Thread-793" prio=5 tid=12 VMWAIT
  | group="main" sCount=1 dsCount=0 obj=0x410dcbf0 self=0x2ef6a0
  | sysTid=17055 nice=0 sched=0/0 cgrp=default handle=7993768
  | schedstat=( 0 0 0 ) utm=4 stm=0 core=0

"Thread-792" prio=5 tid=11 VMWAIT
  | group="main" sCount=1 dsCount=0 obj=0x4113a620 self=0x5edf28
  | sysTid=17054 nice=0 sched=0/0 cgrp=default handle=7291408
  | schedstat=( 0 0 0 ) utm=6 stm=0 core=0

"Thread-791" prio=5 tid=10 VMWAIT
  | group="main" sCount=1 dsCount=0 obj=0x4084c0a0 self=0x5c6b28
  | sysTid=17053 nice=0 sched=0/0 cgrp=default handle=6171632
  | schedstat=( 0 0 0 ) utm=6 stm=0 core=0

"AsyncTask #5" prio=5 tid=767 WAIT
  | group="main" sCount=1 dsCount=0 obj=0x410cbcb0 self=0x85fca0
  | sysTid=16758 nice=10 sched=0/0 cgrp=bg_non_interactive handle=10617808
  | schedstat=( 0 0 0 ) utm=12 stm=0 core=0
  at java.lang.Object.wait(Native Method)
  - waiting on <0x410cbe80> (a java.lang.VMThread) tid=767
  at java.lang.Thread.parkFor(Thread.java:1425)
  at java.lang.LangAccessImpl.parkFor(LangAccessImpl.java:48)
  at sun.misc.Unsafe.park(Unsafe.java:329)
  at java.util.concurrent.locks.LockSupport.park(LockSupport.java:157)
  at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2022)
  at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:413)
  at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1014)
  at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1074)
  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:574)
  at java.lang.Thread.run(Thread.java:1020)

"AsyncTask #4" prio=5 tid=766 WAIT
  | group="main" sCount=1 dsCount=0 obj=0x4101c710 self=0x9e6ca8
  | sysTid=16757 nice=10 sched=0/0 cgrp=bg_non_interactive handle=10383448
  | schedstat=( 0 0 0 ) utm=36 stm=0 core=0
  at java.lang.Object.wait(Native Method)
  - waiting on <0x41079430> (a java.lang.VMThread) tid=766
  at java.lang.Thread.parkFor(Thread.java:1425)
  at java.lang.LangAccessImpl.parkFor(LangAccessImpl.java:48)
  at sun.misc.Unsafe.park(Unsafe.java:329)
  at java.util.concurrent.locks.LockSupport.park(LockSupport.java:157)
  at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2022)
  at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:413)
  at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1014)
  at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1074)
  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:574)
  at java.lang.Thread.run(Thread.java:1020)

"AsyncTask #5" prio=5 tid=765 WAIT
  | group="main" sCount=1 dsCount=0 obj=0x410a9788 self=0x7c0cd0
  | sysTid=16738 nice=10 sched=0/0 cgrp=bg_non_interactive handle=2062320
  | schedstat=( 0 0 0 ) utm=5 stm=0 core=1
  at java.lang.Object.wait(Native Method)
  - waiting on <0x41352368> (a java.lang.VMThread) tid=765
  at java.lang.Thread.parkFor(Thread.java:1425)
  at java.lang.LangAccessImpl.parkFor(LangAccessImpl.java:48)
  at sun.misc.Unsafe.park(Unsafe.java:329)
  at java.util.concurrent.locks.LockSupport.park(LockSupport.java:157)
  at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2022)
  at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:413)
  at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1014)
  at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1074)
  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:574)
  at java.lang.Thread.run(Thread.java:1020)

"AsyncTask #4" prio=5 tid=411 WAIT
  | group="main" sCount=1 dsCount=0 obj=0x415f0098 self=0x779eb8
  | sysTid=16372 nice=10 sched=0/0 cgrp=bg_non_interactive handle=7993152
  | schedstat=( 0 0 0 ) utm=47 stm=2 core=0
  at java.lang.Object.wait(Native Method)
  - waiting on <0x4113ed48> (a java.lang.VMThread) tid=411
  at java.lang.Thread.parkFor(Thread.java:1425)
  at java.lang.LangAccessImpl.parkFor(LangAccessImpl.java:48)
  at sun.misc.Unsafe.park(Unsafe.java:329)
  at java.util.concurrent.locks.LockSupport.park(LockSupport.java:157)
  at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2022)
  at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:413)
  at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1014)
  at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1074)
  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:574)
  at java.lang.Thread.run(Thread.java:1020)

"AsyncTask #3" prio=5 tid=410 WAIT
  | group="main" sCount=1 dsCount=0 obj=0x411276c8 self=0x66bb20
  | sysTid=16371 nice=10 sched=0/0 cgrp=bg_non_interactive handle=7590640
  | schedstat=( 0 0 0 ) utm=125 stm=1 core=1
  at java.lang.Object.wait(Native Method)
  - waiting on <0x41127860> (a java.lang.VMThread) tid=410
  at java.lang.Thread.parkFor(Thread.java:1425)
  at java.lang.LangAccessImpl.parkFor(LangAccessImpl.java:48)
  at sun.misc.Unsafe.park(Unsafe.java:329)
  at java.util.concurrent.locks.LockSupport.park(LockSupport.java:157)
  at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObj...

解决方案

ANR is well known issue. Make sure you do all the expensive operations in AsyncTask and do not overburden onCreate, onStart or onResume activities.

Look at Responsiveness for more info.

In particular, Activities should do as little as possible to set up in key life-cycle methods such as onCreate() and onResume(). Potentially long running operations such as network or database operations, or computationally expensive calculations such as resizing bitmaps should be done in a child thread (or in the case of databases operations, via an asynchronous request). However, this does not mean that your main thread should block while waiting for the child thread to complete — nor should you call Thread.wait() or Thread.sleep(). Instead of blocking while waiting for a child thread to complete, your main thread should provide a Handler for child threads to post back to upon completion. Designing your application in this way will allow your main thread to remain responsive to input and thus avoid ANR dialogs caused by the 5 second input event timeout. These same practices should be followed for any other threads that display UI, as they are also subject to the same timeouts.

这篇关于ANR keyDispatchingTimedOut的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！