众所周知， Bugly是一个比较优秀的异常上报工具， java上层的崩溃和底层的崩溃都可以收集得到，在市面上得到了非常广泛的应用，但是对于一些ndk开发方面， 却一直就存在一个比较头疼的问题， 就是bugly即使捕获到了底层的堆栈，但是是长这个样子的：
对于一个研发而言，拿到这种堆栈信息，基本是没有什么价值的， 那么怎么由这个看不懂的格式变为可以看懂的格式呢？ 首先呢，我们推荐bugly官方提供的方式–上传符号表至bugly， 原则上符号表传对了就能解析出来的， 至少我用我们自己写的demo这样做是可以解析的，但是对于某些特殊情况， 出现部分崩溃堆栈， 即使我传对了符号表但依旧解析不出来的问题。 针对这种异常情况， 我找到了一种偏冷门的解析方式。 针对以上的两种方式，我接下来进行较为详细的讲解。 （首推bugly官方, 尽管某些情况下解析不出来，但是毕竟是官方推荐的。）
第一种官方推荐的方式–bugly 上传符号表
bugly官方提供了上传符号表的工具，下载了这个工具执行相应的命令即可将符号表进行上传！下载链接请点击： https://bugly.qq.com/v2/sdk?id=f67d1ca3-5db9-43d9-8329-99c8f0df3982 这个文件里面有使用文档，建议看一下。
首先先下载一下那个工具哈！然后我们打开工具进到有 buglyqq-upload-symbol.jar 这个文件的目录中，执行以下命令：
键入命令如下：
java -jar buglyqq-upload-symbol.jar -appid 你申请的appId -appkey 你申请的appKey -bundleid 包名 -version 你应用对应的版本号 -platform Android -inputSymbol 你的符号表地址
如果你的命令输入的正确，会看见诸如以下打印：
图中有一个比较重要的概念，就是标记的那个uuid， 这个uuid据我测试得出，是与符号表内容有关的，应该是按照业界统一的规范计算出来的， 类似于md5，但不是md5，也就是，假设你电脑上的代码没有变过，编译出来的符号表的 uuid，就会算出一样的结果。 那么这个uuid在bugly上具有什么意义呢？ 下图是bugly原始的不可读的堆栈：
我们会发现不可读的堆栈的每一行后面都标记了和刚才算的uuid同样格式的字串，这个就是uuid！只不过我截的图和我自己上传的符号表不匹配，所以我两个图中的uuid。 其实这个uuid即使是我们自己用logcat截，都会有这个。
原则上讲， 你上传的符号表的uuid 和 bugly截取到的日志里面的字符一样，应该就可以解析，我用自己demo测试是可以解析出来的。
但是不知道为什么。就是bugly会出现一些日志即使传了正确的符号表照样解析不出来的问题， 我甚至怀疑bugly采用的解析是不是和我们用的不一样。对于实在解析不出来的情况，可以参考接下来的方式进行解析。
第二种兜底方式–自己手动解析
首先要提到的是，此操作的一切前提是基于你有正确的符号表的情况。没有符号表的话你寸步难行。 既然我们上传的解析不对， 那只能自己把这些日志弄到本地，想办法改成能解析的格式。 我们看看bugly的堆栈
其实上面的日志，地址什么的都有了，对应的uuid 也有的， 这些信息对于我们已经是足够了的。有这些信息就有可能解！ 把这些日志内容拷贝下来，写到一个文件中，然后改成如图所示的格式：
大约需要几个步骤
- 1 在头部加上 连续16个 三个星 的格式。
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** - 2 将复制粘贴下来的内容一些不必要的信息删掉，网页上也会把bugly的行号粘贴下来的，没啥用，删掉
- 3 注意uuid位置的字串， 我们需要改成 （BuildId: uuidxxxxxxxxxxxxxxxxxxxxx）这种格式， bugly上原始的是[armeabi-v7a::uuidxxxxxxxxxx]这种格式，我这种格式，用咱们自己的解析工具是解析不出来的， 所以需要整体替换为我们可以识别的格式。
- 4 型号和真正的堆栈之间隔了一个TAB的距离。不加这种格式解析不出来。
按照步骤改基本就可以改成上图所示的模样了。到了这里，你的这个文件基本是可以解析的状态了。接下来我们对这段日志进行解析！
按照步骤改基本就可以改成上图所示的模样了。到了这里，你的这个文件基本是可以解析的状态了。接下来我们对这段日志进行解析！
符号表解析命令
准备好你的符号表,这个十分重要! 符号表是打包的时候总会有一个这样的产出的，找找就找到了，执行命令：
~/android-ndk-r20b/ndk-stack -sym 符号表路径 --dump 带解析的日志 > 解析输出文件目录
例如：
~/android-ndk-r20b/ndk-stack -sym ./ --dump ./tombstone_06 > 06log.log
正常情况下就能解析出来了。
