崩溃优化之Java层crash原理分析

由心99

已于 2023-01-17 11:44:24 修改

阅读量1k

点赞数

分类专栏：源码分析文章标签： java 性能优化 Powered by 金山文档

于 2023-01-17 11:18:31 首次发布

本文链接：https://blog.csdn.net/qq_42165012/article/details/128713334

版权

源码分析专栏收录该内容

6 篇文章 2 订阅

订阅专栏

一、造成系统崩溃（crash）的原因是什么？

未捕获的异常

有Java层面，和Native层面。

在我们平常操作中，如果有未捕获的异常，会导致系统崩溃，这个崩溃本质上是人为操作的，人为去操作系统主动退出（后面讲源码的地方可以看到）。

ANR

系统因为线程阻塞问题，导致的无响应。

WTF（What a Terrible Failure）

一般指，系统中自己编码没有按照android要求进行，例如发送未受保护的广播、启动的Activity未在注册文件里注册等等；

这个一般不用太关注，主要写代码按标准来就行。

二、java层未捕获的异常是如何导致崩溃的

源码分析步骤1

首先我们先明确一个目的，我们的main函数的启用本身作为主线程存在，那么在我们想要探索系统到底如何处理异常，需要去关注到一个类Thread；

在我们的程序代码中，如果存在一个异常，任何地方都没有去捕获处理它的话，它就会一路往上抛，最终来到main函数，如果main函数也没有处理这个异常，就会给到JVM来处理，JVM会给到当前的线程Thread来处理。

源码分析步骤2

在Thread类中，看到一段这样的函数dispatchUncaughtException（）；

注释翻译为：向处理程序发送未捕获的异常。此方法旨在仅由JVM调用；可以理解为，未处理的异常会走到这里来：

在上图我们可以看到官方明确告知，JVM在处理未经捕获的异常时，会调用当前dispatchUncaughtException函数进行处理，这个里面我们能看到一个类型为UncaughtExceptionHandler的类。

在上图的逻辑中我们可以看到如果没有设置uncaughtExceptionHandler，将使用线程所在的线程组（ThreadGroup）来处理这个未捕获异常。线程组ThreadGroup实现了UncaughtExceptionHandler，所以可以用来处理未捕获异常。

源码分析步骤3

所以，我们重点来看ThreadGroup中，是如何来处理未捕获异常的：在Thread类的dispatchUncaughtException函数中，最后调用了getUncaughtExceptionHandler().uncaughtException(this, e); 我们知道这个getUncaughtExceptionHandler()返回的是ThreadGroup，所以我们来看ThreadGroup中的uncaughtException方法：

默认情况下，ThreadGroup处理未捕获异常的逻辑是：

首先将异常消息通知给父线程组(如果parent不为空的话)；

然后尝试利用一个默认的defaultUncaughtExceptionHandler来处理异常；

如果没有默认的异常处理器则将错误信息输出打印到System.err。

这里可以思考下，我们可以自定义一个异常处理类，继承下 Thread.UncaughtExceptionHandler，然后去处理未捕获的异常。记得需要手动去调用Thread.setUncaughtExceptionPreHandler()方法设置下，有了这个自定义异常处理类，就可以做相应的崩溃优化。

源码分析步骤4

回到Thread中，思考下：既然他是通过getDefaultUncaughtExceptionHandler来处理，现在我们并没有看到有相关的设置，但是在Thread中我们看到了他对外提供了对应的设置函数：Thread.setUncaughtExceptionPreHandler()。

源码分析步骤5

思考下：系统是否会有地方默认给我们设置了uncaughtExceptionHandler?

因为从上面的源码看来，我们并没有看到有让系统直接崩溃掉的情况，因为默认是ThreadGroup去处理，他只不过是做了一个日志信息的记录,不会有退出的情况，那么肯定是有哪个地方默认设置了uncaughtExceptionHandler，让系统退出的。

源码分析步骤6

来看下RuntimeInit这个类，zygote负责启动RuntimeInit进程（作用：app运行时环境初始化，用来初始化运行时的一系列信息，其中包含异常处理），它里面有个main方法：

这里设置了默认的异常处理：KillApplicationHandler。

源码分析步骤7

我们来看下KillApplicationHandler：

重点来看 uncaughtException(Thread t, Throwable e)这个方法：

看到这里就知道了，默认的异常处理（杀进程）是在RuntimeInit进程（作用：app运行时环境初始化，用来初始化运行时的一系列信息，其中包含异常处理）的main（）方法里设置的。

小总结

三、AMS如何承接应用的异常信息上报？

在上面的源码分析步骤7我们知道了，在KillApplicationHandler的uncaughtException（）方法里，最终异常信息有一个AMS上报过程：

来看下ActivityManagerService.handleApplicationCrash（）方法：

从上面可以看出,若传入app为null时,processName就设置为system_server，意思是：如果没有来源默认判定是系统进程自己。接着看handleApplicationCrashInner（String eventType......）方法：

参数eventType是指事件类型，具体如下：

Java层未捕捉的异常：crash

ANR：anr

native层的异常：native_crash

现在我们看的是java的异常，所以这个类型传的是crash。

接着看handleApplicationCrashInner（）函数：

中间的可以先不管他们，这个可以理解为在进行系统日志输出，具体的处理是在addErrorToDropBox()函数中。

重点注意：无论是java crash、native_crash、ANR或是wtf，最终都是来到这里，交由addErrorToDropBox()函数去处理。

四、DropBoxManager

addErrorToDropBox()函数和DropBoxManager有关，Android Dropbox 是 Android 在 Froyo(API level 8) 引入的用来持续化存储系统数据的机制。主要用于记录 Android 运行过程中, 内核, 系统进程, 用户进程等出现严重问题时的 log, 可以认为这是一个可持续存储的系统级别的 logcat。

记录位置：在data/system/dropbox中：

也就是说，我们想要看系统的崩溃日志，可以在这个文件路径下找。