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

Question

在 Java 或 Android 中记录未处理异常的堆栈跟踪（例如通过 ACRA）时，您通常会以普通长字符串的形式获取堆栈跟踪。

现在所有提供崩溃报告和分析的服务（例如 Google Play Developer Console、Crashlytics）都将这些堆栈跟踪分组到唯一的桶中。这显然很有帮助——否则，您的列表中可能有成千上万的崩溃报告，但其中只有一打可能是独一无二的。

示例：

java.lang.RuntimeException: An error occured while executing doInBackground()
at android.os.AsyncTask.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)
...

上面的堆栈跟踪可能以多种形式出现，例如由于平台版本不同，平台 class 等 AsyncTask 可能会显示不同的行号。

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

清楚的是，对于您发布的每个新应用程序版本，崩溃报告都应该单独处理，因为编译源是不同的。在ACRA中，可以考虑使用字段APP_VERSION_CODE.

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

Answer 1

我想您已经知道答案了，但您可能正在寻找确认。你已经暗示过了...

如果您致力于明确区分异常及其 Cause/Stacktrace，那么，答案可能会变得更容易理解。

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

我看到的正是你在问题中所暗示的。 在同一行代码（意味着相同的应用程序版本）但是在不同版本的平台（意味着不同的 Java/Android 编译）上发生的相同异常被记录为两次独特的崩溃。 我想这就是你要找的。

我希望我可以在这里复制粘贴崩溃报告，但我想我会因此被解雇 :) 相反，我会给你经过审查的数据：

A java.lang.NullPointerException 发生在 ICantSayTheControllerName.java class 2.4.8 版本的应用程序的第 117 行；但是在这个崩溃状态的两个不同（唯一）分组中，对于那些使用 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 版本号、异常和 Cause/Stacktrace 是构成特定崩溃唯一标识符的三个值；换句话说，崩溃报告的分组是根据这三个信息的唯一值完成的。我几乎想做一个数据库和主键类比，但我离题了。

此外，我以 Crittercism 为例，因为他们就是这样做的；它们几乎是行业标准；我相信他们所做的至少与崩溃报告和分析方面的其他领导者不相上下。（不，我不为他们工作）。

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

-塞尔坎

Answer 2

如果您正在寻找一种方法来获取异常的唯一值，同时忽略 OS 特定的 classes，您可以迭代 getStackTrace() 并散列不是来自的每一帧已知 OS class。我认为将原因异常添加到哈希中也很有意义。它可能会产生一些漏报，但如果您散列的异常是通用的，如 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;
    }
}

Answer 3

我知道那不是灵丹妙药，只是我的 2 美分：

我项目中的所有异常都扩展了 abstract class AppException
所有其他平台异常（RuntimeException、IOException...）在报告发送或记录到文件之前由 AppException 包装。

AppException class 看起来像这样：

public abstract class AppException extends Exception {

    private AppClientInfo appClientInfo; // BuildVersion, AndroidVersion etc...

    [...] // other stuff
}

然后我从 AppException 创建一个 ExceptionReport 并将其发送到我的服务器（如 json/xml） ExceptionReport 包含以下数据：
- appClientInfo
- 异常类型//ui、数据库、网络服务、首选项...
- origin // 从堆栈跟踪获取来源：MainActivity:154
- stacktrace as html // 突出显示以 "com.mycompany.myapp" 开头的所有行。

现在在服务器端我可以排序、分组（忽略重复项）和发布报告。如果异常类型很严重，则可以创建新工单。

如何识别重复项？

示例：

应用程序客户端信息："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")

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

Group Java/Android stack traces into unique buckets

java

android

stack-trace

acra