【问题标题】:Crashlytics in Android - how to capture all exceptions/crashes in one placeAndroid 中的 Crashlytics - 如何在一处捕获所有异常/崩溃
【发布时间】:2017-07-04 19:02:27
【问题描述】:

使用 Java(android 但这是一个 java 问题)我在应用程序类中创建了一个默认异常处理程序,或多或少是从某个 SO 线程中获取的:

    public class MyApplication extends Application {
@Override
    public void onCreate() {
        super.onCreate();
        AppInitialization();
    }

    private void AppInitialization() {
         defaultUEH = Thread.getDefaultUncaughtExceptionHandler();
         Thread.setDefaultUncaughtExceptionHandler(_unCaughtExceptionHandler);
    }

    private UncaughtExceptionHandler defaultUEH;

    // handler listener
    private Thread.UncaughtExceptionHandler _unCaughtExceptionHandler = new Thread.UncaughtExceptionHandler() {
        @Override
        public void uncaughtException(Thread thread, Throwable ex) {
            ex.printStackTrace();
            // TODO handle exception here
        }
    };
}

让我们谈谈我的目标是什么。我需要为 crashLytics 崩溃报告记录额外信息。因此,只要发生异常,就会调用钩子 uncaughtException(Thread thread, Throwable ex)。我认为这适用于崩溃和异常(不确定)。

关于此的 3 个问题:

  1. 这会影响 crashLytics 的工作方式,因为我覆盖了默认异常处理程序。

  2. 这是否允许应用程序继续运行 - 我不希望这样。我只想在其他地方记录异常并让它继续,就好像 defaultexceptionHandler 不存在一样。否则,QA 回归将很难看到错误,因此我们可以修复它们。如果我从 uncaughtException(thread,ex) 中调用 defaultUEH.uncaughtException(thread, ex) 会继续循环吗?

  3. 什么线程与 setDefaultUncaughtExceptionHandler 相关联?例如,这适用于所有线程还是仅适用于主线程?

所以要明确一点,我需要一种方法来发送有关每个 crashlytics 崩溃/异常的附加信息。怎么样?

更新:我看到here 有人找到了解决方案,但使用这种方法是否会使 crashlytics 也报告致命问题?

【问题讨论】:

  • 只是想知道 - 你需要什么样的额外信息?
  • 我想发送崩溃的业务逻辑。例如,应用程序状态(令牌、UUID、当前选项卡)之类的东西可以更容易地重新创建问题。
  • 我明白了,你考虑过使用Crashlytics.log 吗?通过这种方式,您可以准备与崩溃一起发送的日志,例如应用中的用户行为、他打开的活动、他选择的选项卡......只是一个想法
  • 是的,好点,但我试图在应用程序的一个区域完成所有操作,而不是使用 Crashlytics.log 调用污染应用程序。我认为将异常全部集中到一个区域并在那里完成工作会更干净。
  • 如果您在代码的多个点发送完全相同的数据,我可以理解这可能会造成污染,这是真的......

标签: java android exception-handling crashlytics


【解决方案1】:

我找到了一种干净利落的方法,并且测试正常。小心 Crashlytics.log 在崩溃报告期间发送日志。似乎在 Crashlytics 2.3.14.151 版本上无法始终如一地工作。我改用 Crashlytics.setString(key, value) 。 crashlytics.log 似乎与 crashlytics.logException(..) 一起工作得很好。

我的另一个问题是它是否适用于异步异常。答案是肯定的,我自己测试过。

所以它会捕获所有线程的所有异常。

其余的想法类似于here。该人在 defaultExceptionHandler 上使用装饰器模式向 uncaughtException 方法添加功能。

这就是我增强它的方式:

   public class DefaultUnCaughtExceptionHandlerDecorator implements UncaughtExceptionHandler {

   private UncaughtExceptionHandler mDefaultUncaughtExceptionHandler; //we will decorate the default handler to add functionality to it

   public DefaultUnCaughtExceptionHandlerDecorator(UncaughtExceptionHandler mDefaultUncaughtExceptionHandler) {
       this.mDefaultUncaughtExceptionHandler = mDefaultUncaughtExceptionHandler;
   }

   @Override
   public void uncaughtException(Thread t, Throwable e) {

       logToCrashLytics(); //add our crashlytics logging and keys here
       //  we have added our crashlytics extra data, now invoke Crashlytics
       mDefaultUncaughtExceptionHandler.uncaughtException(t, e);
   }

   private void logToCrashLytics() {

           Crashlytics.setUserIdentifier(Model.getUserID());//or whatever. this will show directly on crashlytics dashboard a pretty element

       Crashlytics.setString("Some useful Info","user is logged in"); // or whatever you want, such as printing out singleton managers references or model info
     //dont use Crashlytics.Log(..) here. it wont work consistent. 
   }

}

现在在您的应用程序类的子类中安装 crashlytics 后执行以下操作:

Thread.setDefaultUncaughtExceptionHandler(new DefaultUnCaughtExceptionHandlerDecorator(Thread.getDefaultUncaughtExceptionHandler()));

【讨论】:

  • 将什么序列从什么更改为什么@KamleshKarwande?​​span>
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2013-09-05
  • 2010-09-10
  • 2023-02-21
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多