1. 技术文章
  2. Need some insight on this recurring issue, ANR keyDispatchingTimedOut

Need some insight on this recurring issue, ANR keyDispatchingTimedOut

由 末鹿安然 提交于 2019-12-04 20:59:18
Peter Teoh

In here:

http://developer.android.com/guide/practices/design/responsiveness.html

ANR is when the main thread is blocking on something, so long operation is always advised to do it in the child thread:

TO QUOTE:

Therefore any method that runs in the main thread should do as little work as possible. 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.

I understand it is not easy, but the recommendation from above is that UI should be done not in the main thread.

On the other hand, you main thread is in "WAIT" state, meaning non-async operation is used. Perhaps u want to try the async option - which should result in TIMED_WAIT state, as in the following:

Android - how do I investigate an ANR?

(whose main thread is ok).

But like discussed here:

http://groups.google.com/group/android-ndk/browse_thread/thread/84d6a9be21f4e579/b83537161b96da82?q=%22Bitmap+creation+and+composition+in+native+code%22#b83537161b96da82

your problem I suspect is because bitmap painting takes too long between lockCanvas() and unlockCanvas() - perhaps you might want to break the bitmap update into smaller pieces? And within the same discussion is also mentioned use of JNI/NDK to do the bitmap calculation - which should not be done inside the Java-based bitmap update method - if it takes too long to do the calculation.

Recommended read:

http://obviam.net/index.php/the-android-game-loop/

Thanks.

Based on the logs, the only reason I can think of that could have triggered an ANR is:

As far as i know, usually in Java every thread is associated with 2 components. One being Program counter and the other being Garbage Collector. So every thread will have a gc monitor happening throughout.

at java.lang.Object.wait(Native Method) - waiting on <0x4001d950> (a java.lang.VMThread)

VMThreads are ideally used to handle this aspect of monitoring gc, almost parallelly. So what i could think of, for your scenario, is SurfaceViewis trying to acquire a lock but is unable to because VMThread is holding the lock, unreleased yet (may be due to some major GC op), thus waiting for vmthread to release the lock.

You might want to check your main log dump which has gc activities logged, that might give you a better picture as to why gc was hogging this threads CPU time so much and then app profiling may help. Jus check.

标签
android
surfaceview
android-anr-dialog
易学教程内所有资源均来自网络或用户发布的内容，如有违反法律规定的内容欢迎反馈！
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!