本文为稀土技能社区首发签约文章，14天内制止转载，14天后未获授权制止转载，侵权必究！
布景
crash一向是影响app稳定性的大头，一起在随着项目逐渐迭代，复杂性越来越进步的一起，由于主观或许客观的的原因，都会造成意想不到的crash出现。同样的，在android的历史化过程中，就算是android体系本身，在迭代中也会存在着隐含的crash。咱们常说的crash包括java层（虚拟机层）crash与native层crash，本期咱们着重讲一下java层的crash。
java层crash由来
尽管说咱们在开发过程中会遇到各种各样的crash，可是这个crash是如果发生的呢？咱们来讨论一下一个crash是怎样诞生的！
咱们很简单就知道，在java中main函数是程序的开端（其实还有前置步骤），咱们开发中，尽管android体系把应用的主线程创立封装在了自己的体系中，可是不管怎样封装，一个java层的线程不管再怎样强大，背后肯定是绑定了一个操作体系等级的线程，才真实得与驱动，也便是说，咱们往常说的java线程，它其实是被操作体系真实的Thread的一个运用体算了，java层的多个thread，或许会只对应着native层的一个Thread（便于区别，这儿thread统一只java层的线程，Thread指的是native层的Thread。其实native的Thread也不是真实的线程，只是操作体系供给的一个api算了，可是咱们这儿先简单这样定义，假设了native的线程与操作体系线程为同一个东西）
每一个java层的thread调用start办法，就会来到native层Thread的国际
public synchronized void start() {
throw new IllegalThreadStateException();
group.add(this);
started = false;
try {
nativeCreate(this, stackSize, daemon);
started = true;
} finally {
try {
if (!started) {
group.threadStartFailed(this);
}
} catch (Throwable ignore) {
/* do nothing. If start0 threw a Throwable then
it will be passed up the call stack */
}
}
}
终究调用的是一个jni办法
private native static void nativeCreate(Thread t, long stackSize, boolean daemon);
而nativeCreate终究在native层的实现是
static void Thread_nativeCreate(JNIEnv* env, jclass, jobject java_thread, jlong stack_size,
jboolean daemon) {
// There are sections in the zygote that forbid thread creation.
Runtime* runtime = Runtime::Current();
if (runtime->IsZygote() && runtime->IsZygoteNoThreadSection()) {
jclass internal_error = env->FindClass("java/lang/InternalError");
CHECK(internal_error != nullptr);
env->ThrowNew(internal_error, "Cannot create threads in zygote");
return;
}
// 这儿便是真实的创立线程办法
Thread::CreateNativeThread(env, java_thread, stack_size, daemon == JNI_TRUE);
}
CreateNativeThread 经过了一系列的校验动作，终于到了真实创立线程的地方了，终究在CreateNativeThread办法中，经过了pthread_create创立了一个真实的Thread
Thread::CreateNativeThread 办法中
...
pthread_create_result = pthread_create(&new_pthread,
&attr,
Thread::CreateCallback,
child_thread);
CHECK_PTHREAD_CALL(pthread_attr_destroy, (&attr), "new thread");
if (pthread_create_result == 0) {
// pthread_create started the new thread. The child is now responsible for managing the
// JNIEnvExt we created.
// Note: we can't check for tmp_jni_env == nullptr, as that would require synchronization
// between the threads.
child_jni_env_ext.release(); // NOLINT pthreads API.
return;
}
...
到这儿咱们就能够明白，一个java层的thread其实真实绑定的，是一个native层的Thread，有了这个知识，咱们就能够回到咱们的crash主题了，当发生反常的时候（即检测到一些操作不符合虚拟机规定时），注意，这个时候仍是在虚拟机的控制范围之内，就能够直接调用
void Thread::ThrowNewException(const char* exception_class_descriptor,
const char* msg) {
// Callers should either clear or call ThrowNewWrappedException.
AssertNoPendingExceptionForNewException(msg);
ThrowNewWrappedException(exception_class_descriptor, msg);
}
进行对exception的抛出，咱们目前所有的java层crash都是如此，由于对crash的辨认还属于本虚拟机所在的进程的领域（native crash 虚拟机就没办法直接辨认），比方咱们常见的各种crash
然后就会调用到Thread::ThrowNewWrappedException 办法，在这个办法里边再次调用到Thread::SetException办法，成功的把当次引发反常的信息记录下来
void Thread::SetException(ObjPtr<mirror::Throwable> new_exception) {
CHECK(new_exception != nullptr);
// TODO: DCHECK(!IsExceptionPending());
tlsPtr_.exception = new_exception.Ptr();
}
此刻，此刻就会调用Thread的Destroy办法，这个时候，线程就会在里边判断，本次的反常该怎样去向理
void Thread::Destroy() {
...
if (tlsPtr_.opeer != nullptr) {
ScopedObjectAccess soa(self);
// We may need to call user-supplied managed code, do this before final clean-up.
HandleUncaughtExceptions(soa);
RemoveFromThreadGroup(soa);
Runtime* runtime = Runtime::Current();
if (runtime != nullptr) {
runtime->GetRuntimeCallbacks()->ThreadDeath(self);
}
HandleUncaughtExceptions 这个方法便是处理的函数，咱们继续看一下这个反常处理函数
void Thread::HandleUncaughtExceptions(ScopedObjectAccessAlreadyRunnable& soa) {
if (!IsExceptionPending()) {
return;
}
ScopedLocalRef<jobject> peer(tlsPtr_.jni_env, soa.AddLocalReference<jobject>(tlsPtr_.opeer));
ScopedThreadStateChange tsc(this, ThreadState::kNative);
// Get and clear the exception.
ScopedLocalRef<jthrowable> exception(tlsPtr_.jni_env, tlsPtr_.jni_env->ExceptionOccurred());
tlsPtr_.jni_env->ExceptionClear();
// Call the Thread instance's dispatchUncaughtException(Throwable)
// 要害点就在此，回到java层
tlsPtr_.jni_env->CallVoidMethod(peer.get(),
WellKnownClasses::java_lang_Thread_dispatchUncaughtException,
exception.get());
// If the dispatchUncaughtException threw, clear that exception too.
tlsPtr_.jni_env->ExceptionClear();
}
到这儿，咱们就接近尾声了，能够看到咱们的处理函数终究经过jni，再次回到了java层的国际，而这个连接的java层函数便是dispatchUncaughtException（java_lang_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);
}
到这儿，咱们就完全了解到了一个java层反常的发生过程！
为什么java层反常会导致crash
从上面咱们文章咱们能够看到，一个反常是怎样发生的，或许仔细的读者会了解到，笔者一向在用反常这个词，而不是crash，由于反常发生了，crash是不一定发生的！咱们能够看到dispatchUncaughtException办法终究会尝试着调用UncaughtExceptionHandler去向理本次反常，好家伙！那么UncaughtExceptionHandler是在什么时候设置的？其实便是在Init中，由体系提早设置好的！frameworks/base/core/java/com/android/internal/os/RuntimeInit.java
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));
/*
* Install a time zone supplier that uses the Android persistent time zone system property.
*/
RuntimeHooks.setTimeZoneIdSupplier(() -> SystemProperties.get("persist.sys.timezone"));
LogManager.getLogManager().reset();
new AndroidConfig();
/*
* Sets the default HTTP User-Agent used by HttpURLConnection.
*/
String userAgent = getDefaultUserAgent();
System.setProperty("http.agent", userAgent);
/*
* Wire socket tagging to traffic stats.
*/
TrafficStats.attachSocketTagger();
initialized = true;
}
好家伙，原来是KillApplicationHandler“捣蛋”，在反常到来时，就会经过KillApplicationHandler去向理，而这儿的处理便是，杀死app！！
private static class KillApplicationHandler implements Thread.UncaughtExceptionHandler {
private final LoggingHandler mLoggingHandler;
public KillApplicationHandler(LoggingHandler loggingHandler) {
this.mLoggingHandler = Objects.requireNonNull(loggingHandler);
}
@Override
public void uncaughtException(Thread t, Throwable e) {
try {
ensureLogging(t, e);
// Don't re-enter -- avoid infinite loops if crash-reporting crashes.
if (mCrashing) return;
mCrashing = true;
if (ActivityThread.currentActivityThread() != null) {
ActivityThread.currentActivityThread().stopProfiling();
}
// 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);
}
}
private void ensureLogging(Thread t, Throwable e) {
if (!mLoggingHandler.mTriggered) {
try {
mLoggingHandler.uncaughtException(t, e);
} catch (Throwable loggingThrowable) {
// Ignored.
}
}
}
}
看到了吗！反常的发生导致的crash，真实的源头便是在此了！
捕获crash
经过对前文的阅读，咱们了解到了crash的源头便是KillApplicationHandler，由于它默认处理便是杀死app，此刻咱们也注意到，它是继承于UncaughtExceptionHandler的。当然，有反常及时抛出解决，是一件功德，可是咱们也或许有一些反常，比方android体系sdk的问题，或许其他没那么重要的反常，直接崩溃app，这个处理就不是那么好了。可是没关系，java虚拟机开发者也肯定注意到了这点，所以供给
Thread.java
public static void setDefaultUncaughtExceptionHandler(UncaughtExceptionHandler eh)
方法，导入一个咱们自定义的实现了UncaughtExceptionHandler接口的类
public interface UncaughtExceptionHandler {
/**
* Method invoked when the given thread terminates due to the
* given uncaught exception.
* <p>Any exception thrown by this method will be ignored by the
* Java Virtual Machine.
* @param t the thread
* @param e the exception
*/
void uncaughtException(Thread t, Throwable e);
}
此刻咱们只需要写一个类，仿照KillApplicationHandler相同，就能写出一个自己的反常处理类，去向理咱们程序中的反常（或许Android体系中特定版本的反常）。比如demo比方
class MyExceptionHandler:Thread.UncaughtExceptionHandler {
override fun uncaughtException(t: Thread, e: Throwable) {
// 做自己的逻辑
Log.i("hello",e.toString())
}
}
总结
到这儿，咱们能够了解到了一个java crash是怎样发生的了，一起咱们也了解到了常用的UncaughtExceptionHandler为什么能够拦截一些咱们不期望发生crash的反常，在接下来的android功能优化系列中，会继续带来相关的其他分享，感谢观看
