Android Crash的防护与追踪

一. 序

Android系统中,抛出Exception 或者 Error都会导致Crash.进而导致App强制退出.简单的来说就是因为抛出异常的代码.并未被Try catch包围…就会导致进程被杀.

二. 原理

从Fork进程伊始,就已经存在的UncaughtExceptionHandler(大致描述了AMS对于异常处理的过程.).
##1. 进程Fork之后就注册了一个UncaughtHandler

//RuntimeInit.java中的zygoteInit函数
public static final void zygoteInit(int targetSdkVersion, String[] argv, ClassLoader classLoader)
        throws ZygoteInit.MethodAndArgsCaller {
    ............
    //跟进commonInit
    commonInit();
    ............
}
private static final void commonInit() {
    ...........
    /* set default handler; this applies to all threads in the VM */
    //到达目的地！
    Thread.setDefaultUncaughtExceptionHandler(new UncaughtHandler());
    ...........
}

2. 异常处理

当UncaughtHandler接收到未捕获异常的时候.进程会自杀,并且弹出大家最熟悉不过的Force Close对话框.

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 {
                //打印进程的crash信息
                .............
            }
            .............
            // Bring up crash dialog, wait for it to be dismissed
            //调用AMS的接口，进行处理
            ActivityManagerNative.getDefault().handleApplicationCrash(
                    mApplicationObject, new ApplicationErrorReport.CrashInfo(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.
            //crash的最后，会杀死进程
            Process.killProcess(Process.myPid());
            //并exit
            System.exit(10);
        }
    }
}

又发现了神秘的System.exit(10);这里面的魔法数字.
Difference in System. exit(MagicCode) in Java

3.UncaughtExceptionHandler

3.1 简单说说UncaughtExceptionHandler

UncaughtExceptionHandler存在于Thread中.当异常发生且未捕获时.异常会透过UncaughtExceptionHandler抛出.并且该线程会消亡.所以在Android中子线程死亡是允许的.主线程死亡就会导致ANR.

下面是相关源码的截取.仔细阅读会发现.Thread中存在两个UncaughtExceptionHandler.一个是静态的defaultUncaughtExceptionHandler,另一个是非静态uncaughtExceptionHandler.

• defaultUncaughtExceptionHandler:设置一个静态的默认的UncaughtExceptionHandler.来自所有线程中的Exception在抛出,并且为捕获的情况下.都会从此路过.大家可以看到进程fork的时候设置的就是这个静态的defaultUncaughtExceptionHandler.管辖范围为整个进程.
• uncaughtExceptionHandler:为单个线程设置一个.属于线程自己的uncaughtExceptionHandler.也就是说.他的管辖范围比较小.

public class Thread implements Runnable {

 ...........
 
    @FunctionalInterface
    public interface UncaughtExceptionHandler {
        void uncaughtException(Thread t, Throwable e);
    }

    // null unless explicitly set
    private volatile UncaughtExceptionHandler uncaughtExceptionHandler;

    // null unless explicitly set
    private static volatile UncaughtExceptionHandler defaultUncaughtExceptionHandler;

  
    public static void setDefaultUncaughtExceptionHandler(UncaughtExceptionHandler eh) {
         defaultUncaughtExceptionHandler = eh;
     }
    
    public void setUncaughtExceptionHandler(UncaughtExceptionHandler eh) {
        checkAccess();
        uncaughtExceptionHandler = eh;
    }
    ...
}

3.2 UncaughtExceptionHandler的"职责连"

1. 当我们自定一个CrashHandler并register(),本质上这个CrashHandler就已经持有进程中上一个注册成DefaultUncaughtExceptionHandler的引用…并且将自己设置成进程中DefaultUncaughtExceptionHandler.

2. 异常来了.我们先在uncaughtException中处理,如果不拦截.就包装一些扩展信息,并且交给我手中的人质mUncaughtExceptionHandler继续处理.

3. 大家可能看出来了.这是一个链式的结构.直到丢给最后进程中的UncaughtExceptionHandler.然后就ForceClose了.

public class CrashHandler implements Thread.UncaughtExceptionHandler {

  private Thread.UncaughtExceptionHandler mUncaughtExceptionHandler;

  ......

  void register() {
        mUncaughtExceptionHandler = Thread.getDefaultUncaughtExceptionHandler();
        Thread.setDefaultUncaughtExceptionHandler(this);
    }
  }
  
  
   @Override public void uncaughtException(Thread thread, Throwable throwable) {
    
    //做些事情
    ......
    
    if(心情不好){
	    return;
    }
    //心情不好的话,异常就不能继续传递了.
    mUncaughtExceptionHandler.uncaughtException(thread, facadeThrowable);
  }

  ......
}

总结: 很重要! 很重要!! 很重要!!!

UncaughtExceptionHandler是以链式结构存在.原则上,谁后注册的,谁优先处理异常,并且决定,这个异常是否交给上一个注册的.这点很重要,牢记!假如我们注册在其他UncaughtExceptionHandler后边很有可能导致,因为他们并未继续传递Exception.导致一些其他问题.所以我们要注册在最后.以便优先处理.

三. App层可以做的Crash防护

1.Crash统计平台

例如Fabric等错误日志上报平台,可以当Crash发生时,收集异常信息.到平台,此处不扩展讲.网上相关文档很多.本质也是注册一个UncaughtExceptionHandler然后将Throw上报给服务器.

2. try-catch大法好.

Java的异常处理可以让程序具有更好的容错性，程序更加健壮。当程序运行出现意外情形时，系统会自动生成一个Exception对象来通知程序。大家肯定会考虑到性能损耗问题。毕竟做了“额外”的事情。这里我从两种方式去探究一下：
写两个一样逻辑的函数，只不过一个包含try-catch代码块，一个不包含，分别循环调用百万次，通过System.nanoTime()来比较两个函数百万次调用的耗时。本机跑了一下基本上没什么区别。
可以看看.java文件经过编译生成的JVM可以执行的.class文件里的字节码指令。

 javap -verbose ReturnValueTest  xx.class 命令可以查看字节码

《深入Java虚拟机》作者Bill Venners于1997年所写的文章How the Java virtual machine handles exceptions比较详尽地分析了一番。文章从反编译出的指令发现加了try-catch块的代码跟没有加的代码运行时的指令是完全一致的（你也可以按照上面命令自行进行对比）。 如果程序运行过程中不产生异常的话try catch 几乎是不会对运行产生任何影响的 。只是在产生异常的时候jvm会追溯异常栈。这部分耗时就相对较高了。

3.上文地提到的"职责连"

我们能做的就是在所有第三方的UncaughtExceptionHandler注册之后,注册一个自己的CrashHandler.这样我们就可以在第一时间接收到异常之后,做异常拦截或者异常包装.

4.异常拦截

上文同样提到了.我们注册一个自己的CrashHandler的目的之一,就是优先与异常见面…当发现可以拦截的异常的时候.就不将其继续传递.异常拦截最重要的原则就是不能拦截主线程中的异常:

这是一段异常拦截的代码:

  @Override public void uncaughtException(Thread thread, Throwable throwable) {
    //先尝试拦截拦截
    if (crashInterceptor()) {
      return;
    }
    uncaughtExceptionHandler.uncaughtException(thread, facadeThrowable);
  }

 //异常拦截器
public static boolean crashInterceptor(Throwable throwable, Thread thread) {

    if (thread.getId() == 1
        || throwable == null
        || throwable.getMessage() == null
        || throwable.getStackTrace() == null) {
      //异常发生之后,所在线程会挂掉.所以主线程异常,拦截了也没用.主线程也会死掉.
      //除非,后续判断,app在前台,触发APP重启.
      return false;
    }

    String classpath = null;
    if (throwable.getStackTrace() != null && throwable.getStackTrace().length > 0) {
      classpath = throwable.getStackTrace()[0].toString();
    }

    if (classpath == null) {
      return false;
    }

    //拦截GMS异常.
    if (throwable.getMessage().contains("Results have already been set") && classpath.contains(
        "com.google.android.gms")) {
      logException(throwable);
      return true;
    }

    //拦截GMS的 NPE.
    if (classpath.contains("com.google.android.gms") && throwable instanceof NullPointerException) {
      CrashHelper.logException(CrashFacade.facadeThrowable(throwable));
      return true;
    }


    //拦截ssl_NPE
    if (throwable instanceof NullPointerException && throwable.getMessage()
        .contains("ssl_session == null")) {
      CrashHelper.logException(CrashFacade.facadeThrowable(throwable));
      return true;
    }

    return false;
  }

5.异常信息包装上传

当我们用了平台之后,发现除了我们自己能看到的又明确调用栈的异常信息.还有许许多多看不到调用栈的.或者是第三方SDK里的Crash.这些Crash因为没有调用栈.一直是个很头疼的问题.

  @Override public void uncaughtException(Thread thread, Throwable throwable) {
    //先尝试拦截拦截
    if (crashInterceptor()) {
      return;
    }
    //再包装扩展信息,交给Fabric上报服务器
    Throwable facadeThrowable = facadeThrowable(throwable , "");
    uncaughtExceptionHandler.uncaughtException(thread, facadeThrowable);
  }

  //通过反射,在detailMessage后面追加信息
  public static Throwable facadeThrowable(Throwable throwable , String facadeMessage) {
    try {
      Field field = getDeclaredField(throwable, "detailMessage");
      if (field == null) {
        return throwable;
      }
      field.setAccessible(true);
      String originDetailMessage = (String) field.get(throwable);
      String newDetailMessage = originDetailMessage + facadeMessage;
      field.set(throwable, newDetailMessage);
    } catch (Exception ignore) {
      CrashHelper.logExceptionWithoutFacade(ignore);
    }
    return throwable;
  }

此处我们追加的部分信息的截图.两个例子.没有调用栈的情况.
我这里都是先通过包装Crash.收集没有调用栈信息异常和第三方库的异常的所在线程.在谨慎的增加对应的异常拦截.确保没有在主线程中拦截异常…毕竟ANR了…也不合适.就直接挂掉吧…

这是我在StackOverFlow上和Google Issue Tracker上的提问
StackOverFlow : GMS IllegalStateException : Results have already been set?
Google Issue Tracker : GMS Results have already been set
也有很多网友遇到了同样的问题。我也就先捕获一下。

WARNING: 之前尝试.在UnCaughtHandler中,将Exception放到一个new Throwable的cause中.并追加信息.这种方式会导致平台日志堆叠,因为new Throwable都产生在同样的地方.平台会把日志合并.所以才考虑用反射的方法加到detailMessage后面的.

大结局

哦?FinalizerWatchdogDaemon是什么线程?
引发了我研究从Daemons到finalize timed out after 10 seconds这个问题

简书个人主页欢迎大家关注

相关资料

Android开发之打造永不崩溃的APP——Crash防护