将Java / Android堆栈跟踪分组到唯一存储桶中

时间:2015-03-15 16:43:30

标签: java android stack-trace acra

在Java或Android中记录未处理异常的堆栈跟踪时(例如通过ACRA),通常会将堆栈跟踪视为一个普通的长字符串。

现在,所有提供崩溃报告和分析的服务(例如Google Play Developer Console,Crashlytics)都会将这些堆栈跟踪分组到唯一的存储桶中。这显然很有用 - 否则,您的列表中可能会有成千上万的崩溃报告,但其中只有十几个可能是唯一的。

示例:

java.lang.RuntimeException: An error occured while executing doInBackground()
at android.os.AsyncTask$3.done(AsyncTask.java:200)
at java.util.concurrent.FutureTask$Sync.innerSetException(FutureTask.java:274)
at java.util.concurrent.FutureTask.setException(FutureTask.java:125)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:308)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1088)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:581)
at java.lang.Thread.run(Thread.java:1027)
Caused by: java.lang.ArrayIndexOutOfBoundsException
at com.my.package.MyClass.i(SourceFile:1059)
...

上面的堆栈跟踪可能出现在多个变体中,例如由于平台版本不同,AsyncTask等平台类可能会显示不同的行号。

为每个崩溃报告获取唯一标识符的最佳技术是什么?

很明显,对于您发布的每个新应用程序版本,崩溃报告应该分开处理,因为编译的源代码不同。在ACRA中,您可以考虑使用字段APP_VERSION_CODE

但除此之外,您如何识别具有独特原因的报告?通过第一行搜索第一次出现的自定义(非平台)类并查找文件和行号?

3 个答案:

答案 0 :(得分:5)

如果您正在寻找一种方法来获取异常的唯一值而忽略特定于操作系统的类,则可以迭代getStackTrace()并散列不是来自已知操作系统类的每一帧。我认为将原因异常添加到哈希中也是有意义的。它可能会产生一些漏报,但如果您散列的异常是ExecutionException这样的泛型,那么这比假阳性更好。

import com.google.common.base.Charsets;
import com.google.common.hash.HashCode;
import com.google.common.hash.Hasher;
import com.google.common.hash.Hashing;

public class Test
{

    // add more system packages here
    private static final String[] SYSTEM_PACKAGES = new String[] {
        "java.",
        "javax.",
        "android."
    };

    public static void main( String[] args )
    {
        Exception e = new Exception();
        HashCode eh = hashApplicationException( e );
        System.out.println( eh.toString() );
    }

    private static HashCode hashApplicationException( Throwable exception )
    {
        Hasher md5 = Hashing.md5().newHasher();
        hashApplicationException( exception, md5 );
        return md5.hash();
    }

    private static void hashApplicationException( Throwable exception, Hasher hasher )
    {
        for( StackTraceElement stackFrame : exception.getStackTrace() ) {
            if( isSystemPackage( stackFrame ) ) {
                continue;
            }

            hasher.putString( stackFrame.getClassName(), Charsets.UTF_8 );
            hasher.putString( ":", Charsets.UTF_8 );
            hasher.putString( stackFrame.getMethodName(), Charsets.UTF_8 );
            hasher.putString( ":", Charsets.UTF_8 );
            hasher.putInt( stackFrame.getLineNumber() );
        }
        if( exception.getCause() != null ) {
            hasher.putString( "...", Charsets.UTF_8 );
            hashApplicationException( exception.getCause(), hasher );
        }
    }

    private static boolean isSystemPackage( StackTraceElement stackFrame )
    {
        for( String ignored : SYSTEM_PACKAGES ) {
            if( stackFrame.getClassName().startsWith( ignored ) ) {
                return true;
            }
        }

        return false;
    }
}

答案 1 :(得分:4)

我想你已经知道了答案,但你也许正在寻找确认。你已经暗示了它......

如果您承诺明确区分异常及其原因/ Stacktrace,那么答案可能会变得更容易理解。

为了仔细检查我的答案,我查看了Crittercism中的Android应用程序崩溃报告 - 这是一家我尊重和合作的分析公司。 (顺便说一句,我为PayPal工作,我曾经领导他们的Android产品之一,而Crittercism是我们报告和分析崩溃的首选方式之一)。

我所看到的正是你在问题中隐含的内容。 同一行代码发生同样的异常(意思是相同的应用程序版本),但是在不同版本的平台上(意味着不同的Java / Android编译)被记录为两个独特的崩溃。我认为& #39; s你正在寻找的东西。

我希望我可以复制粘贴崩溃报告,但我想我会被解雇:)而不是我会给你审查数据:

java.lang.NullPointerException发生在我们申请的2.4.8版本第117行的ICantSayTheControllerName.java课程中;但是在这种崩溃状态的两个不同(唯一)分组中,对于那些使用Android 4.4.2设备的用户,原因是在android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2540),但是对于那些使用Android 4.4.4的用户,原因是android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2404) 。 *请注意由于平台编译不同,ActivityThread.java中行号的细微差别。

这确保了App Version Version,Exception和Cause / Stacktrace是特定崩溃的唯一标识符的三个值;换句话说,根据这三个信息的唯一值完成崩溃报告的分组。我几乎想要建立一个数据库和一个主要的类比,但我离题了。

另外,我以Crittercism为例,因为这是他们所做的;它们几乎是行业标准;我相信他们所做的至少与崩溃报告和分析中的其他领导者相提并论。 (不,我不为他们工作)。

我希望这个真实世界的例子澄清或证实你的想法。

-serkan

答案 2 :(得分:0)

我知道这不是银弹,而只是我的2美分:

  1. 我的项目中的所有异常都延伸abstract class AppException
  2. 所有其他平台异常(RuntimeException,IOException ...)在发送报告或记录到文件之前由AppException包装。
  3. AppException类如下所示:

    public abstract class AppException extends Exception {
    
        private AppClientInfo appClientInfo; // BuildVersion, AndroidVersion etc...
    
        [...] // other stuff
    }
    
    1. 然后我从ExceptionReport创建AppException并将其发送到我的服务器(作为json / xml) ExceptionReport包含以下数据:

      • appClientInfo
      • 异常类型 // ui,数据库,网络服务,偏好...
      • 来源 //从stacktrace获取来源:MainActivity:154
      • stacktrace as html //所有以“com.mycompany.myapp”开头的行都会突出显示。
    2. 现在,在服务器端,我可以对报告进行排序,分组(忽略重复)并发布报告。如果异常类型很重要,则可以创建新票证。


      我如何识别重复项?

      示例:

      • appClientInfo:"android" : "4.4.2", "appversion" : "2.0.1.542"
      • 例外类型:"type" : "database"
      • 原产地:"SQLiteProvider.java:423"

      现在我可以用这种天真的方式计算唯一ID:

      UID = HASH("4.4.2" + "2.0.1.542" + "database" + "SQLiteProvider.java:423")