ANR-WatchDog、ACRA、Firebase Crashlytics、xCrash 核心原理对比总结

一、总览对比表

二、各库核心原理详解

1. ANR-WatchDog

设计哲学：极简的 ANR 检测器，不做崩溃收集，只做”主线程心跳检测”。

ANR 检测原理：

Watchdog 线程（后台）
  │
  ├─ 仅当上一轮的 _tick 已被主线程消费（_tick == 0）时
  │   才向主线程 Handler post _ticker（_ticker 会将 _tick 置 0）
  ├─ sleep(N 秒)
  └─ 检查 _tick 是否为 0
       ├─ 是 → 主线程在 N 秒内执行了 _ticker，正常
       └─ 否 → 主线程未消费心跳，判定为 ANR，构造 ANRError 抛出
            （此时本轮不再 post 新心跳）

Crash 处理：

• 本身不捕获任何 Crash。它只是在检测到 ANR 时抛出一个继承自 Error 的 ANRError。
• 这个 ANRError 可以被系统的默认崩溃处理程序捕获，也可以被接入的其他崩溃收集库（如 ACRA、Crashlytics）捕获。

本质：一个可以集成到任何崩溃收集体系中的 ANR 检测探针。

2. ACRA

设计哲学：开源的、可自托管的 Java 崩溃报告框架，强调灵活性和隐私可控。

Java Crash 原理：

应用发生未捕获异常
  │
  ▼
ErrorReporterImpl (UncaughtExceptionHandler)
  │
  ▼
ReportBuilder 组装报告数据
  │
  ▼
CrashReportDataFactory 并行调用所有 Collector
  ├─ ThreadCollector → 线程堆栈
  ├─ DeviceCollector → 设备信息
  ├─ DropBoxCollector → 系统日志（含 ANR）
  └─ ... 其他 Collector
  │
  ▼
持久化为本地文件 → 调度器选择时机发送（HTTP/Email/Notification）

ANR 原理：

• 无主动 ANR 检测机制（无 Watchdog、无信号监听）。
• 通过 DropBoxCollector 在发生崩溃时顺带读取系统 DropBoxManager 中最近 dropboxCollectionMinutes 分钟（默认 5 分钟）的记录。
• 筛选的系统标签不止 ANR，而是一组：system_app_anr、system_app_wtf、system_app_crash、system_server_anr、system_server_wtf、system_server_crash、SYSTEM_TOMBSTONE 等（需开启 includeDropBoxSystemTags，默认 false），内容统一写入 ReportField.DROPBOX 字段。因此 ACRA 也能顺带捕到系统侧记录的 native tombstone 和 WTF。
• 致命限制：所有这些都必须在 ACRA 本身捕获到一次 Java Crash 时才会被读取；若发生 ANR 后没有后续 Java Crash，ANR/tombstone 信息永远不会被收集。

Native Crash：

• ACRA 核心模块不支持 Native Crash 捕获。

3. Firebase Crashlytics

设计哲学：Google 提供的云端崩溃分析服务，强调全平台覆盖、实时统计、与其他 Firebase 服务联动。

Java Crash 原理：

• 与 ACRA 类似，注册 Thread.UncaughtExceptionHandler 捕获未捕获异常。
• 但增加了 Session 概念，崩溃数据与 Session 关联，支持”无崩溃用户率”等统计指标。

Native Crash 原理：

• 通过 firebase-crashlytics-ndk 模块集成 Crashpad（或早期 Breakpad）。
• 在 Native 层注册信号处理器（SIGSEGV、SIGABRT、SIGFPE、SIGILL、SIGBUS、SIGTRAP）。
• Native crash 发生时，由 Crashpad 生成 minidump，下次启动时解析并上报。

ANR 原理：

应用启动初始化
  │
  ▼
CrashlyticsController.doCloseSessions(...)
  │
  ▼
SessionReportingCoordinator.persistRelevantAppExitInfoEvent(...)
  │
  ▼
ActivityManager.getHistoricalProcessExitReasons(null, 0, 0)
  │
  ▼
跳过 getReason() != ApplicationExitInfo.REASON_ANR 的条目
  │
  ▼
构造 Event(type="anr")
  │
  ▼
持久化为高优先级 Event → 随报告上报

• 完全被动：依赖 Android 系统（API 30+）在进程退出时记录的 ApplicationExitInfo。
• 下次启动时读取历史记录，提取 REASON_ANR 事件。
• 事件类型固定为 "anr"，包含 appExitInfo（pid、processName、traceFile 等）。没有结构化的线程堆栈列表，但 traceFile 包含原始 trace 文本（内含完整堆栈）。

4. xCrash

设计哲学：爱奇艺开源的自包含崩溃捕获库，强调”零权限、零网络、零第三方依赖”，只负责生成本地 Tombstone 文件。

Java Crash 原理：

未捕获异常
  │
  ▼
JavaCrashHandler (UncaughtExceptionHandler)
  │
  ├─ notifyJavaCrashed() → 通知 Native/ANR 处理器暂停
  ├─ 创建 .java.xcrash 日志文件
  ├─ 写入 Tombstone 头部（时间、版本、设备信息）
  ├─ 写入 Java StackTrace
  ├─ 写入 logcat / FD 列表 / 网络信息 / 内存信息
  ├─ 写入其他线程 Java 堆栈（可选）
  └─ 触发 ICrashCallback.onCrash()

Native Crash 原理：

• 在 Native 层通过 sigaction() 注册信号处理器，并通过 sigaltstack() 设置 128 KB 备用栈（SA_ONSTACK），保证栈溢出场景下信号处理器仍可运行。
• 捕获 8 个信号：SIGABRT、SIGBUS、SIGFPE、SIGILL、SIGSEGV、SIGTRAP、SIGSYS、SIGSTKFLT。
• 信号触发后，通过 clone(CLONE_VFORK | CLONE_FS | CLONE_UNTRACED)（非 NDK 构建则退回 fork()）派生子进程，随即 execl() 启动独立的 xcrash_dumper ELF 可执行文件——dumper 与崩溃进程完全隔离，因此其代码无需是 async-signal-safe。
• Dumper 通过 ptrace attach 崩溃进程并读取其内存/寄存器，使用 xCrash 自研的 DWARF / ARM EXIDX 解析器（xcrash_dumper/xcd_dwarf.c、xcd_arm_exidx.c）进行栈回溯；只有 in-process fallback 路径（xc_fallback.c）才会使用 libcorkscrew / libunwind / clang unwind。
• 最终产物：包含 Native 堆栈、寄存器、内存映射、FD 列表的 Tombstone 文件。

ANR 原理（最具特色）：

系统判定 ANR → 发送 SIGQUIT 到应用进程
  │
  ▼
xc_trace_handler (信号处理器)
  │
  ▼
eventfd 通知 xc_trace_dumper 线程
  │
  ▼
dump 线程执行：
  ├─ 创建 .trace.xcrash 文件
  ├─ dup2(stderr) 重定向到文件
  ├─ 调用 art::Runtime::DumpForSigQuit()  ← 直接调用 ART 内部方法
  ├─ 恢复 stderr
  ├─ 写入 logcat / FD / 内存信息
  ├─ tgkill() 转发 SIGQUIT 给系统 Signal Catcher（兼容系统行为）
  └─ Java 层 traceCallback()
       ├─ Util.checkProcessAnrState() 校验 NOT_RESPONDING
       └─ .trace.xcrash → .anr.xcrash 重命名

核心亮点：

• 劫持 SIGQUIT 信号，通过 dlopen/dlsym 调用 libart.so 内部的 DumpForSigQuit，获取与系统 /data/anr/trace 完全一致的内容。
• 使用 sigsetjmp/longjmp 保护，防止调用 ART 内部方法时崩溃。
• 低版本（API < 21）使用 FileObserver 监视 /data/anr/ 目录。

三、ANR 检测机制对比

四、Crash 检测机制对比

五、如何选择？

六、一句话总结