欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页

Android Crash的防护与追踪

程序员文章站 2024-03-20 17:10:34
...

一. 序

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. 当我们自定一个CrashHandlerregister(),本质上这个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 , "<HelloWorld>");
    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了..也不合适.就直接挂掉吧…

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

Android Crash的防护与追踪

Android Crash的防护与追踪

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

Android Crash的防护与追踪

Android Crash的防护与追踪

大结局

Android Crash的防护与追踪
哦?FinalizerWatchdogDaemon是什么线程?
引发了我研究从Daemons到finalize timed out after 10 seconds这个问题

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