android 异常开发者最头疼的地方，了解异常的处理机制对我们开发来说常有帮助。系统在app应用进程运行的时候设置一个异常处理类：
···
/* set default handler; this applies to all threads in the VM */
Thread.setDefaultUncaughtExceptionHandler(new UncaughtHandler());
···
UncaughtHandler异常处理类是RuntimeInit.java 内部类；是系统默认处理异常类。所以Android系统默认的异常信息都会被这里的UncaughtHandler所捕获并被其uncaughtException方法回调，所以若我们不重写Thread.setDefaultUncaughtExceptionHandler方法，那么这里的UncaughtHandler就是我们默认的异常处理操作 这样我们看一下UncaughtHandler的具体实现：
···
private static class UncaughtHandler implements Thread.UncaughtExceptionHandler {
public void uncaughtException(Thread t, Throwable e) {
try {
// Don’t re-enter — avoid infinite loops if crash-reporting crashes.
if (mCrashing) return;
mCrashing = true;
if (mApplicationObject == null) {
Clog_e(TAG, “*** FATAL EXCEPTION IN SYSTEM PROCESS: ” + t.getName(), e);
} else {
StringBuilder message = new StringBuilder();
message.append(“FATAL EXCEPTION: “).append(t.getName()).append(“\n”);
final String processName = ActivityThread.currentProcessName();
if (processName != null) {
message.append(“Process: “).append(processName).append(“, “);
}
message.append(“PID: “).append(Process.myPid());
Clog_e(TAG, message.toString(), e);
}
// Bring up crash dialog, wait for it to be dismissed
ActivityManagerNative.getDefault().handleApplicationCrash(
mApplicationObject, new ApplicationErrorReport.CrashInfo(e));
} catch (Throwable t2) {
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);
}
}
}
···
这里uncaughtException方法最终会被执行异常信息的处理，我们看一下在这里我们调用了ActivityManagerNative.getDefault().handleApplicationCrash方法，看过我们前面Activity启动流程的童鞋应该知道这里的ActivityManagerNative其实是ActivityManagerService的Binder客户端，而这里的handleApplicationCrash方法最终会调用的是ActivityManagerService的handleApplicationCrash方法。最后在finally分之中，我们调用了Process.killProcess(Process.myPid)和System.exit(10)，这样我们的应用进程就会退出了。然后我们在这里先简单的分析一下Binder的数据传输过程，看一下handleApplicationCrash方法具体做了哪些事，首先看一下ActivityManagerNative的getDefault方法是如何实现的？
···
static public IActivityManager getDefault() {
return gDefault.get();
}
···
可以发现，其是一个静态方法，并执行了gDefault.get方法，我们在看一下gDefault.get方法的实现逻辑：
···
private static final Singleton<IActivityManager> gDefault = new Singleton<IActivityManager>() {
protected IActivityManager create() {
IBinder b = ServiceManager.getService(“activity”);
if (false) {
Log.v(“ActivityManager”, “default service binder = ” + b);
}
IActivityManager am = asInterface(b);
if (false) {
Log.v(“ActivityManager”, “default service = ” + am);
}
return am;
}
};
···
可以发现这里返回一个IActivityManager类型的am对象，而这个am对象是通过调用asInterface方法创建的，我们再来看一下这个asInterface方法的实现逻辑。
···
static public IActivityManager asInterface(IBinder obj) {
if (obj == null) {
return null;
}
IActivityManager in =
(IActivityManager)obj.queryLocalInterface(descriptor);
if (in != null) {
return in;
}
return new ActivityManagerProxy(obj);
}
···
可以发现该方法最终返回的是一个ActivityManagerProxy对象，所以ActivityManagerNative.getDefault()方法最终返回的是一个ActivityManagerProxy对象，我们再来看一下ActivityManagerProxy的handleApplicationCrash方法。
···
public void handleApplicationCrash(IBinder app,
ApplicationErrorReport.CrashInfo crashInfo) throws RemoteException
{
Parcel data = Parcel.obtain();
Parcel reply = Parcel.obtain();
data.writeInterfaceToken(IActivityManager.descriptor);
data.writeStrongBinder(app);
crashInfo.writeToParcel(data, 0);
mRemote.transact(HANDLE_APPLICATION_CRASH_TRANSACTION, data, reply, 0);
reply.readException();
reply.recycle();
data.recycle();
}
···
这里就是具体的Binder传输数据的逻辑了，这里ActivityManagerNative最为Binder的clent端，而我们的ActivityManagerService同样是继承与ActivityManagerNative，最为Binder的server端，通过传输最终ActivityManagerService的handleApplicationCrash方法会被执行。
···
public void handleApplicationCrash(IBinder app, ApplicationErrorReport.CrashInfo crashInfo) {
ProcessRecord r = findAppProcess(app, “Crash”);
final String processName = app == null ? “system_server”
: (r == null ? “unknown” : r.processName);
handleApplicationCrashInner(“crash”, r, processName, crashInfo);
}
···
可以看到在ActivityManagerService的handleApplicationCrash方法中我们调用了handleApplicationCreashInner方法，这样我们继续看一下handleApplicationCrashInner方法的实现。
···
void handleApplicationCrashInner(String eventType, ProcessRecord r, String processName,
ApplicationErrorReport.CrashInfo crashInfo) {
EventLog.writeEvent(EventLogTags.AM_CRASH, Binder.getCallingPid(),
UserHandle.getUserId(Binder.getCallingUid()), processName,
r == null ? -1 : r.info.flags,
crashInfo.exceptionClassName,
crashInfo.exceptionMessage,
crashInfo.throwFileName,
crashInfo.throwLineNumber);
addErrorToDropBox(eventType, r, processName, null, null, null, null, null, crashInfo);
crashApplication(r, crashInfo);
}
···
可以发现在handleApplicationCrashInner方法中主要调用了两个方法addErrorToDropBox和crashApplication，我们首先看一下addErrorToDropBox方法的实现逻辑。
···
public void addErrorToDropBox(String eventType,
ProcessRecord process, String processName, ActivityRecord activity,
ActivityRecord parent, String subject,
final String report, final File logFile,
final ApplicationErrorReport.CrashInfo crashInfo) {
// NOTE — this must never acquire the ActivityManagerService lock,
// otherwise the watchdog may be prevented from resetting the system.
final String dropboxTag = processClass(process) + “_” + eventType;
final DropBoxManager dbox = (DropBoxManager)
mContext.getSystemService(Context.DROPBOX_SERVICE);
// Exit early if the dropbox isn’t configured to accept this report type.
if (dbox == null || !dbox.isTagEnabled(dropboxTag)) return;
final StringBuilder sb = new StringBuilder(1024);
appendDropBoxProcessHeaders(process, processName, sb);
if (activity != null) {
sb.append(“Activity: “).append(activity.shortComponentName).append(“\n”);
}
if (parent != null && parent.app != null && parent.app.pid != process.pid) {
sb.append(“Parent-Process: “).append(parent.app.processName).append(“\n”);
}
if (parent != null && parent != activity) {
sb.append(“Parent-Activity: “).append(parent.shortComponentName).append(“\n”);
}
if (subject != null) {
sb.append(“Subject: “).append(subject).append(“\n”);
}
sb.append(“Build: “).append(Build.FINGERPRINT).append(“\n”);
if (Debug.isDebuggerConnected()) {
sb.append(“Debugger: Connected\n”);
}
sb.append(“\n”);
// Do the rest in a worker thread to avoid blocking the caller on I/O
// (After this point, we shouldn’t access AMS internal data structures.)
Thread worker = new Thread(“Error dump: ” + dropboxTag) {
@Override
public void run() {
if (report != null) {
sb.append(report);
}
if (logFile != null) {
try {
sb.append(FileUtils.readTextFile(logFile, DROPBOX_MAX_SIZE,
“\n\n[[TRUNCATED]]”));
} catch (IOException e) {
Slog.e(TAG, “Error reading ” + logFile, e);
}
}
if (crashInfo != null && crashInfo.stackTrace != null) {
sb.append(crashInfo.stackTrace);
}
String setting = Settings.Global.ERROR_LOGCAT_PREFIX + dropboxTag;
int lines = Settings.Global.getInt(mContext.getContentResolver(), setting, 0);
if (lines > 0) {
sb.append(“\n”);
// Merge several logcat streams, and take the last N lines
InputStreamReader input = null;
try {
java.lang.Process logcat = new ProcessBuilder(“/system/bin/logcat”,
“-v”, “time”, “-b”, “events”, “-b”, “system”, “-b”, “main”,
“-b”, “crash”,
“-t”, String.valueOf(lines)).redirectErrorStream(true).start();
try { logcat.getOutputStream().close(); } catch (IOException e) {}
try { logcat.getErrorStream().close(); } catch (IOException e) {}
input = new InputStreamReader(logcat.getInputStream());
int num;
char[] buf = new char[8192];
while ((num = input.read(buf)) > 0) sb.append(buf, 0, num);
} catch (IOException e) {
Slog.e(TAG, “Error running logcat”, e);
} finally {
if (input != null) try { input.close(); } catch (IOException e) {}
}
}
dbox.addText(dropboxTag, sb.toString());
}
};
if (process == null) {
// If process is null, we are being called from some internal code
// and may be about to die — run this synchronously.
worker.run();
} else {
worker.start();
}
}
···
可以看到方法体很长，但是逻辑比较简单，在方法体最后通过判断应用进程是否为空（是否被销毁）来执行worker.run方法或者是worker.start方法，这里的worker是一个Thread对象，而在我们的worker对象的run方法中主要的执行逻辑就是将崩溃信息写入系统log中，所以addErrorToDropBox方法的主要执行逻辑就是讲App的崩溃信息写入系统log中。。。。继续回到我们的handleApplicationCrashInner方法中，看一下crashApplication方法是如何实现的。
···
private void crashApplication(ProcessRecord r, ApplicationErrorReport.CrashInfo crashInfo) {
long timeMillis = System.currentTimeMillis();
String shortMsg = crashInfo.exceptionClassName;
String longMsg = crashInfo.exceptionMessage;
String stackTrace = crashInfo.stackTrace;
if (shortMsg != null && longMsg != null) {
longMsg = shortMsg + “: ” + longMsg;
} else if (shortMsg != null) {
longMsg = shortMsg;
}
AppErrorResult result = new AppErrorResult();
synchronized (this) {
if (mController != null) {
try {
String name = r != null ? r.processName : null;
int pid = r != null ? r.pid : Binder.getCallingPid();
int uid = r != null ? r.info.uid : Binder.getCallingUid();
if (!mController.appCrashed(name, pid,
shortMsg, longMsg, timeMillis, crashInfo.stackTrace)) {
if (“1”.equals(SystemProperties.get(SYSTEM_DEBUGGABLE, “0”))
&& “Native crash”.equals(crashInfo.exceptionClassName)) {
Slog.w(TAG, “Skip killing native crashed app ” + name
+ “(” + pid + “) during testing”);
} else {
Slog.w(TAG, “Force-killing crashed app ” + name
+ ” at watcher’s request”);
if (r != null) {
r.kill(“crash”, true);
} else {
// Huh.
Process.killProcess(pid);
killProcessGroup(uid, pid);
}
}
return;
}
} catch (RemoteException e) {
mController = null;
Watchdog.getInstance().setActivityController(null);
}
}
final long origId = Binder.clearCallingIdentity();
// If this process is running instrumentation, finish it.
if (r != null && r.instrumentationClass != null) {
Slog.w(TAG, “Error in app ” + r.processName
+ ” running instrumentation ” + r.instrumentationClass + “:”);
if (shortMsg != null) Slog.w(TAG, ” ” + shortMsg);
if (longMsg != null) Slog.w(TAG, ” ” + longMsg);
Bundle info = new Bundle();
info.putString(“shortMsg”, shortMsg);
info.putString(“longMsg”, longMsg);
finishInstrumentationLocked(r, Activity.RESULT_CANCELED, info);
Binder.restoreCallingIdentity(origId);
return;
}
// Log crash in battery stats.
if (r != null) {
mBatteryStatsService.noteProcessCrash(r.processName, r.uid);
}
// If we can’t identify the process or it’s already exceeded its crash quota,
// quit right away without showing a crash dialog.
if (r == null || !makeAppCrashingLocked(r, shortMsg, longMsg, stackTrace)) {
Binder.restoreCallingIdentity(origId);
return;
}
Message msg = Message.obtain();
msg.what = SHOW_ERROR_MSG;
HashMap data = new HashMap();
data.put(“result”, result);
data.put(“app”, r);
msg.obj = data;
mUiHandler.sendMessage(msg);
Binder.restoreCallingIdentity(origId);
}
int res = result.get();
Intent appErrorIntent = null;
synchronized (this) {
if (r != null && !r.isolated) {
// XXX Can’t keep track of crash time for isolated processes,
// since they don’t have a persistent identity.
mProcessCrashTimes.put(r.info.processName, r.uid,
SystemClock.uptimeMillis());
}
if (res == AppErrorDialog.FORCE_QUIT_AND_REPORT) {
appErrorIntent = createAppErrorIntentLocked(r, timeMillis, crashInfo);
}
}
if (appErrorIntent != null) {
try {
mContext.startActivityAsUser(appErrorIntent, new UserHandle(r.userId));
} catch (ActivityNotFoundException e) {
Slog.w(TAG, “bug report receiver dissappeared”, e);
}
}
}
···
可以发现在方法体中我们调用了mUiHandler.sendMessage(msg)，其中mUiHandler是一个在主线程中创建的Handler对象，而这里的msg是一个what值为SHOW_ERROR_MSG的消息，这句话的本质就是向Ui线程中发送一个异步消息。我们来看一下mUiHander的处理逻辑。在mUiHandler的handeMessage方法中，根据what值得不同，执行了如下逻辑：
···
case SHOW_ERROR_MSG: {
HashMap<String, Object> data = (HashMap<String, Object>) msg.obj;
boolean showBackground = Settings.Secure.getInt(mContext.getContentResolver(),
Settings.Secure.ANR_SHOW_BACKGROUND, 0) != 0;
synchronized (ActivityManagerService.this) {
ProcessRecord proc = (ProcessRecord)data.get(“app”);
AppErrorResult res = (AppErrorResult) data.get(“result”);
if (proc != null && proc.crashDialog != null) {
Slog.e(TAG, “App already has crash dialog: ” + proc);
if (res != null) {
res.set(0);
}
return;
}
boolean isBackground = (UserHandle.getAppId(proc.uid)
>= Process.FIRST_APPLICATION_UID
&& proc.pid != MY_PID);
for (int userId : mCurrentProfileIds) {
isBackground &= (proc.userId != userId);
}
if (isBackground && !showBackground) {
Slog.w(TAG, “Skipping crash dialog of ” + proc + “: background”);
if (res != null) {
res.set(0);
}
return;
}
if (mShowDialogs && !mSleeping && !mShuttingDown) {
Dialog d = new AppErrorDialog(mContext,
ActivityManagerService.this, res, proc);
d.show();
proc.crashDialog = d;
} else {
// The device is asleep, so just pretend that the user
// saw a crash dialog and hit “force quit”.
if (res != null) {
res.set(0);
}
}
}
ensureBootCompleted();
}
···
可以看到在方法体中我们创建了一个AppErrorDialog对象，并执行了show方法，这样该Dialog就会被显示出来。而这里的Dialog的显示内容就是：App already has crash dialog: ….O(∩_∩)O哈哈~，原来我们App崩溃的时候弹出昂的异常提示框就是在这里弹出来的。这里对AppErrorDialog不做过多的介绍，在其的构造方法中，调用了如下的代码：
···
// After the timeout, pretend the user clicked the quit button
mHandler.sendMessageDelayed(
mHandler.obtainMessage(FORCE_QUIT),
DISMISS_TIMEOUT);
···
这里的常量DISMISS_TIME = 5 * 60 * 1000，也就是五分钟，相当于这里发送了一个延时异步消息五分钟之后取消崩溃弹窗的显示。所以我们的App若果崩溃之后不主动取消弹窗，崩溃弹窗也会默认在五分钟之后取消。好吧，文章开头我们所提到的两个问题我们已经解决掉一个了，force close弹窗是如何弹出来的，相信大家已经有所了解了，其实第二个问题也已经说明了，我们知道系统默认的App异常处理流程就是从Thread.setDefaultUncaughtExceptionHandler(new UncaughtHandler());开始的，并创建了自己的UncaughtHandler对象，那么我们接管系统默认的异常处理逻辑其实也就是从Thread.setDefaultUncaughtExceptionHandler开始的，并重写其uncaughtException方法，那么App异常信息就会被我们自定义的UncaughtHandler所捕获，捕获之后奔溃信息的记录与上报就可以做定制了。。。这样我们就大概分析完成了Android系统的异常处理流程。O(∩_∩)O哈哈~
#### 总结：
1、App应用进程启动时会经过一系列的调用，执行Thread.setDefaultUncaughtExceptionHandler方法，创建默认的UncaughtHandler异常处理对象。
2、默认的UncaughtHandler异常处理对象，在其回调方法uncaughtException方法中会执行弹窗异常弹窗的操作，这也就是我们原生的force close弹窗，并且弹窗如果不主动取消的话，会在五分钟内默认取消。
3、自定义App的全局异常处理逻辑，需要接管UncaughtHandler，也就是创建自身的UncaughtHandler对象，并调用Thread.setDefaultUncaughtExceptionHandler方法，接管默认的异常处理逻辑。
4、force close弹窗，弹窗的时候App应用可能已经退出，该弹窗的弹窗是SystemServer进程中的ActivityManagerService服务控制的。
