📚 课程目录第1章崩溃上报链路全景

1. 崩溃上报链路全景

崩溃上报链路是 Android 应用质量保障的核心基础设施。一次崩溃从发生到最终触达工程师的分析界面，需要经过采集、存储、调度、网络传输、服务端解包与落盘等多个阶段。理解整条链路的组成、参与角色、数据流向以及分层架构，是设计健壮状态机的前提。

一条完整的崩溃上报链路包含以下物理和逻辑组件：

层级	组件	职责
客户端采集	Signal Handler / Exception Catcher	拦截 native 信号或 Java 未捕获异常，提取线程堆栈、寄存器、内存映像
客户端存储	Crash File Store	将原始 crash 数据序列化为 JSON/Protobuf，写入应用私有目录；支持多文件排队
客户端上报	Upload State Machine	管理上报流程的状态转换：待上传 → 上传中 → 上传成功/重试/丢弃
通信层	HTTP/HTTPS 客户端	通过 OkHttp / Retrofit 将 crash 载荷发送至后端网关，支持 gzip 压缩
服务端接收	API Gateway / Collector	解压缩、验签、去重，写入消息队列或直接落盘
服务端存储	Object Store / Database	长期存放原始 crash 文件与结构化索引，供聚合分析使用

要点：链路中的每一个组件都可能成为瓶颈或故障点。状态机设计必须覆盖数据在链路各阶段的路径，并给出超时、重试、降级的明确策略。

在崩溃上报链路中，以下角色各自承担不可替代的职责：

信号处理器（Signal Handler）：在 native 层注册 SIGABRT、SIGSEGV、SIGBUS 等关键信号，捕获进程崩溃瞬间的完整上下文。
Java 异常捕获器：通过 Thread.setDefaultUncaughtExceptionHandler 拦截 Java 层未捕获异常。
数据序列化器：将堆栈、线程列表、内存映射、设备信息等组装成紧凑的二进制或 JSON 载荷。
上报状态机：管理文件上传的整个生命周期，负责幂等、并发控制、重试退避与过期清理。
网络调度器：根据网络状态（Wi-Fi / 移动数据 / 无网）、电量、用户后台策略动态决定是否发起上传。
服务端收集器：接收并校验客户端请求，写入存储层，同时返回合适的响应码以驱动客户端状态机转移。

崩溃数据自下而上流经四个分层：

下面的 SVG 展示了完整的崩溃上报链路架构与数据流动关系：

设计提示：严格的分层架构使状态机能够专注于“调度层”的职责，而不必关心底层存储格式或网络实现细节。在状态机内部应只处理 文件路径 → 上传结果 的抽象逻辑。

在实现崩溃上报链路时，必须正视以下五个关键挑战：

进程崩溃可靠性：崩溃处理代码自身可能在崩溃进程中运行，内存损坏、堆损坏、死锁都会导致上报失败。信号处理器必须使用 async-signal-safe 的函数。
幂等与去重：同一份 crash 数据可能因网络超时导致多次上传，服务端需通过 crash_id 去重；客户端状态机应避免重复发送已确认成功的文件。
资源竞争：多个 crash 文件同时准备上传时，需要考虑并发上传数与文件锁，防止 I/O 放大或数据损坏。
用户隐私合规：采集层不能包含敏感个人信息，链路中所有数据需经过脱敏与加密处理，并遵守 GDPR / 个人信息保护法。
低损耗集成：上报链路必须对 App 启动速度、运行期内存、流量消耗影响极小，通常通过懒初始化、后台线程调度、只在上报时才建立连接等手段实现。

常见误区：不要在信号处理器中执行 malloc、lock、printf 等非安全函数，也不要在 Java 异常捕获回调中执行复杂网络请求。这些操作极易导致死锁或二次崩溃，使 crash 文件永远无法被写出。