Crash日志收集：日志格式、关键信息提取方法
做Crash分析这么多年，我最怕一种情况——拿到一个日志，关键字段被截断，堆栈不全，线程信息丢失。说白了，日志质量直接决定了分析效率。这一章我们就聊一聊怎么把日志收好、看透，把关键信息一把捞出来。
常见日志格式，你得心里有数
不同的平台、不同的Crash类型，日志格式差别很大。我习惯把它们分成三类：
| 平台/场景 | 典型格式 | 关键特征 |
|---|---|---|
| Android Native | tombstone / debuggerd 输出 | 包含信号、寄存器、堆栈、内存映射 |
| Android Java | Java 堆栈 + 异常类型 | 异常链、线程名、类方法行号 |
| iOS / macOS | .crash 文件 (Apple格式) | UUID、binary images、thread state |
| Linux core dump | ELF 二进制 + gdb 用于解析 | 需要符号表匹配 |
| Windows minidump | .dmp (MiniDumpWriteDump) | 带栈回溯、内存快照 |
嗯，这里要注意——同一个App在不同设备上，日志格式可能微调。我在项目中遇到过某款定制Android系统把主线程名截断到8个字符，害得我排查了半天才发现是线程名对不上。所以，你最好在日志采集阶段就做格式统一。
关键信息提取：从日志里挖出四块“金矿”
日志拿到手，别急着看堆栈。先把下面这几个信息抽出来：
- 进程与线程：PID、TID、线程名称，是否主线程？
- 异常类型与信号：Java 的 NullPointerException 还是 Native 的 SIGSEGV？
- 寄存器与内存：PC、LR、SP 的值，以及内存映射区。
- 堆栈回溯：调用链，特别是最后一个调用的函数地址。
我把这四块信息称为“Crash身份证”。我个人习惯第一步先把它们填到一个固定模板里，确保不遗漏。
我的小技巧：写一个简单的 Python 脚本，自动从日志中按正则提取这些字段。比如提取 Android tombstone 中的 PC 寄存器：
import re
pattern = r'pc\s+([0-9a-fA-F]+)'
match = re.search(pattern, log_content)
if match:
pc = match.group(1)提取方法：手撕VS自动化
你可能会问：这些信息一个个找不就行了吗？说实话，在崩溃量大的场景下，手工提取等于浪费生命。我曾经在压测环境一天收到500多个Crash日志，全靠手工看——看了一天，眼睛都快瞎了。后来我写了个解析器，把关键字段打上标签存到数据库，查询效率翻了不止10倍。
自动化的核心思路就是两步：
- 第一步：使用正则或DSL解析不同格式的日志，输出结构化JSON。
- 第二步：按Crash指纹（信号+堆栈顶函数）去重，归类存储。
避坑指南：我曾经踩过一个坑——日志中的堆栈地址是未符号化的（比如
#00 pc 0x1234 /system/lib/libxxx.so）。如果不提前做符号化，你拿到的只是裸地址，完全没法定位代码行。所以，提取阶段就要和符号表服务器联动。整个流程画个图就清楚了
下面这张图概括了从日志产生到关键信息提取的完整链路，你把它当作你工具链的蓝图就行。
警告：日志收集阶段千万别做任何过滤！我见过有人觉得某些日志“不重要”就直接丢弃，结果真正关键的崩溃信息反而丢了。宁滥勿缺，所有原始日志全部保留，等解析时再按规则剔除噪声。
好了，日志收进来、关键信息抽出来，下一步才是真正的Crash分类和复现。说白了，前两步做扎实了，后面90%的问题都挡不住你。你想想看，如果连日志里的寄存器都读不对，那还谈什么复现？