1.Crash是什么？
Crash，即闪退，多指在移动设备(如IOS、Android设备)中，在打开应用程序时出现突然退出中断的情况(类似于Windows的应用程序崩溃)。
2.什么引起Crash？
异常可以简单分为Checked异常及Unchecked异常，那么这两种异常的区别是什么呢？其中派生于Error或者RuntimeException异常称为Unchecked异常，所有其他的Exception称为Checked异常。
那么为什么要这样区分他们呢？因为Java compiler(编译器)强制要求所有的Exception要么被catch，要么被throw对其进行处理，否则编译会不通过，除非这是一个RuntimeException(e instanceof RuntimeException)。也就是说，通常的Exception一定要被处理，也即我们所说的Checked Exception，而RuntimeException/Error，编译器是不强制要求处理的，所以被称为UnChecked exception。
RuntimeException(运行时异常)，它属于Unchecked异常。如果出现RuntimeException，那么一定是程序员代码的问题，编译器并不会检查Unchecked异常。在开发过程中，我们遇到的crash绝大多数都属于RuntimeException(RuntimeException是引起Crash主要原因)；
3.异常分类分哪些种？
Java层
?从上图可以看出，他们都是从Throwable继承而来的，Throwable下层分为两个子类：Error和Exception。
3.1关于Error和Exception
其中Error类描述了Java运行时系统的内部错误或设备资源耗尽的错误。?这种错误一般没有别的解决办法，它用于报告给开发者程序无法恢复的异常情况。对于所有Error类型以及其子类都不要求程序进行处理，常见如栈溢出StackOverflowError等。
而Exception类则是值程序有可能恢复的异常情况，Exception包含了运行时异常(Runtime Exception)和受检查的异常(Checked Exception)；
3.2关于Checked和Unchecked异常
上面一小节提到了Checked异常及Unchecked异常，那么这种异常的区别是什么呢？其中派生于Error或者RuntimeException的异常称为Unchecked异常，所有其他的Exception称为Checked异常。在上图所示中，浅蓝色方框所标注的为Unchecked异常。
那么为什么要这样区分他们呢？因为Java compiler(编译器)强制要求所有的Exception要么被catch，要么被throw对其进行处理，否则编译会不通过，除非这是一个RuntimeException(e instanceof RuntimeException)。也就是说，通常的Exception一定要被处理，也即我们所说的Checked Exception，而RuntimeException/Error，编译器是不强制要求处理的，所以被称为UnChecked exception。
3.3关于RuntimeException
Oracle 官网解释：
RuntimeException and its subclasses are unchecked exceptions. Unchecked exceptions do not need to be declared in a method or constructor’s throws clause if they can be thrown by the execution of the method or constructor and propagate outside the method or constructor boundary.
RuntimeException(运行时异常)，它属于Unchecked异常。如果出现RuntimeException，那么一定是程序员代码的问题，编译器并不会检查Unchecked异常。在开发过程中，我们遇到的crash绝大多数都属于RuntimeException(RuntimeException是引起Crash主要原因)；
4.Crash崩溃率的统计
影响用户体验因素：
App的应用性能稳定是良好用户体验中非常关键的一环，而现实情况却是应用崩溃、卡顿、加载缓慢、页面白屏等问题，频频出现在用户的真实体验之中，成为影响业务表现的直接杀手。为此，应用性能管理（APM）正在国内外蓬勃发展，被越来越多的企业所认可。
友盟崩溃率统计：
友盟+U-APM数据白皮书显示：APP 整体崩溃率为0.293%，其中Android 端崩溃率为0.32%， iOS 端崩溃率为0.1%，头部移动应用在治理崩溃表现方面表现更为优异，更加注重在应用质量治理方面的精细打磨。
参考：
移动应用性能体验报告-Android崩溃率达0.32%，OV、华为表现良好
5.线程如何处理一个未捕获异常导致的线程中断
5.1Thread定义了UncaughtExceptionHandler异常处理器接口
public interface UncaughtExceptionHandler {
void uncaughtException(Thread t, Throwable e);
}5.2Thread定义两个UncaughtExceptionHandler成员变量
//成员变量，线程独有的
// null unless explicitly set
private volatile UncaughtExceptionHandler uncaughtExceptionHandler;
//静态变量用于所有线程
// null unless explicitly set
private static volatile UncaughtExceptionHandler defaultUncaughtExceptionHandler;Thread中存在两个UncaughtExceptionHandler成员变量:
1)一个是静态的defaultUncaughtExceptionHandler：来自所有线程中的Exception在抛出并且未捕获的情况下，都会从此路过。进程fork的时候设置的就是这个静态defaultUncaughtExceptionHandler，管辖范围为整个进程。
2)另一个非静态uncaughtExceptionHandler：为单个线程设置一个属于线程自己的uncaughtExceptionHandler，管辖范围比较小。
当一个线程由于未捕获异常即将终止时，Java虚拟机将使用Thread的getDefaultUncaughtExceptionHandler()方法查询线程unCaughtException处理程序，并调用处理程序的uncaughtException方法，将线程和异常作为参数传递。一个线程如果没有设置uncaughtExceptionHandler，将使用线程所在的线程组来处理这个未捕获异常。线程组ThreadGroup实现UncaughtExceptionHandler，所以可以用来处理未捕获的异常。
ThreadGroup实现uncaughtException如下：
public void uncaughtException(Thread t, Throwable e) {
if (parent != null) {
parent.uncaughtException(t, e);
} else {
Thread.UncaughtExceptionHandler ueh =
Thread.getDefaultUncaughtExceptionHandler();
if (ueh != null) {
ueh.uncaughtException(t, e);
} else if (!(e instanceof ThreadDeath)) {
System.err.print("Exception in thread \""
+ t.getName() + "\" ");
e.printStackTrace(System.err);
}
}
}1)首先将异常消息通知给父线程组处理；
2)否则，尝试利用一个默认的defaultUncaughtExceptionHandler来处理异常；
3)如果没有默认的异常处理则将错误信息输出到System.err。
6.Android如何自定义添加全局接收Crash异常错误信息
在Android中，我们同样可以使用UncaughtExceptionHandler来添加运行时异常的回调，来监控Crash发生；
6.1创建一个自定义UncaughtExceptionHandler类
//实现UncaughtExceptionHandler接口
public class CrashHandler implements Thread.UncaughtExceptionHandler {
private static CrashHandler mAppCrashHandler;
//系统默认的处理器
private Thread.UncaughtExceptionHandler mDefaultHandler;
private CrashHandler(){}
public void initCrashHandler() {
// 获取系统默认的UncaughtException处理器
mDefaultHandler = Thread.getDefaultUncaughtExceptionHandler();
//设置系统
Thread.setDefaultUncaughtExceptionHandler(this);
}
public static CrashHandler getInstance() {
if (mAppCrashHandler == null) {
mAppCrashHandler = new CrashHandler();
}
return mAppCrashHandler;
}
@Override
public void uncaughtException(Thread thread, Throwable ex) {
// 回调函数，处理异常
// 在这里将崩溃日志读取出来，然后保存到SD卡，或者直接上传到日志服务器
// 注意 保存或者上传到日志服务器需要将系统版本，手机唯一标识等系统信息和崩溃信息一同上传，方便分析crash问题
// 如果用户没有处理则让系统默认的异常处理器来处理
}
}
6.2在Application子类内设置全局监控
CrashHandler.getInstance().initCrashHandler()完成以上2个步骤，我们就可以实现全局Crash监控了。这是所说的全局，是针对整个进程生效；
7.Android系统中Crash如何处理、分发逻辑
上面我们了解了怎么在Android中补货Crash，实现Crash的监控，上报。那么Android中系统是如何处理、分发Crash的呢？
7.1异常处理的注册
APP启动时，会通过zygote进程fork一个进程，然后创建VM虚拟机，然后会调用到zygoteInit进行初始化工作。
zygoteInit方法
frameworks/base/core/java/com/android/internal/os/ZygoteInit.java的zygoteInit方法：
public static final Runnable zygoteInit(int targetSdkVersion, long[] disabledCompatChanges,
String[] argv, ClassLoader classLoader) {
...
RuntimeInit.commonInit();
...
}zygoteInit方法主要被zygote进程调用，zygoteInit调用了RuntimeInit.commonInit()方法；
RuntimeInit.commonInit()方法
protected static final void commonInit() {
if (DEBUG) Slog.d(TAG, "Entered RuntimeInit!");
/*
* set handlers; these apply to all threads in the VM. Apps can replace
* the default handler, but not the pre handler.
*/
LoggingHandler loggingHandler = new LoggingHandler();
RuntimeHooks.setUncaughtExceptionPreHandler(loggingHandler);
Thread.setDefaultUncaughtExceptionHandler(new KillApplicationHandler(loggingHandler));
...
}逻辑分析：
1)LoggingHandler主要处理打印日志，打印一个线程遇到的未捕获的异常信息；
2)Thead.setDefaultUncaughtExceptionHandler()用于注册系统默认异常处理的逻辑；
这里的RuntimeHooks.setUncaughtExceptionPreHandler()方法，其实是调用了Thread的setUncaughtExceptionPreHandler()方法；
Android 8.0中，Thread类增加了一个接口叫setUncaughtExceptionPreHandler，它会注册在分发异常处理时的回调，用于Android系统(平台)使用；
我们先来看异常的分发逻辑，后面再分析KillApplicationHandler中对异常的处理逻辑；
异常的分发
Thread的dispatchUncaughtException负责处理异常的分发逻辑；
Thread的dispatchUncaughtException
public final void dispatchUncaughtException(Throwable e) {
// BEGIN Android-added: uncaughtExceptionPreHandler for use by platform.
Thread.UncaughtExceptionHandler initialUeh =
Thread.getUncaughtExceptionPreHandler();
if (initialUeh != null) {
try {
initialUeh.uncaughtException(this, e);
} catch (RuntimeException | Error ignored) {
// Throwables thrown by the initial handler are ignored
}
}
// END Android-added: uncaughtExceptionPreHandler for use by platform.
getUncaughtExceptionHandler().uncaughtException(this, e);
}这里首先处理setUncaughtExceptionHandler注册的异常处理方法，然后调用通过setDefaultUncaughtExceptionHandler或者setUncaughtExceptionHandler方法注册的异常处理方法；
我们来看getUncaughtExceptionHandler()方法的返回值；
Thread的getUncaughtExceptionHandler()方法
public UncaughtExceptionHandler getUncaughtExceptionHandler() {
return uncaughtExceptionHandler != null ?
uncaughtExceptionHandler : group;
}逻辑分析：
1)当uncaughtExceptionHandler不为空时，返回uncaughtExceptionHandler；
uncaughtExceptionHandler是通过setUncaughtExceptionHandler方法注册异常处理Handler；
2)否则，返回group
3)这里的group，其实就是当前线程所在的线程组；并且线程组ThreadGroup同样实现了UncaughtExceptionHandler接口；
TheadGroup的uncaughtException
在本文第一部分，我们其实已经介绍了，这里来回顾一下：
public void uncaughtException(Thread t, Throwable e) {
if (parent != null) {
parent.uncaughtException(t, e);
} else {
Thread.UncaughtExceptionHandler ueh =
Thread.getDefaultUncaughtExceptionHandler();
if (ueh != null) {
ueh.uncaughtException(t, e);
} else if (!(e instanceof ThreadDeath)) {
System.err.print("Exception in thread \""
+ t.getName() + "\" ");
e.printStackTrace(System.err);
}
}
}逻辑分析：
1)首先将异常消息通知给父线程组处理；
2)否则，尝试利用一个默认的defaultUncaughtExceptionHandler来处理异常；
3)如果没有默认的异常处理则将错误信息输出到System.err；
7.2异常的处理
系统默认异常处理逻辑在KillApplicationHandler类的uncaughtException方法中，我们来看代码；
KillApplicationHandler类的uncaughtException方法
@Override
public void uncaughtException(Thread t, Throwable e) {
try {
//确保LoggingHandler
ensureLogging(t, e);
// Don't re-enter -- avoid infinite loops if crash-reporting crashes.
if (mCrashing) return;
mCrashing = true;
// Try to end profiling. If a profiler is running at this point, and we kill the
// process (below), the in-memory buffer will be lost. So try to stop, which will
// flush the buffer. (This makes method trace profiling useful to debug crashes.)
if (ActivityThread.currentActivityThread() != null) {
ActivityThread.currentActivityThread().stopProfiling();
}
//调用AMS，展示弹框等逻辑
// Bring up crash dialog, wait for it to be dismissed
ActivityManager.getService().handleApplicationCrash(
mApplicationObject, new ApplicationErrorReport.ParcelableCrashInfo(e));
} catch (Throwable t2) {
if (t2 instanceof DeadObjectException) {
// System process is dead; ignore
} else {
try {
Clog_e(TAG, "Error reporting crash", t2);
} catch (Throwable t3) {
// Even Clog_e() fails! Oh well.
}
}
} finally {
//杀死进程，退出虚拟机
// Try everything to make sure this process goes away.
Process.killProcess(Process.myPid());
System.exit(10);
}
}逻辑分析：
1)调用ensureLogging(t,e)确保LoggingHandler的执行(有去重逻辑，不用担心重复执行)；
2)然后调用了ActivityManager.getService().handleApplicationCrash()方法来进行处理；
3)最后调用Process.killProcess(Process.myPid())来杀死进程，并且退出VM；
AMS的handleApplicationCrash方法
我们继续来看ActivityManagerService的handleApplicationCrash方法：
位置：/frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java
public void handleApplicationCrash(IBinder app,
ApplicationErrorReport.ParcelableCrashInfo crashInfo) {
ProcessRecord r = findAppProcess(app, "Crash");
final String processName = app == null ? "system_server"
: (r == null ? "unknown" : r.processName);
handleApplicationCrashInner("crash", r, processName, crashInfo);
}这里通过Application的binder，取得进程的ProcessRecord对象，然后调用handleApplicationCrashInner方法；
AMS的handleApplicationCrashInner方法
void handleApplicationCrashInner(String eventType, ProcessRecord r, String processName,
ApplicationErrorReport.CrashInfo crashInfo) {
//处理一些错误日志的相关逻辑
//调用
mAppErrors.crashApplication(r, crashInfo);
}这里处理一些错误日志的相关逻辑，然后调用AppErrors的crashApplication方法。
AppErrors的crashApplication方法
/frameworks/base/services/core/java/com/android/server/am/AppErrors.java
void crashApplication(ProcessRecord r, ApplicationErrorReport.CrashInfo crashInfo) {
final int callingPid = Binder.getCallingPid();
final int callingUid = Binder.getCallingUid();
final long origId = Binder.clearCallingIdentity();
try {
crashApplicationInner(r, crashInfo, callingPid, callingUid);
} finally {
Binder.restoreCallingIdentity(origId);
}
}crashApplication调用crashApplicationInner方法，处理系统的crash弹框等逻辑，这里我们就不再详细分析了，感兴趣的可以看源代码了解一下；
到这里，关于系统默认的异常捕获及处理逻辑我们也就分析完成了。
8.Crash优化建议
Crash是APP性能的一个非常重要的指标，我们要尽可能的减少Crash，增加APP的稳定性，一下是几点实际经验：
1)要有可靠的Crash日志收集方式：可以自己实现，也可以集成第三方SDK来采集分析；
2)当一个Crash发生了，我们不但需要针性的解决这一个Crash，而且要考虑这一类Crash怎么去解决和预防，只有这样才能使得该类Crash真正的解决，而不是反复出现。
3)不能随意的使用try-catch，这样只会隐蔽真正的问题，要从根本上了解Crash的原因，根据原因去解决。
4)增加代码检测，预防常规可检测的代码问题的产生，预防胜于治理。
9.总结?
1)Java异常可分为：可查的异常（checked exceptions）和不可查的异常（unchecked exceptions）。
2)Java中，可以通过设置Thread类的uncaughtExceptionHandler属性或静态属性defaultUncaughtExceptionHandler来设置不可查异常的回调处理。
3)在Android中，运行时异常（属于不可查的异常），如果没有在try-catch语句捕获并处理，就会产生Crash，导致程序崩溃。
4)在Android中，我们同样可以使用UncaughtExceptionHandler来添加运行时异常的回调，来监控Crash的发生。
5)通过Thread的静态方法setDefaultUncaughtExceptionHandler方法，可以注册全局的默认Crash监控。通过Thread的setUncaughtExceptionHandler方法来注册某个线程的异常监控。
6)setDefaultUncaughtExceptionHandler方法和setUncaughtExceptionHandler方法有注册顺序的问题，多次注册后，只有最后一次生效。
7)Android系统中，默认的Crash处理Handler，是在进程创建时，通过RuntimeInit.commonInit()方法进行注册的。
8)Android 8.0中，Thread类增加了一个接口叫setUncaughtExceptionPreHandler，它会注册在分发异常处理时的回调，用于Android系统（平台）使用。
9)Thread的dispatchUncaughtException负责处理异常的分发逻辑。
10)Android中，异常分发顺序为：
????????a.首先处理setUncaughtExceptionPreHandler注册的异常处理方法；
? ? ? ? b.然后处理线程私有的（uncaughtExceptionHandler）Handler异常处理方法；
? ? ? ? c.如果私有Handler不存在，则处理ThreadGroup的Handler异常处理方法；
????????d.ThreadGroup中，优先调用父线程组的处理逻辑，否则，调用通过setUncaughtExceptionHandler方法注册异常处理Handler。
11)系统默认异常处理逻辑在KillApplicationHandler类的uncaughtException方法中，系统默认Crash弹框等逻辑是通过AMS的handleApplicationCrash方法执行的。
Crash是App性能的一个非常重要的指标，我们要尽可能的减少Crash，增加App的稳定性。
4.1Crash解决思路
4.2Crash解决实例
参考：