第三方异常问题的研究

在分析第三方兼容性和异常问题的时候，厂商的log并没有办法记录第三方的异常信息，其中包括堆栈信息，这个大家应该都知道，是因为java机制中，有一个UncaughtExceptionHandler的机制，这个机制实现的原理是当有异常时会报告虚拟机，最终调用到Thread类里面的dispatchUncaughtException，判断是否有重写uncaughtException的方法，如果有则调用重写的方法，如果没有则调用默认的方法。

       

     原理基本上如上述，但在这里我想说下下面几个东西：

1.在8.0以上的版本中为何UncaughtExceptionHandler无效；

2.默认的方法是什么方法，在哪里去set进去；

3.当第三方拦截了异常之后，我们厂商如何获取这些异常log。

4.当异常没有抛出的时候（不限于第三方）我们还有那些方法可以获取。  

Q1：在8.0以上的版本中为何UncaughtExceptionHandler无效

说第一个问题之前先简单说下UncaughtExceptionHandler的使用和实现，这个是java中就有的方法，这个方法的实现实在Thread里面，在Theard.JAVA里面有一个

所以说这个是关联线程的，在java中只能对某个线程检查，如果你只关联了某个线程这但其他线程发生异常时，这个是没有效果的，这个也符合java异常的原理。但这个在Android中不一样，安卓是可以做到对整个application的线程做到监听。

具体的实现如下，实现一个UncaughtExceptionHandler，再把这个set到线程中去，这样当发生异常的时候就会调用uncaughtException里面的内容了。

然而，这个在7.0上的时候完全是ok，但在7.0之后是还会调用到uncaughtException里面的方法，但是也会打印堆栈。上图是8.0的下图是7.1的。

通过分析系统默认的uncaughtExceptionHandler机制发现原来8.0在Thread类中新增了一个接口叫setUncaughtExceptionPreHandler

而这里面的LoggingHandler，实现如下：

对比打印的堆栈，这就是打印堆栈的内容。

Q2：默认的方法是什么方法，在哪里去set进去

     要回答这个问题，则要回到进程启动的原理，简单说下进程启动的原理：

      Amsstart activity之后，发现进程并不存在会通过Process 里面的start方法，最终调用到zygote里面fork之后调用ZygoteInit.handleChildPro（）此时新进程创建完成，开始配置新进程的一些，此后调用的过程为ZygoteConnection.handleChildPro（）->ZygoteInit.zygoteInit()->RuntimeInit.commonInit(),上面看到过commonInit()方法中有

   Thread.setUncaughtExceptionPreHandler(newLoggingHandler());

Thread.setDefaultUncaughtExceptionHandler(newKillApplicationHandler());

那默认的方法会做什么呢，LoggingHandler前面也看到了，打印异常堆栈内容。

再看下KillApplicationHandler的实现：

关于后面的处理流程这里就不详细讲了，大家可以去自己去看下源码，很easy。

Q3：当第三方拦截了异常之后，我们厂商如何获取这些异常log

     这个其实是这次分享的根本目的，就是如果一些apk如腾讯家族下面的app会把他们自己的异常通过bugly拦截，对于四大厂商也许还好，反馈过去得到的回馈还比较快，其他的厂商估计就不怎么理。

    要回答这个问题我们的第一想法是这是我的机器，我的地盘，我产生的东西，我还不能拿到吗？如果从“产生”来说，还真不能，我们Q2看了上面的原理之后，当进程有异常时，会找到由于注册了uncaughthandlerexception，直接跑了uncaughthander的方法里面去了，这个过程对系统来说完全透明，根本没有经过系统，也就是说系统根本拿不到这个异常，所以根本不能，这是我最初的想法，也是我和很多负责第三方同事的想法。

但是如果理解了异常捕获的原理，这个问题就可以可以非常ok的回答该如何做。前面讲过是否异常发生的原理是如果发生异常则虚拟机会通知到Thread线程，通过dispatchUncaughtException方法，分发处理异常的方法，请注意这个方法，里面有一个参数Throwable，也就是说如下做就可以

 

由于目前没有Android8.0的sdk，所以无法明确验证，但以下log中打印了两次堆栈，已经可以说明这个结果验证是ok的。

此问题是否会有风险呢，我觉得会有。风险为cts，不知道谷老大是否愿意同意我们这样做，，这个还有跑cts试下，毕竟这不是我的地盘是谷老大的地盘。

Q4：在当异常没有抛出的时候（不限于第三方）我们还有那些方法可以获取

     要回答这个问题同样要看下进程产生的流程，当zygote启动完成fork进程时，被fork出的进程会继承zygote的所有资源，包括虚拟机相关的信息。

在system_sever启动时，会通过AndroidRuntime::start把虚拟机等启起来，在这个方法中会通过env->CallStaticVoidMethod(startClass,startMeth, strArray);跑到java层，这个最终调用的activitythread里面的main，也就是进入死循环，如果没有异常时，这个方法永远在不会退出。但是如果发生异常了，那么这个方法就会退出，即执行下面的。

注意env这个变量，这个变量里面会会带很多东西，包括异常信息，也就是说我们可以在free之前打印异常，即

结果如下：

那这个是否万能的呢，所有的异常都能打印呢，no，我们说过异常和线程有关，如果主线程退出，则会打印这个异常非主线程时无法打印的。

有人问如果应用直接调用system.exit是否会从这里退出，当然不会，这个时异常，不是简单的退出，那如果发sig-9或者kill呢，也不会，因为kill -9时内核层面的了，不会从这里走的。