是否支持只集成native捕获部分

[854133055]

因为目前团队采用acra+breakpad方案，对于java部分的崩溃，现有方案基本没什么问题；但对于native崩溃，目前效果还不是很好，从dmp文件解析出的内容，大多是系统相关信息，业务堆栈有限。所以想优化下native部分。App中RN页面较多

目前native的堆栈类似，较多系统so，大部分出现在RN页面
libc.so NativeException: Operating system: Android
0.0.0 Linux 4.4.21-perf+ #1 SMP PREEMPT Wed Sep 12 23:34:33 CST 2018 armv8l
CPU: arm
ARMv1 Qualcomm part(0x51008010) features: half,thumb,fastmult,vfpv2,edsp,neon,vfpv3,tls,vfpv4,idiva,idivt
8 CPUs
GPU: UNKNOWN
Crash reason: SIGABRT
Crash address: 0x3fe1
Process uptime: not available
Thread 21 (crashed)
0 libc.so + 0x4a988
r0 = 0x00000000 r1 = 0x00004017 r2 = 0x00000006 r3 = 0x00000008
r4 = 0xd2eeb978 r5 = 0x00000006 r6 = 0xd2eeb920 r7 = 0x0000010c
r8 = 0xb8289080 r9 = 0x00000000 r10 = 0xf26600f8 r12 = 0x0000000c
fp = 0xf26600fc sp = 0xd2eeaf30 lr = 0xf531d06f pc = 0xf531f988
Found by: given as instruction pointer in context
1 libc.so + 0x1dacf
sp = 0xd2eeaf48 pc = 0xf52f2ad1
Found by: stack scanning
2 libc.so + 0x194c7
sp = 0xd2eeaf50 pc = 0xf52ee4c9
Found by: stack scanning
3 libhwui.so + 0x745cd
sp = 0xd2eeaf5c pc = 0xf5c985cf
Found by: stack scanning
4 libhwui.so + 0x745cd
sp = 0xd2eeaf6c pc = 0xf5c985cf
Found by: stack scanning
5 libc.so + 0x17522
sp = 0xd2eeaf78 pc = 0xf52ec524
3Found by: stack scanning
...

刚接触xCrash，想咨询下，对于上述的这种情况，集成xcrash会有提升么？ 另外，xcrash是否支持单独集成native crash信息采集的部分呢？ 感谢～

[caikelun]

1. xcrash 的 java crash / native crash / anr 捕获都支持分别单独开启或关闭。

2. 如果你们现在执行breakpad stackwalker时，已经准备好了对应设备上相关的所有so库，那么stackwalker得到的backtrace和xcrash捕获的backtrace应该是一样的；否则xcrash捕获的更全一些，因为xcrash的unwind是在设备端直接进行的。

3. breakpad minidump中包含的内存数据比xcrash多，对于解某些崩溃问题会更有帮助。

[854133055]

”已经准备好了对应设备上相关的所有so库“ 目前我们还没有针对系统的so库做收集，感觉这部分的难度会不低，讲真，也不知道去哪里收集这些so.... 但其实可能系统的信息其实并不是我们重点关注的，主要是调用系统前的业务代码

[caikelun]

1. backtrace中，系统so和apk so可能会交叉出现。
2. backtrace的前几行（#00 ......）很可能都是系统so。

因为调用栈的回溯是一层依赖于一层的。所以，如果出现了系统so的缺失，就无法保证后续的调用栈回溯的准确性。

建议你们可以灰度做个abtest，比较一下现有breakpad方案和xcrash的效果再定。

[854133055]

嗯，的确，如果用上的话会做AB的