第三方异常问题的研究

时间:2024-04-10 19:24:03

在分析第三方兼容性和异常问题的时候,厂商的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时内核层面的了,不会从这里走的。