3. Android Native层架构
要定位 Native Crash，必须先建立一张“运行时地图”：崩溃信号从哪里来、由谁接收、栈帧落在哪个库、最终如何被 tombstone 记录。Android 的 Native 层并不是单一 libc，而是由内核、Bionic、ART、Zygote、系统 Native 服务、HAL 与厂商库共同构成的执行环境。理解它们的职责边界，才能判断一个 SIGSEGV 是应用自身空指针、ART 运行时异常，还是系统库与厂商库的兼容性问题。
一、Native 层的组成与调用链
从下往上，Android Native 层大致分为四层：Linux 内核提供进程、内存、信号与系统调用；Bionic 提供 libc、libm、libdl、liblog 等基础运行库；ART 虚拟机与 Zygote 负责 Java/Kotlin 世界的启动与托管；再往上是系统 Native 服务（如 SurfaceFlinger、AudioFlinger、CameraService）和 HAL/厂商库。应用进程虽然以 Java 代码为主，但最终仍通过 JNI 进入 Native 世界，调用 Bionic 与内核。
关键点在于：Java 崩溃与 Native 崩溃的分界线是 ART 与 JNI。Java 异常由 ART 抛出并打印 Java 栈；而 SIGSEGV、SIGABRT、SIGILL 等信号由内核投递，由 Bionic 的 linker/debuggerd 捕获并生成 tombstone。因此看到 tombstone，说明崩溃已经发生在 Native 层或 ART 运行时内部。
二、Zygote 与 ART：应用进程的起点
Zygote 在系统启动时由 init 拉起，预先加载 ART 运行时、常用 Java 类与资源，然后通过 fork 快速孵化应用进程。这意味着所有应用进程共享 Zygote 的地址空间布局与已加载库。如果 Zygote 预加载的某个 Native 库存在缺陷，崩溃可能表现为“多个应用同时崩溃”或“启动即崩”。
ART 负责 Java 代码的执行、GC、异常抛出与 JNI 调用。当 Java 代码通过 JNI 调用 Native 函数时，线程栈会从 Java 栈切换到 Native 栈。若 Native 函数内部发生空指针解引用，内核向该线程投递 SIGSEGV，ART 的 signal handler 与 Bionic 的 debuggerd 协同工作，最终输出包含 #00 pc 帧的 tombstone。因此，ART 既是 Java 崩溃的源头，也是 Native 崩溃的“第一现场记录者”之一。
三、Bionic、libc 与系统调用
Bionic 是 Android 对标准 C 库的定制实现，体积小、面向移动设备，且与内核系统调用紧密绑定。它包含 libc、libm、libdl、liblog 以及动态链接器 linker。应用中的 malloc、pthread_create、dlopen、open 等调用最终都由 Bionic 转发到内核系统调用。
系统调用是用户态进入内核态的入口。常见崩溃与系统调用密切相关：
- SIGSEGV：访问非法内存地址，常见于空指针、野指针、栈溢出、use-after-free。
- SIGABRT：通常由
abort()、断言失败、C++ 未捕获异常、堆破坏检测触发。 - SIGILL：执行非法指令，常见于 ABI 不匹配、CPU 指令集不支持、代码段被破坏。
- SIGBUS：内存对齐错误或 mmap 文件访问越界。
Bionic 的 linker 还负责加载 .so 并重定位符号。若出现 dlopen failed: library "libxxx.so" not found 或符号找不到，进程可能在启动阶段直接 abort，这类问题在 tombstone 中通常表现为 abort_message 栈帧。
四、崩溃关系速查表
| 层级/组件 | 典型职责 | 常见崩溃信号 | tombstone 关键线索 |
|---|---|---|---|
| 应用 Native 库 | 业务逻辑、JNI 实现 | SIGSEGV、SIGABRT | 栈帧落在 libxxx.so，含业务符号 |
| ART | Java 执行、GC、JNI 桥接 | SIGSEGV、SIGABRT | libart.so 帧、GC 相关、JNI 调用点 |
| Zygote | fork 应用进程、预加载 | SIGABRT、SIGSEGV | 启动即崩、多应用同时崩 |
| Bionic/libc | 内存、线程、动态链接、系统调用封装 | SIGSEGV、SIGABRT、SIGILL | libc.so 帧、malloc/free、linker 报错 |
| 系统 Native 服务 | 图形、音频、相机等系统能力 | SIGSEGV、SIGABRT | system_server 或 native 服务进程崩溃 |
| HAL/厂商库 | 硬件抽象、驱动适配 | SIGSEGV、SIGILL | vendor 分区 .so 帧、ABI 不匹配 |
| Linux 内核 | 内存管理、信号投递、调度 | 投递所有信号 | si_code、fault addr、signal 来源 |
五、案例：一次 JNI 空指针崩溃的定位
某应用在调用相机预览回调时崩溃，日志中出现如下 tombstone 片段：
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0
backtrace:
#00 pc 000000000001a2b4 /data/app/libnative-camera.so
#01 pc 0000000000021c88 /data/app/libnative-camera.so
#02 pc 0000000000034f10 /system/lib64/libart.so
#03 pc 000000000004a1c4 /system/lib64/libc.so
从栈帧看，崩溃发生在应用自己的 libnative-camera.so 中，fault addr 0x0 表明是空指针解引用。上层 libart.so 帧说明调用来自 JNI，libc.so 帧是线程启动入口。此时应优先检查 JNI 回调中是否对 Java 传入的对象做了空判断，以及 Native 层是否在对象释放后仍持有指针。
六、常见误区与复盘
- 误区一：把 libc 当成“标准 glibc”。Bionic 与 glibc 在符号、线程、DNS、locale 等方面差异明显，移植代码时容易出现未定义符号或行为不一致。
- 误区二：忽略 Zygote 预加载影响。Zygote 中加载的库若存在全局构造问题，会导致所有 fork 出的应用进程异常。
- 误区三：只看 Java 栈，不看 Native 栈。JNI 崩溃的根因通常在 Native 栈顶，Java 栈只能说明调用入口。
- 误区四：把 SIGABRT 都归为“系统杀进程”。SIGABRT 多由 abort、断言、堆破坏触发，需结合
abort_message与日志中的Fatal signal判断。