Anr Internal Function On Some Devices
Solution 1:
Looking at the ANR trace in the android-developers link, they're running Android 4.2 and their main thread is stalling when the SurfaceView tries to lock its Surface. I believe the problem there is that the render thread has called lockCanvas(), which locks the Surface (using a ReentrantLock), and then something happened that caused the SurfaceView to need to update (e.g. its size or position changed). You can see in the trace for the thread that (presumably) called lockCanvas() that it's actively running ("Thread-3899" is in NATIVE with state=R) in some complicated-looking bit of Skia code. So either the Skia code is looping forever, or is just taking a really long time to finish.
In your case, the render thread (SurfaceDraw) is suspended, possibly because it finished what it was doing and was returning from native code to the VM. Yours was a simple drawARGB() call so I'm not sure why it would take so long. It's possible that something else stalled it, and this is just where it happened to be when the ANR snapshot mechanism finally caught up.
It might be wise to grab your lock on the SurfaceHolder before you call lockCanvas() to ensure that you don't block waiting for it with the Canvas lock held.
(FWIW, synchronizing on a SurfaceHolder instance makes me a little nervous, since you can't know if something in SurfaceView is going to lock it for its own nefarious purposes. Don't think that's the problem here though.)
Post a Comment for "Anr Internal Function On Some Devices"