问题
We have found several cases for this kind of crashes reported by backend logging monitoring. It seems the crashes do not tie to particular UX failure. And from the reports, there is no sign of how our own classes being involved(no sign of any of our classes names). Here is an example of typical crashes:
java.lang.NullPointerException: Attempt to read from field 'int android.view.View.mViewFlags' on a null object reference
at android.view.ViewGroup.dispatchDraw(ViewGroup.java:3357)
at android.view.View.updateDisplayListIfDirty(View.java:14288)
at android.view.View.getDisplayList(View.java:14315)
at android.view.ViewGroup.recreateChildDisplayList(ViewGroup.java:3549)
at android.view.ViewGroup.dispatchGetDisplayList(ViewGroup.java:3528)
at android.view.View.updateDisplayListIfDirty(View.java:14253)
at android.view.View.getDisplayList(View.java:14315)
at android.view.ViewGroup.recreateChildDisplayList(ViewGroup.java:3549)
at android.view.ViewGroup.dispatchGetDisplayList(ViewGroup.java:3528)
at android.view.View.updateDisplayListIfDirty(View.java:14253)
at android.view.View.getDisplayList(View.java:14315)
at android.view.ViewGroup.recreateChildDisplayList(ViewGroup.java:3549)
at android.view.ViewGroup.dispatchGetDisplayList(ViewGroup.java:3528)
at android.view.View.updateDisplayListIfDirty(View.java:14253)
at android.view.View.getDisplayList(View.java:14315)
at android.view.ViewGroup.recreateChildDisplayList(ViewGroup.java:3549)
at android.view.ViewGroup.dispatchGetDisplayList(ViewGroup.java:3528)
at android.view.View.updateDisplayListIfDirty(View.java:14253)
at android.view.View.getDisplayList(View.java:14315)
at android.view.ViewGroup.recreateChildDisplayList(ViewGroup.java:3549)
at android.view.ViewGroup.dispatchGetDisplayList(ViewGroup.java:3528)
at android.view.View.updateDisplayListIfDirty(View.java:14253)
at android.view.View.getDisplayList(View.java:14315)
at android.view.ViewGroup.recreateChildDisplayList(ViewGroup.java:3549)
at android.view.ViewGroup.dispatchGetDisplayList(ViewGroup.java:3528)
at android.view.View.updateDisplayListIfDirty(View.java:14253)
at android.view.View.getDisplayList(View.java:14315)
at android.view.ViewGroup.recreateChildDisplayList(ViewGroup.java:3549)
at android.view.ViewGroup.dispatchGetDisplayList(ViewGroup.java:3528)
at android.view.View.updateDisplayListIfDirty(View.java:14253)
at android.view.View.getDisplayList(View.java:14315)
at android.view.ViewGroup.recreateChildDisplayList(ViewGroup.java:3549)
at android.view.ViewGroup.dispatchGetDisplayList(ViewGroup.java:3528)
at android.view.View.updateDisplayListIfDirty(View.java:14253)
at android.view.View.getDisplayList(View.java:14315)
at android.view.ViewGroup.recreateChildDisplayList(ViewGroup.java:3549)
at android.view.ViewGroup.dispatchGetDisplayList(ViewGroup.java:3528)
at android.view.View.updateDisplayListIfDirty(View.java:14253)
at android.view.View.getDisplayList(View.java:14315)
at android.view.ThreadedRenderer.updateViewTreeDisplayList(ThreadedRenderer.java:273)
at android.view.ThreadedRenderer.updateRootDisplayList(ThreadedRenderer.java:279)
at android.view.ThreadedRenderer.draw(ThreadedRenderer.java:318)
at android.view.ViewRootImpl.draw(ViewRootImpl.java:2561)
at android.view.ViewRootImpl.performDraw(ViewRootImpl.java:2377)
at android.view.ViewRootImpl.performTraversals(ViewRootImpl.java:2007)
at android.view.ViewRootImpl.doTraversal(ViewRootImpl.java:1086)
at android.view.ViewRootImpl$TraversalRunnable.run(ViewRootImpl.java:6453)
at android.view.Choreographer$CallbackRecord.run(Choreographer.java:846)
at android.view.Choreographer.doCallbacks(Choreographer.java:647)
at android.view.Choreographer.doFrame(Choreographer.java:601)
at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:829)
at android.os.Handler.handleCallback(Handler.java:739)
at android.os.Handler.dispatchMessage(Handler.java:95)
at android.os.Looper.loop(Looper.java:135)
at android.app.ActivityThread.main(ActivityThread.java:5254)
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:927)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:713)
Does anyone know whether there is related bug logged against Android code?
回答1:
Possible Solution
I had this same issue. I setup an animation and in onAnimationEnd I was removing the object that had been animated which is when problems started. What I did was setup an asynchronous Runnable to wait 100 milliseconds after the animation had stopped before removing the animated object:
the object previously animated is this._loader
private void removeLoader() {
final ContentContainer self = this; // "CustomContainer" needs to match the type of `this`
Handler h = new Handler();
h.postAtTime(new Runnable() {
@Override
public void run() {
MainActivity.instance.runOnUiThread(new Runnable() {
@Override
public void run() {
try {
if(self._loader == null) {
// there is no loader. quit now while you still have the chance!!
return;
}
while(self._loader.getParent() != null) {
removeView(self._loader);
}
} catch(Exception e) {
Crashlytics.logException(e);
e.printStackTrace();
}
self._loader = null;
}
});
}
}, 100);
}
Cheers
回答2:
I was facing same problem. I resolved with Handler.
new Handler(Looper.getMainLooper()).post(new Runnable() {
@Override
public void run() {
// remove fragment from here
}
});
回答3:
The problem is in the ViewGroup's dispatchDraw() method. This method tries to draw all the ViewGroup's children. When a child is null, you get an exception, which most likely comes from this line: if ((child.mViewFlags & VISIBILITY_MASK) == VISIBLE) { (notice the mViewFlags).
So the problem is that one of your views, somewhere, is not properly initialized. I'm afraid that's the best I can do.
回答4:
We started getting this error unexpectedly too. It was tracked down to fragment animations being the issue. More specifically using custom animations with replace() in a fragment transaction when the app is built against Local Maven repository for Support Libraries rev > 26.
Possible solution
Downgrade Local Maven repository for Support Libraries to rev 26. See here
回答5:
Possible cause: I was having the exact same issue. It turned out it started to happen when I added code to modify the view tree within onDraw() call. To be specific, I removed a view with children in my derived onDraw() when certain conditions were met. I now believe this is a bad thing to do, probably because the platform is trying to draw views that I have now removed from the view tree. I resolved the issue by posting the deletion with Runnable to happen after the call to onDraw() has finished.
回答6:
Override dispatchDraw method and put in it a try/catch block, like this:
public void dispatchDraw(Canvas c)
{
try
{
super.dispatchDraw(c);
return;
}
catch(Exception exception)
{
return;
}
}
回答7:
Even though the exception is common, the causing source is uncommon and occurs when you have so many dynamic views. Sometimes scrolling in the Instagram page cause this exception. However, if you look deep into that, the hardware problem may come to be an issue. So just handle(catch) the issue.
来源：https://stackoverflow.com/questions/33242776/android-viewgroup-crash-attempt-to-read-from-field-int-android-view-view-mview