快速定位crash的炫酷方式
本人所在项目组主要负责一款Android平台产品的开发，因为用户量比较大，正式版本发布后，每天Crash次数的上报量都在几十万量级，即便是内测版，每天Crash次数的上报量也在两三千次。面对如此庞大的上报量，能否快速准确的定位问题直接关系到Crash的解决率，我们项目组在这方面做了比较多的尝试，现在在这里给大家分享一下比较有效的一些做法，也欢迎大家一起来探讨和分享。
1
利用Bugly平台的工具自动还原堆栈
刚接入Bugly的时候，看着大量混淆后的java堆栈，着实让人头大。每次定位问题都要到处找mapping文件，手动还原堆栈。后来仔细研究了Bugly平台的帮助文档（关于帮助文档，我一般比较少看，除非出了问题，不知道大伙是不是也跟我一样，冒汗ing），才发现原来可以手动上传mapping文件，让Bugly自动还原异常堆栈。这样大大的提高了定位问题的效率，也让之前炙手可热的mapping文件终于被打入了冷宫。
不过，手动上传mapping文件也让懒癌晚期的我感到十分痛苦，后来经过确认，才发现原来Bugly可以通过Android Studio的符号表插件自动上传版本对应的mapping文件，来还原异常上报堆栈！
实现mapping文件自动上传的只需要两步：
1）在工程主根目录下的build.gradle中加入依赖库；
2）在Module目录下的build.gradle中应用插件并配属几个Bugly的属性。
•<appId>和<appKey>从产品的设置页面就可以拿到，<execute>和<upload>是插件任务执行和上传开关。
•Sync并重新release编译工程，Android Studio将会从jCenter远程仓库中下载插件并实现mapping文件的自动上传！
只要寥寥数行，便可以从上传mapping到Bugly这个无尽的任务中解脱了，一个字，爽！
2
小技巧快速准确定位到异常行号
正式版的发布线一般与开发线的差异是比较大的，当遇到一些比较复杂的异常上报时，常常需要将正式版的tag从svn上拉下来。但是即便把tag拉到本地后，只能定位到方法和调用栈，无法准确的确定到底是哪一句代码把应用搞死了。因为项目的ant脚本在打包时会对源码做一些预处理（比如会去掉log和exception的打印）或多或少会改变代码的结构，导致apk对应的源码行号与tag中源码的行号大相径庭。
例如：Bugly已经很清晰地将代码行还原，但由于代码结构变化，行号与当前的代码行是对不上的，而prepare又是个一百多行的大方法，处理这个npe有的猜了。
为了快速的定位到对应的行号，每次构建版本，我们都会把此次构建的源码打包保存到bin目录归档，这样处理异常上报时，只需要把对应版本的源码下载下来，就可以快速的查阅到是哪句代码搞的鬼!
对应上图，可以发现，哦！原来是你空了！
3
利用自定义日志还原用户操作路径
处理过bug的同学都晓得，如果一个bug可以复现，那么问题的定位和解决就会很方便。对于异常上报的问题也是一样。如果我们能够知道一个异常发生时，经过了哪些逻辑上的关键节点，就有可能把问题复现了。
我们团队将一些业务逻辑上的关键节点进行编码，并在发生异常时将这些信息通过”自定义日志功能"上报到Bugly平台。
分析对应的异常上报问题时，我们只需要打开异常上报对应的“自定义日志”，并用团队自己开发的自定义日志解析平台将关键操作还原，即可通过这些信息去定位问题了。
有了关键节点信息后，就可以尝试复现bug，一些奇奇怪怪的异常上报就难逃被消灭的命运了！
腾讯Bugly 最专业的质量跟踪平台
精神哥、小萝莉，为您定期分享应用崩溃解决方案