1. 崩溃监控工具选择
主流工具对比
| 工具 | 优势 | 适用场景 |
|---|---|---|
| Firebase Crashlytics | 免费、实时报告、与 Google 生态集成 | 中小型应用、快速接入 |
| Sentry | 支持多平台、自定义过滤、开源 SDK | 复杂业务、需要深度分析 |
| Bugsnag | 自动上下文关联、支持 NDK 崩溃 | 企业级应用、高稳定性要求 |
| Bugly（腾讯） | 中文支持好、实时告警、支持符号化 | 国内应用、快速响应 |
2. 集成与配置
以 Firebase Crashlytics 为例
添加依赖：
// build.gradle (app)
dependencies {
implementation 'com.google.firebase:firebase-crashlytics:18.6.1'
}
初始化 SDK：
class MyApp : Application() {
override fun onCreate() {
super.onCreate()
FirebaseApp.initializeApp(this)
FirebaseCrashlytics.getInstance().setCrashlyticsCollectionEnabled(true)
}
}
强制触发测试崩溃（验证集成）：
throw RuntimeException("Test Crash for Firebase")
3. 关键崩溃信息收集
必收集字段
| 字段 | 说明 |
|---|---|
| 堆栈轨迹 | 崩溃线程的详细调用栈（包括行号） |
| 设备信息 | 型号、Android 版本、RAM/ROM 使用率 |
| 应用上下文 | 当前 Activity/Fragment、用户 ID（脱敏后） |
| 网络状态 | 网络类型（Wi-Fi/4G）、请求 URL（如崩溃在网络层） |
| 自定义日志 | 通过 FirebaseCrashlytics.log() 添加关键日志 |
示例：添加自定义信息
FirebaseCrashlytics.getInstance().setCustomKey("user_role", "premium")
FirebaseCrashlytics.getInstance().log("User clicked button X before crash")
4. 混淆与符号化处理
步骤说明
生成 Mapping 文件
在 build/outputs/mapping/release/ 下找到 mapping.txt（ProGuard/R8 生成）。
上传符号文件到后台
Firebase：通过 Grad 插件自动上传：
apply plugin: 'com.google.firebase.crashlytics'
手动上传（针对 NDK 崩溃）：
./gradlew :app:uploadCrashlyticsSymbolFileRelease
还原堆栈
工具后台自动将混淆后的类名（如 a.a.a）转换为原始类名（如 MainActivity）。
5. 崩溃聚合与优先级划分
典型聚合维度
崩溃类型：NullPointerException、OutOfMemoryError 等。
设备型号：特定厂商（如 Xiaomi）的系统兼容性问题。
操作系统版本：Android 12 以上的权限变更导致崩溃。
用户路径：从“支付页面”进入后发生的崩溃。
优先级判定规则
| 等级 | 标准 | 响应时间 |
|---|---|---|
| P0 | 核心流程崩溃（如支付、登录），影响 5%+ 用户 | < 2 小时 |
| P1 | 非核心功能崩溃，影响 1%-5% 用户 | < 24 小时 |
| P2 | 低频崩溃（<1%），不影响主流程 | 下一版本修复 |
6. 根因分析与修复
常见崩溃场景与解法
| 崩溃类型 | 典型原因 | 解决方案 |
|---|---|---|
| NullPointerException | 未判空直接调用对象方法 | 添加 ?. 或 !! 前检查非空 |
| ANR（Application Not Responding） | 主线程耗时操作（如数据库读写） | 使用协程/线程池异步处理 |
| OutOfMemoryError | 内存泄漏（如未解注册监听器） | 使用 LeakCanary 检测并修复 |
| Crashes in Native Code | JNI 层逻辑错误或内存越界 | 使用 adb logcat 或 ndk-stack 分析 |
使用 Android Studio 调试崩溃
在 Logcat 中过滤崩溃日志（关键词：FATAL EXCEPTION）。
通过 Debugger 附加到进程复现问题。
使用 Profiler 监控内存/CPU 异常。
7. 热修复与验证
热修复方案
| 工具 | 原理 | 限制 |
|---|---|---|
| Tinker | 全量替换 Dex/资源文件 | 需重启应用 |
| Sophix | 阿里云方案，支持即时生效 | 商业付费 |
| Robust | 方法级替换，高兼容性 | 代码插桩增加包体积 |
验证流程
灰度发布：先向 10% 用户推送修复版本。
监控指标：观察崩溃率是否降至 0%。
全量发布：确认修复有效后覆盖全体用户。
8. 预防与优化
代码层面
使用 @NonNull/@Nullable 注解。
避免主线程阻塞：用 CoroutineScope(Dispatchers.IO) 执行 IO 操作。
内存优化：定期检查 Activity 泄漏（通过 LifecycleObserver）。
自动化测试
单元测试：使用 JUnit + Mockito 覆盖关键逻辑。
UI 测试：通过 Espresso 模拟用户操作路径。
Monkey Test：使用 adb shell monkey 随机压力测试。
9. 高级场景：NDK 崩溃捕获
使用 Breakpad
编译 Breakpad 库
在 CMakeLists.txt 中集成 Google Breakpad：
add_subdirectory(external/breakpad)
target_link_libraries(native-lib breakpad)
捕获 Native 崩溃
#include "client/linux/handler/exception_handler.h"
bool DumpCallback(const char* dump_path, void* context) {
// 上传 dump 文件到服务器
return true;
}
ExceptionHandler eh("/tmp", nullptr, DumpCallback, nullptr, true);
符号化 minidump 文件
使用 dump_syms 和 stackwalker 工具解析崩溃堆栈。
10. 数据驱动优化
监控 Dashboard：通过 Crashlytics 或自建平台跟踪崩溃率趋势。
用户反馈闭环：在崩溃弹窗中添加“提交反馈”按钮，收集用户描述。
版本对比：分析新版本崩溃是否引入回归问题。
通过以上步骤，可实现 Android 端崩溃的 快速发现、精准定位、高效修复，显著提升应用稳定性。
