📚 课程目录第4章原生Crash与托管Crash

原生Crash与托管Crash：Java/Android平台区别

我先问个问题：你在开发 Android 时，见过这两种 crash 吗？一种是“空指针”，直接告诉你异常类名；另一种是“段错误”，只有个信号编号。这两种到底差在哪儿？

嗯，要搞清楚这个，得先明白 Android 应用是跑在两层世界里的。上层是 Java/Kotlin 写的业务代码，底层是 C/C++ 写的系统库和 NDK 代码。这两层的 crash 机制完全不同。

1. 托管 Crash：Java/Kotlin 层面的异常

托管 Crash 说白了就是 Java 虚拟机（ART）抛出的未捕获异常。我们平时最熟悉的 NullPointerException、IndexOutOfBoundsException 都属于这一类。

  关键特征： 托管 Crash 是受控的。Java 有一套完整的异常处理机制，异常对象包含了完整的调用栈、线程信息、异常消息。你能清楚地知道是哪一行代码出了问题。

我在项目里遇到过好几次：线上突然大量用户闪退，日志里全是同一个 ConcurrentModificationException。你想想看，这个问题其实很好定位——因为异常栈清晰，直接指向了某个 HashMap 在多线程里被同时操作。

举个例子，一个典型的空指针 crash 日志长这样：

java.lang.NullPointerException
    at com.example.app.MainActivity.onClick(MainActivity.java:42)
    at android.view.View.performClick(View.java:7355)
    at android.view.View.performClickInternal(View.java:7322)
    ...

这个信息量已经足够我们直接定位到 MainActivity.java 第 42 行。所以我们处理托管 Crash 时，重点在于理解异常类型和修复逻辑，而不是猜测在哪崩溃。

小技巧： 我个人习惯在 Application 的 Thread.setDefaultUncaughtExceptionHandler() 里捕获所有未处理异常，把线程名、异常栈、手机信息、时间戳一并写入本地日志文件。这样即使线上没有及时上传，也能从本地捞到线索。

2. 原生 Crash：C/C++ 层面的信号

原生 Crash 就不一样了。它发生在 Native 层，通过 Linux 信号机制上报。Android 中最常见的信号是 SIGSEGV（段错误，信号 11）和 SIGABRT（异常终止，信号 6）。

为什么原生 Crash 更难搞？因为信号本身不携带对象信息，只有内存地址和寄存器快照。你看到的是：

pid: 12345, tid: 12345, name: my_thread  >>> /data/app/com.example.app <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0
    r0 00000000  r1 12345678  r2 ... 
    #00 pc 00012345  /system/lib/libc.so (malloc+0x234)
    #01 pc 00056789  /data/app/com.example.app/lib/arm64/libnative-lib.so (Java_com_example_native_NativeBridge_nativeMethod+0x12)
    ...

注意： 原生 Crash 没有“异常消息”，没有行号，只有地址和映射库。你需要用 addr2line 或 ndk-stack 工具把 PC 地址还原成源码行号。而且——这是个大坑——Release 版本通常会去掉符号表，你必须保留好每次构建时的 .so 文件。

我曾经被一个原生 Crash 折磨过两三天。线上日志显示 SIGSEGV 发生在 libc.so 的 memcpy 里，但地址每次都变。最后发现是 NDK 代码里一个结构体指针没有初始化，在某种内存压力下被随机覆盖了。嗯，这种问题靠纯看日志是很难的，需要结合内存布局分析。

3. 核心区别对比表

我把两者的核心差异整理成了表格，方便你快速对照：

对比维度	托管 Crash	原生 Crash
语言层面	Java / Kotlin	C / C++ (NDK)
触发机制	未捕获异常 (Exception/Error)	信号 (SIGSEGV, SIGABRT 等)
信息粒度	完整调用栈 + 行号 + 异常消息	PC 地址 + 寄存器 + 内存映射
捕获方式	`try-catch` 或 `UncaughtExceptionHandler`	`sigaction()` 注册信号处理器
符号化工具	一般不需要（直接可读）	`addr2line`、`ndk-stack`
修复难度	低到中（逻辑错误居多）	高（内存管理问题，有时需要 GDB 调试）
典型场景	空指针、数组越界、类型转换失败	野指针、堆内存越界、使用已释放对象

4. 两种 Crash 在 Android 中的混用与联动

很多人以为他们完全独立。其实不是。一个典型的例子：JNI 调用中，如果 Native 代码抛出一个未处理信号，整个 ART 进程也会一起挂掉。而且，托管层的 System.exit() 最终也会触发 SIGABRT。

再比如，你在 Java 层调用 Thread.stop()（虽然已经被废弃了），底层实现就是发送 SIGKILL 信号。所以严格来说，应用层的一个调用可能会跨层产生不同类型的 crash。

  总结一句话： 托管 Crash 是“有据可查”的，原生 Crash 是“无头悬案”。两者的分析工具链完全不同，但最终都指向一个问题——你的代码写错了。

5. 原生 Crash 的避坑指南

一定要保留符号表。 我每次构建 Release 版时都会自动备份 .so 文件和 符号表 到服务器。否则等 crash 上传了，你拿到的只是一个裸地址，根本还原不了。
注册自己的信号处理器。 用 sigaction() 捕获 SIGSEGV 等信号，在 crash 前把日志写下来。注意——信号处理器里不能做复杂操作，只能写一个简单文件。
不要用 try-catch 包住 Native 调用。 这没用。Native crash 是信号，不是异常，Java 的 try-catch 捕获不了。
用 Breakpad 或 Crashpad。 我自己在项目中集成过 Google 的 Breakpad 库，它能生成 minidump，再用 dump_syms 和 minidump_stackwalk 还原出完整调用栈。省心不少。

6. 本章知识体系一览

下面这张图帮我梳理了本章的核心脉络。你看一眼应该就能记住两者的区别和关系。

7. 实际项目中的选择建议

最后聊点实战经验。如果你在选一款 crash 监控 SDK（比如 Firebase Crashlytics 或 Bugly），要注意它们对原生 crash 的支持深度。有些 SDK 只上报 Java 层异常，原生 crash 直接忽略。

我的选择： 如果项目用了 NDK（哪怕是第三方 SDk 带的），一定要选原生 crash 能解析符号表的平台。我个人偏爱 Crashlytics，它原生支持 ndk 符号上传，还能自动符号化。但你得在构建流程里把 mapping 文件和符号文件一起发上去。

嗯，说到底，搞清楚这两种 crash 的核心区别，你就知道该怎么分配精力了：托管 Crash 靠日志和代码审查就能搞定，原生 Crash 则需要更硬核的工具和内存知识储备。下一层我们聊如何统一上报它们——不过那是后话了。