1nativeCrash选型和整体流程
原理流程四个阶段
graph LR
nativeCrashHappening-->systemHandle(1:SystemHandle)-->|debug|tombstoneFile(TombstoneFile)
tombstoneFile-->symbolrecovery(3:SymbolRecovery)-->analysisRootCause(4:AnalysisRootCause)
systemHandle-->|release|collectStack(2:CollectStack)-->|upload|tombstoneFile
处理流程
一个完整的 Native 崩溃从捕获到解析要经历哪些流程。
-
编译端。编译 C/C++ 代码时，需要将带符号信息的文件保留下来。
-
客户端。捕获到崩溃时候，将收集到尽可能多的有用信息写入日志文件，然后选择合适的时机上传到服务器。
-
服务端。读取客户端上报的日志文件，寻找适合的符号文件，生成可读的 C/C++ 调用栈。
现有的方案
对于很多中小型公司来说，我并不建议自己去实现一套如此复杂的系统，可以选择一些第三方的服务。目前各种平台也是百花齐放，包括腾讯的Bugly、阿里的啄木鸟平台、网易云捕、Google 的 Firebase 等等。
当然，在平台的选择方面，我认为，从产品化跟社区维护来说，Bugly 在国内做的最好；从技术深度跟捕获能力来说，阿里 UC 浏览器内核团队打造的啄木鸟平台最佳。
xCrash
BreakPad
https://chromium.googlesource.com/breakpad/breakpad/+/master
https://chromium.googlesource.com/breakpad/breakpad/+/master/docs/
https://chromium.googlesource.com/breakpad/breakpad/+/master/docs/getting_started_with_breakpad.md
https://github.com/google/breakpad
https://github.com/AndroidAdvanceWithGeektime/Chapter01
Google breakpad是一个跨平台的崩溃转储和分析框架和工具集合。
Breakpad由三个主要组件：
- client，以library的形式内置在你的应用中，当崩溃发生时写 minidump文件
- symbol dumper, 读取由编译器生成的调试信息（debugging information），并生成 symbol file
- processor， 读取 minidump文件 和 symbol file ，生成可读的c/c++ Stack trace.
简单来说就是一个生成 minidump，一个生成symbol file，然后将其合并处理成可读的Stack trace。
bugly
nativecrash模块+ setCrashHandleCallback监听上报到公司服务器
选型结论:==xCrash==
| 判断标准 | xCrash | bugly/网易云捕/阿里的啄木鸟平台 |
|---|---|---|
| 是否开源 | 是 | 否 |
| 自动上传到三方后台 | 否 | 是 |
| 是否需要公司后台符号解析 | 是 | 是 |
参考
google breakpad native crash分析工具
https://chromium.googlesource.com/breakpad/breakpad/+/master
https://bugly.qq.com/docs/user-guide/advance-features-android/?v=20200312155538#crash