一. 造成系统崩溃的主要原因
1.未捕获的异常
java + native
2.ANR
3.WTF(What a Terrible Failure)
一般指系统中自己编码没有按照android要求进行（比如native没有返回值）
二. 系统崩溃所谓优化到底要做什么？
1.规避问题，优化用户体验
2.收集信息上传，便于分析
三. 学习思路
1. 系统如何对于这一类问题进行处理
2.结合framework认知，给出特殊解决方案
3. 日志信息采集
四. 抛出异常导致崩溃分析
1. main函数启用本身作为主线程存在，需要关注类Thread
2.Thread.dispatchUncaughtException
JVM在处理未经捕获的异常时，会调用当前dispatchUncaughtException函数进行处理。
image.png
如果没有设置uncaughtExceptionHandler，将使用线程所在的线程组来处理这个未捕获异常。线程组ThreadGroup实现了UncaughtExceptionHandler，所以可以用来处理未捕获异常。
image.png
3.ThreadGroup
默认情况下，线程组处理未捕获异常的逻辑是，首先将异常消息通知给父线程组然后尝试利用一个默认的defaultUncaughtExceptionHandler来处理异常，如果没有默认的异常处理器，则将错误信息输出到System.err
image.png
4.Thread.setUncaughtExceptionHandler
对外提供设置Handler功能
image.png
5.思考系统是否会有地方默认给我们设置了Handler
6.认识RuntimeInit
a.RuntimeInit运行时初始化进程
初始化运行的一系列信息，其中包含异常处理
image.png
c.commonInit方法
当前线程中设置了setDefaultUncaughtExceptionHandler其类型未KillApplicationHandler
image.png
7.KillApplicationHandler
android内部默认初始化设置的主线程异常处理方案
image.png
方法总结：
- 调用当前ActivityThread的当前线程，直接stopProFling
- 上报AMS崩溃异常信息
- 在最终的 finally中直接kill掉进程且退出当前进程。
8.结论
- JVM通过调用dispatchUncaughtException来进行未捕获异常处理。
- 具体对应的提供处理能力的是UncaughtExceptionHandler这个类。
- 默认ThreadGroup提供日志打印处理。
- 但是在进程环境初始化时RuntimeInit提供杀死进程的能力。
- 我们可以编写Handler处理类来进行未捕获异常处理。
五. AMS如何承接应用的异常信息上报
1.handleApplicationCrash
在KillApplicationHandler类中的uncaughtException方法，可以看到ActivityManager.getServie().handleApplicationCrash被调用
image.png
2.handleApplicationCrash
![]()
image.png
image.png
如果app为null,processName就设置为system_server,意思是如果没有来源，默认判断是系统进程自己。
3.handleApplicationCrashInner
进行系统日志输出，具体处理在addErrorToDropBox
image.png
4.addErrorToDropBox
无论是crash,native_crash,ANR或是WTF，最终都是来到这里。
六. 对于native crash系统如何做的处理
native_crash的崩溃处理，是有AMS提供一个NativeCrashListener线程监听对应的文件数据
1.起始路径
SystemServer.run --> startOtherServices --> AMS.startObservingNativeCrashes
image.png
2.NativeCrashListener
![]()
image.png
image.png
-
通信机制建立image.png
File socketFile = new File(DEBUGGERD_SOCKET_PATH);//建立一个信号机制通信点。
UnixSocketAddress socketAddr = UnixSocketAddress.createFileSystem(DEBUGGERD_SOCKET_PATH)；//建立通信管道 -
接收数据image.png
peerFd = Os.accept(serverFd, null);//触发异常信息
-
处理数据
consumeNativeCrashData(peerFd);
image.png -
封装数据，提交AMS处理
将数据封装成字符串提交给NativeCrashReporter处理
image.png
将数据封装后提交AMS处理。其实都是交给handleApplicationCrashInner函数，只不过类型不一样而已，也就是最终数据都是通过AMS的addErrorToDropBix函数进行具体处理image.png
七. 系统如何处理ANR异常数据
1.AnrHelper.appnotResonding
将对应的数据封装成一个ANR信息包加入到一个列表中然后爱妻一个线程进行具体处理
image.png
2.startAnrConsumerIfNeeded
![]()
image.png
![]()
image.png
image.png
image.png
3.AnrConsumerThread
在当前信息包中回调了AnrRecord.appNotResponding
image.png
AnrRecord中又会回调到ProcressRecord
image.png
4.ProcressRecord.appNotResponding
- 记录ANR数据到SLOG(framework日志体系中)
- 记录ANR数据到LOG(主日志体系中)
- dump具体数据到指定文件中
-
调用AMS.addErrorDropBox上报信息image.png
八. addErrorToDropBox
总结：不管是crash,native_crash,ANR或是WTF，最终都是来自AMS.addErrorToDropBox，交由它去处理。
1.添加头信息
![]()
image.png
image.png
2.读取对应异常数据并拼装成字符数据
![]()
image.png
image.png
3.交给DropBoxManager进行录入
![]()
image.png
![]()
image.png
image.png
image.png
九. DropBoxManager
文件输入写入
image.png
