2024年安卓最新Android Native Crash 捕获之 BreakPad(2)，Android经典面试

结语

看到这篇文章的人不知道有多少是和我一样的Android程序员。

35岁，这是我们这个行业普遍的失业高发阶段，这种情况下如果还不提升自己的技能，进阶发展，我想，很可能就是本行业的职业生涯的终点了。

我们要有危机意识，切莫等到一切都成定局时才开始追悔莫及。只要有规划的，有系统地学习，进阶提升自己并不难，给自己多充一点电，你才能走的更远。

千里之行始于足下。这是上小学时，那种一元钱一个的日记本上每一页下面都印刷有的一句话，当时只觉得这句话很短，后来渐渐长大才慢慢明白这句话的真正的含义。

有了学习的想法就赶快行动起来吧，不要被其他的事情牵绊住了前行的脚步。不要等到裁员时才开始担忧，不要等到面试前一晚才开始紧张，不要等到35岁甚至更晚才开始想起来要学习要进阶。

给大家一份系统的Android学习进阶资料，希望这份资料可以给大家提供帮助。

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化学习资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

========================================================================

如下从几个维度分析说明了如何使用。

构建 so 注意事项

这里要特别注意一个问题，记得每次构建备份自己 obj 带符号表的 so 文件，发布一定要用不带符号表的小体积 so 文件，别搞混了，别问我为什么，这是常识。

获取 native crash 后的 dump

如上一顿操作后你会发现，你只用在你项目初始化时给他喂个路径就行，然后就等着 native 奔溃后触发他往你路径下写一个.dump文件吧。

如果你需要线上使用且需要保留所有的 dump，那就自己简单封装管理下文件目录啥的吧，然后每次启动发现有这个文件就上传到你服务器吧。

dump 文件怎么转成可阅读的崩溃堆栈

假设你程序现在 native crash 了，你也从服务端拿到 dump 文件了，接着我们需要对其做解析即可。

解析工具从哪来？还是 Breakpad 编译就行，具体参见官方文档里如何编译 minidump_stackwalk 工具部分吧。

如果你像我一样足够懒，或者因为第一次编译了 minidump_stackwalk 工具但是后来丢了，这时候你的第一选择肯定就是重新拉代码编译出一个工具。我想说的是，你可以偷懒，哈哈。

现成的 minidump_stackwalk 工具在哪里？

在这里，无论你是 Mac、windows、linux，我都试过，在 Android Studio 的安装目录下的bin\lldb\bin里面就存在一个对应平台的可执行文件叫做 minidump_stackwalk，这就是偷懒的办法。

所以我们直接用这个工具执行解析 dump 即可，如下操作：

./minidump_stackwalk xxooxx.dump > crash.txt

dump转换成可阅读崩溃堆栈文件后怎么分析

打开crash.txt你会发现类似如下的日志：

Operating system: Android

0.0.0 Linux 4.14.116 #1 SMP PREEMPT Wed Apr 8 17:01:19 CST 2020 armv8l

CPU: arm

ARMv1 ARM part(0x4100d0b0) features: half,thumb,fastmult,vfpv2,edsp,neon,vfpv3,tls,vfpv4,idiva,idivt

8 CPUs

GPU: UNKNOWN

Crash reason: SIGSEGV

Crash address: 0x0

Process uptime: not available

Thread 0 (crashed)

0 test.so + 0x18efd86

r0 = 0x00000000 r1 = 0x00000000 r2 = 0x7fffffff r3 = 0x00000000

r4 = 0x0000002a r5 = 0xffdfd948 r6 = 0xd1403280 r7 = 0xd13cdd14

r8 = 0xffdfd4f4 r9 = 0xffdfd940 r10 = 0xffdfd944 r12 = 0xffdfd4b8

fp = 0xffdfd4f4 sp = 0xffdfd4e0 lr = 0xf3d6886d pc = 0xcfc03d86

Found by: given as instruction pointer in context

…

通过上面的Crash reason: SIGSEGV我们可以知道是 unix 系统里的哪种类型错误，最关键的其实是(crashed)关键词开始的行，显示了哪个 so 哪里 crash 了，即test.so + 0x18efd86显示了发生 crash 的位置和寄存器信息。

有了具体的崩溃寄存器信息，我们接下来直接进行符号解析即可，然后就能直接看到是源码的哪一行崩溃了，直接去修复即可，使用 Android NDK 里面提供的 addr2line 工具（SDK 里面自己找）将寄存器地址转换为对应符号。记得 addr2line 要用和自己 so 的 ABI 匹配的目录（上面crash.txt中有崩溃 so 的 ABI 信息）。

arm-linux-androideabi-addr2line -f -C -e obj-test.so 0x18efd86

//具体崩溃代码位置，其他行号啥的自己去看 addr2line 参数列表吧

xxxxxxFunc()

这里就不再过多解释 addr2line 的用法了，和安卓墓碑机制的 tombstone 解析一样用法，自己去查吧，懒得写了。

crash.txt中崩溃的不是我的 so 怎么办

一般 app 开发者都是凉拌，最多就是反馈给对应固件厂商或者 SDK 的开发者，因为想要通过寄存器地址反转到代码行数是需要有对应版本 obj 中带符号表的 so 才行，而这些 so 的备份只有对应提供者有。譬如如下这种奇葩的 bug。

Crash reason: SIGTRAP

Crash address: 0x0

Process uptime: not available

Thread 0 (crashed)

0 libmonochrome.so + 0x18efd86

唯一途径就是反馈给厂商背锅了。

总结

---

甩锅需要证据，证据来源如上分析，一顿操作猛如虎，最后发现 native crash 最多的都特么是三方 SDK，随伏案吐血而亡。

《960全网最全Android开发笔记》

《379页Android开发面试宝典》

《507页Android开发相关源码解析》

因为文件太多，全部展示会影响篇幅，暂时就先列举这些部分截图

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化学习资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。**

需要这份系统化学习资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！