每日一问 SDK 的问题 怪我咯？

可以用移花接木之法：

只是我们的手法与大家熟知的手法不一样，因为现在的场景是在SDK中，无法直接修改它的代码，所以用反射替换掉Handler，也是于事无补的。

除非，你能拿到NotificationManagerService的实例，替换掉它的mHandler，这个Handler的handleMessage方法中有接收一个what为MESSAGE_TIMEOUT的消息，收到此消息后，会取消掉 刚刚已经通知给Toast.TN那边显示的Toast的View 所对应的Token。

没错，也是通过上一个问题中提到的removeWindowToken方法来从Map中移除对应的<Binder, WindowToken>键值对了。

问题就出在这里，先来看一下NotificationManagerService的showNextToastLocked方法：

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

record.callback，就是Toast.TN的实例，TN的这个show方法中，会send一条带有token的message到它的mHandler，mHandler收到消息之后，就会调用大家熟知的那个会报错的方法：handleShow。

现在看回上面的showNextToastLocked方法，可以看到在回调了show方法之后，还调用了一个scheduleTimeoutLocked方法，这个方法会给NotificationManagerService中的mHandler发一个延时消息，延时的时长就是刚刚调用show方法的Toast的实际时长，这条消息的what，就是上面说的MESSAGE_TIMEOUT。

好，再回到刚刚说的那个会报错的handleShow方法，如果这时候，主线程有很多任务，等待处理的时间超出了当前要显示的Toast的时长（这时候对应的token已经被移除了），当调用WindowManager的addView方法准备把这个Toast的View显示出来时，WindowSession的addToDisplay方法就不能根据这个token找到WindowToken了，所以会返回一个ADD_BAD_APP_TOKEN的Flag，也就是"xxx is not valid; is your activity running?"这条描述了。

emmm，那现在会萌生一个想法：替换掉NotificationManagerServiced的mHandler，在收到MESSAGE_TIMEOUT消息之后，不立即remove，而是给主线程post这个remove任务，这样的话，就能保证Toast能在token被remove之前show出来了，也就避免了BadTokenException。

但实际上，你是拿不到NotificationManagerService的实例的，只能拿到它的代理类。所以这个想法，就让它石沉大海吧。

正确的解决方法：

我们说的移花接木，既不是替换掉Toast.TN中的mHandler，也不是替换NotificationManagerService的mHandler，更不是替换掉原生的Toast，而是替换掉Application的WindowManager！

为什么呢？

先来看看那个会报错的handleShow方法：

    public void handleShow(IBinder windowToken) {

        ......

        Context context = mView.getContext().getApplicationContext();
        if (context == null) {
            context = mView.getContext();
        }
        mWM = (WindowManager) context.getSystemService(Context.WINDOW_SERVICE);
        mWM.addView(mView, mParams);

        ......

    }

看到没有？那个WindowManager它是通过context的getSystemService来获取的，而这个context实例，就是Application！

它还把View的Context当作第二选择，以防万一。

不过在日常开发中，我们使用Toast的时候，无非就借助Activity、Fragment、Service的Context来显示。

Fragment的Context也是Activity，所以Toast的View的Context，就只有Activity和Service了。而这两个类的getApplicationContext方法：

    @Override
    public Context getApplicationContext() {
        return (mPackageInfo != null) ?
                mPackageInfo.getApplication() : mMainThread.getApplication();
    }

在非不可预测的特殊情况下，是不会为空的，mPackageInfo和mMainThread这两个类里面，都没有把Application引用置空的代码。

那现在就等于是调用Application的getSystemService方法来获取WindowManager了，我们可以在Application中重写这个方法（必须在manifest里面使用），并且判断版本和对象类型，确定是WindowManager之后，返回一个WindowManger的包装类，就像这样：

    override fun getSystemService(name: String): Any? {
        val service = super.getSystemService(name)

        if (service is WindowManager && Build.VERSION.SDK_INT == 25) {
            return object : WindowManager {
                override fun addView(view: View?, params: ViewGroup.LayoutParams?) {
                    try {
                        service.addView(view, params)
                    } catch (e: WindowManager.BadTokenException) {
                        e.printStackTrace()
                        //这里可以添加一些自定义的逻辑
                    }
                }

                override fun updateViewLayout(view: View?, params: ViewGroup.LayoutParams?) {
                    service.updateViewLayout(view, params)
                }

                override fun removeView(view: View?) {
                    service.removeView(view)
                }

                override fun getDefaultDisplay(): Display = service.defaultDisplay

                override fun getCurrentImeTouchRegion() = service.currentImeTouchRegion

                override fun removeViewImmediate(view: View?) {
                    service.removeViewImmediate(view)
                }

                override fun requestAppKeyboardShortcuts(
                    receiver: WindowManager.KeyboardShortcutsReceiver?,
                    deviceId: Int
                ) {
                    service.requestAppKeyboardShortcuts(receiver, deviceId)
                }
            }
        }
        return service
    }

可以看到，我们把WindowManger的全部方法都重写了一遍，把具体的逻辑都交给了super.getSystemService返回的WindowManager实例，只是我们在调用它的addView方法时，像其他版本那样，外面加了try catch。

这样的话，当发生BadTokenException时，也不会crash了。

这个方法还有个好处就是，其他地方的代码不需要做任何修改，就算SDK里面的方法有使用Toast，发生异常时我们也一样能catch到。

可以使用kotlin的类代理简化代码：

    override fun getSystemService(name: String): Any? {
        val service = super.getSystemService(name)
        if (service is WindowManager && Build.VERSION.SDK_INT == 25) {
            return object : WindowManager by service {
                override fun addView(view: View?, params: ViewGroup.LayoutParams?) {
                    try {
                        service.addView(view, params)
                    } catch (e: WindowManager.BadTokenException) {
                        e.printStackTrace()
                        //这里可以添加一些自定义的逻辑
                    }
                }
            }
        }
        return service
    }

hook toast，然后拦截“enqueueToast”，替换成自己的handler就可以了。部分华为手机需要拦截“enqueueToastEx”

try {
            // 获得HOOK点
            val toast = Toast(this)
            val getService = toast.javaClass.getDeclaredMethod("getService")
            getService.isAccessible = true
            val sService = getService.invoke(toast)
            // 生成代理对象
            val toastProxy = ToastProxy()
            val proxyNotiMng = toastProxy.newProxyInstance(sService)
            // 替换 sService
            val sServiceField = Toast::class.java.getDeclaredField("sService")
            sServiceField.isAccessible = true
            sServiceField.set(toast, proxyNotiMng)

        } catch (e: Exception) {
            e.printStackTrace()
        }

public class ToastProxy implements InvocationHandler {

     private Object mService;

     public Object newProxyInstance(Object sService) {
         this.mService = sService;
         return Proxy.newProxyInstance(sService.getClass().getClassLoader(),
                 sService.getClass().getInterfaces(), this);
     }

     @Override
     public Object invoke(Object arg0, Method method, Object[] args)
             throws Throwable {
         try {
             if ("enqueueToast".equals(method.getName()) || "enqueueToastEx".equals(method.getName())) {
                 if (args != null && args.length > 0) {

                     Field sField_TN = Toast.class.getDeclaredField("mTN");
                     sField_TN.setAccessible(true);
                     Field sField_TN_Handler = sField_TN.getType().getDeclaredField("mHandler");
                     sField_TN_Handler.setAccessible(true);

                     Object tn = args[1];
                     Handler preHandler = (Handler) sField_TN_Handler.get(tn);
                     sField_TN_Handler.set(tn, new SafelyHandlerWarpper(preHandler));
                 }
             }
             return method.invoke(mService, args);
         } catch (Exception e) {
             e.printStackTrace();
         }
         return null;
     }


    private static class SafelyHandlerWarpper extends Handler {

        private Handler impl;

        SafelyHandlerWarpper(Handler impl) {
            this.impl = impl;
        }

        @Override
        public void dispatchMessage(Message msg) {
            try {
                super.dispatchMessage(msg);
            } catch (Exception e) {

            }

        }

        @Override
        public void handleMessage(Message msg) {
            impl.handleMessage(msg);//需要委托给原Handler执行
        }
    }
 }

try一下

目前是想到两种方案

1. 编译期通过类似 AspectJ 的字节码修改框架将需要用到 Toast 的地方全部修改
2. 运行时hook show，然后拿到mTN进行处理。看了一下Toast源码，hook点比较多，拿到mTN就行

第一种方案比较稳定一些，第二种稍微差点