Android崩溃分析之Java 崩溃

来,
今天来说说Android崩溃中的Java崩溃。

Java 崩溃 简单点说就是在 Java 代码中,出现了未捕获异常,导致程序异常退出

崩溃分析

遇到崩溃其实很正常,而且随着用户量的增加,覆盖到的设备越来越多,可能越来越多的问题和崩溃就会摆在我们面前,我们需要的是认真仔细地对待这些崩溃,并想办法解决。
这里总结了一个崩溃三步走:

  • 排个序
    对于崩溃的问题,我们需要先排个序,优先解决那些重要的问题。比如哪些崩溃影响到用户的正常使用,或者影响到APP的主要功能。特别比如支付,登录这一类的问题。
  • 收集日志
    app运行期间日志很多,我们需要过滤出有用的信息来解决我们的崩溃问题。一般崩溃的日志都发生在warn或者error,我们需要重点关注。然后联系崩溃期间日志的上下文,了解崩溃期间都发生了什么,发生的环境如何。
  • 尝试复现
    这一点可能大家都深有体会,“只要能复现,我就能解决”。事实确实如此,能复现的问题,我们都可以通过本地调试来找到问题所在。所以对于线上的崩溃,我们尽量去复现它。但是要考虑到各种环境因素的影响,比如系统版本号,rom,手机型号,网络环境,CPU架构,APP版本等等。而且复现也能帮我们测试问题是否正确修复
崩溃修复

在了解到崩溃原因后,我们就要去分析具体的问题并解决了。解决的办法只有一个,研读代码,无论是自己写的还是第三方的,亦或者是系统源码,只要把代码读懂,就能找到崩溃源头。
这里带大家一起分析一个系统崩溃问题:

android.view.WindowManager$BadTokenException: Unable to add window -- token android.os.BinderProxy@a22690b is not valid; is your activity running?
        at android.view.ViewRootImpl.setView(ViewRootImpl.java:679)
        at android.view.WindowManagerGlobal.addView(WindowManagerGlobal.java:342)
        at android.view.WindowManagerImpl.addView(WindowManagerImpl.java:93)
        at android.widget.Toast$TN.handleShow(Toast.java:459)
        at android.widget.Toast$TN$2.handleMessage(Toast.java:342)
        at android.os.Handler.dispatchMessage(Handler.java:102)
        at android.os.Looper.loop(Looper.java:154)
        at android.app.ActivityThread.main(ActivityThread.java:6119)
        at java.lang.reflect.Method.invoke(Native Method)
        at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:886)
        at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:776)

这是Android7.1.1机型会发生的一个崩溃信息,可以看到崩溃发生在Toast的handleShow方法中,那我们就去研读下这部分的代码。

1、进入ViewRootImpl类中找到了报错的代码

                    res = mWindowSession.addToDisplay(mWindow, mSeq, mWindowAttributes,
                            getHostVisibility(), mDisplay.getDisplayId(),
                            mAttachInfo.mContentInsets, mAttachInfo.mStableInsets,
                            mAttachInfo.mOutsets, mInputChannel);
                    ……
                    switch (res) {
                        case WindowManagerGlobal.ADD_BAD_APP_TOKEN:
                        case WindowManagerGlobal.ADD_BAD_SUBWINDOW_TOKEN:
                            throw new WindowManager.BadTokenException(
                                    "Unable to add window -- token " + attrs.token
                                    + " is not valid; is your activity running?");

2、继续研究res的来源,发现其实就是WindowManagerService中对token进行了一个判断,如果无效或者为空就会报错。那么这个token哪里来的呢,为什么会失效呢?
先看Toast的显示过程,定位到show方法

public void show() {
        if (mNextView == null) {
            throw new RuntimeException("setView must have been called");
        }

        INotificationManager service = getService();
        String pkg = mContext.getOpPackageName();
        TN tn = mTN;
        tn.mNextView = mNextView;

        try {
            service.enqueueToast(pkg, tn, mDuration);
        } catch (RemoteException e) {
            // Empty
        }
    }

3、可以看到执行了NotificationManagerService的enqueueToast方法。
终于让我,找到token了

@Override
public void enqueueToast(String pkg, ITransientNotification callback, int duration)
{
Binder token = new Binder();
mWindowManagerInternal.addWindowToken(token,
WindowManager.LayoutParams.TYPE_TOAST);
record = new ToastRecord(callingPid, pkg, callback, duration, token);
mToastQueue.add(record);
index = mToastQueue.size() - 1;
keepProcessAliveIfNeededLocked(callingPid);
……
  if (index == 0) {
       showNextToastLocked();
  }
}

 void showNextToastLocked() {
        ToastRecord record = mToastQueue.get(0);
        while (record != null) {
            try {
                record.callback.show(record.token);
                scheduleTimeoutLocked(record);
                return;
            }
          ……
        }
    }

private void scheduleTimeoutLocked(ToastRecord r)
    {
        mHandler.removeCallbacksAndMessages(r);
        Message m = Message.obtain(mHandler, MESSAGE_TIMEOUT, r);
        long delay = r.duration == Toast.LENGTH_LONG ? LONG_DELAY : SHORT_DELAY;
        mHandler.sendMessageDelayed(m, delay);
    }

 case MESSAGE_TIMEOUT:
         handleTimeout((ToastRecord)msg.obj);
         break;

private void handleTimeout(ToastRecord record)
    {
        if (DBG) Slog.d(TAG, "Timeout pkg=" + record.pkg + " callback=" + record.callback);
        synchronized (mToastQueue) {
            int index = indexOfToastLocked(record.pkg, record.callback);
            if (index >= 0) {
                cancelToastLocked(index);
            }
        }
    }

void cancelToastLocked(int index) {
       ToastRecord record = mToastQueue.get(index);
       ToastRecord lastToast = mToastQueue.remove(index);
       mWindowManagerInternal.removeWindowToken(lastToast.token, true);
}

4、可以看到罪魁祸首就是这个removeWindowToken方法,它移除当前的toast的token。

到此,真相大白,如果toast显示的时候主线程被阻塞,就会导致超时,从而token失效,最终发生异常。

发现原因了之后,我们就开始上一节说的步骤,试试复现下:

Toast.makeText(this, "toast 崩溃测试", Toast.LENGTH_SHORT).show();
try {
   Thread.sleep(5000);
} catch (Exception e) {
   e.printStackTrace();
}

嘿嘿,接下来该去解决它了。

解决方案

刚才说到这是Android 7.1.1才有的问题。那么其他版本为什么没有这个问题呢?我们去看看源码:

#android 7.1.1
public void handleShow(IBinder windowToken) {
                mWM.addView(mView, mParams);
                trySendAccessibilityEvent();
}
#android 9.0
public void handleShow(IBinder windowToken) {
               try {
                    mWM.addView(mView, mParams);
                    trySendAccessibilityEvent();
                } catch (WindowManager.BadTokenException e) {
                    /* ignore */
                }
}

原来就是加了一个异常捕获。那我们学习官方的就好了,我们发现handleShow的调用来自Toast内部的Handler处理消息中,那我们就来把这个Handler替换掉吧。

public class ToastUtils {

    public static void showToast(Context context, CharSequence text, int duration) {
        Toast toast = Toast.makeText(context, text, duration);
        if (Build.VERSION.SDK_INT == Build.VERSION_CODES.N_MR1) {
            hookToast(toast);
        }
        toast.show();
    }

    /**
     * 反射替换handler
     * @param toast
     */
    private static void hookToast(Toast toast) {
        try {
            //获取mTN成员变量
            Field mField_mTN = toast.getClass().getDeclaredField("mTN");
            mField_mTN.setAccessible(true);
            //获取mHandler成员变量
            Object TN = mField_mTN.get(toast);
            Field mField_mHandler = TN.getClass().getDeclaredField("mHandler");
            mField_mHandler.setAccessible(true);
            //替换handler
            mField_mHandler.set(TN, new ToastNewHandler((Handler)TN));
        } catch (Exception e) {
            e.printStackTrace();
        }
    }

    /**
     * handler
     */
    private static class ToastNewHandler extends Handler {

        private Handler impl;

        public ToastNewHandler(Handler impl) {
            this.impl = impl;
        }

        @Override
        public void handleMessage(Message msg) {
            try {
                impl.handleMessage(msg);
            } catch (Exception e) {
                e.printStackTrace();
            }

        }
    }

}

bug已修复。

谢谢大家支持!
——积木

发布了8 篇原创文章 · 获赞 3 · 访问量 2922

猜你喜欢

转载自blog.csdn.net/liuzhengisme/article/details/101680924