今天本来想写的题材没写完,于是就找了一篇我很久之前写的,比较简单的文章给大家看看吧。
今天来说说Android崩溃中的Java崩溃。
Java 崩溃 简单点说就是在 Java 代码中,出现了未捕获异常,导致程序异常退出
遇到崩溃其实很正常,而且随着用户量的增加,覆盖到的设备越来越多,可能越来越多的问题和崩溃就会摆在我们面前,我们需要的是认真仔细地对待这些崩溃,并想办法解决。这里总结了一个崩溃三步走:
在了解到崩溃原因后,我们就要去分析具体的问题并解决了。解决的办法只有一个,研读代码,无论是自己写的还是第三方的,亦或者是系统源码,只要把代码读懂,就能找到崩溃源头。这里带大家一起分析一个系统崩溃问题:
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替换掉,然后在自己的Hanlder处理中进行异常捕获。
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已修复。
今天发的这篇远古文其实和我本来想写的题材有点点关系,大家能猜到一点吗?