Ⅰ.前言
上篇文章总结混淆相关的知识点，基本的技术点都有罗列到。如果项目开发比较紧张，可以考虑套用混淆配置的模板，复制粘贴的基础上再修修补补. 上篇文章说到和朋友讨论的问题，前几天也基本探究完了，那么也得理理思路~总结总结，期望有更多的问题出现~才可以去探讨.
Ⅱ.异常收集
这篇文章主要的技术点是异常收集，项目上线前除了混淆、打包、加固、签名和发布等，还有一项是无可避免的，就是对线上的应用进行各种统计，对应用进行各种统计包括异常的收集统计、应用的渠道下载率、活跃量、留存率和页面访问路径统计等等，有很多第三方的统计SDK可供接入使用，比如友盟+、百度、诸葛IO 等第三方，精细点的话可以考虑下无埋点技术等. 只要在上线前集成了统计SDK，那么就可以在其相应的后台看到上线后各种数据的统计报表.
统计对于运营和项目维护还是很有必要的，开发人员可以看到收集到的异常，然后对异常进行分析并找到相应解决的方案，那么这里就要开始文章的主题了，下面的截图是友盟+后台收集到的异常信息，在其异常信息下面还可以收集到该异常发生的手机型号、版本和渠道。看下异常信息吧，当看到红圈圈出来的部分，是不是就迷惑了，异常信息里怎么会有abc 这样的替代符，本来异常信息可以让开发者清楚知道异常发生的地方，可以使其轻易定位到，但现在呢?难不成靠猜的方式去定位异常，那就呵呵了.怪不得朋友说异常信息定位问题非常迷惑，那么下面开始来整整这迷惑.
Ⅲ.还原混淆信息的方式
针对上面的异常信息出现abc 的替代符，主要是由于混淆打包导致的，上面abc 其实是项目的类名或变量名的代替符，那么如果apk没有经过混淆就会导致apk源码泄露或被二次打包，虽说混淆了之后的apk还是很大风险会泄露，但相对来说代码泄露的难度是增大了，所以混淆是不可缺的。那么上面的异常信息又该如何定位Bug呢？
Android SDK工具包就提供了解决的工具，sdk\tools\proguard\bin路径下名为”proguardgui.bat”和”retrace.bat”(windows和linux下，工具的后缀名不同)的两个工具，前者是通过图形化的方式去将被混淆的异常信息反编译，后者则通过命令行的方式将被混淆的异常信息反编译.那么在使用这工具前，还得有一个叫”mapping.txt”的文件，看下面截图，这是在打包apk完成后生成的一个文件，主要记录着混淆前后的信息映射关系。
每次打包apk 完成后生成的mapping.txt 都是有必要保存的，那怎么使用上面提到的 “proguardgui.bat”和”retrace.bat” 这两个工具呢？看下面截图即可，简简单单搞定proguardgui.bat ,但抱歉的是本人试了很多次，都不能将异常信息转换回去，而最无语的是搜索到的文章介绍的方法跟我操作的完全一样，这时候我就发现了经常碰到的奇葩问题，基本文章上演示截图的异常信息都是一样的，尼玛这些文章的截图既然都是抄袭的，难不成Android SDK提供的”proguardgui.bat” 图形化工具已经失效了，接着试试”retrace.bat” 工具.上面也提到了 “proguardgui.bat”和”retrace.bat” 这两个工具基本是一样的，只是使用方式不同，一个是图形化方式，一个则是命令行方式。
在retrace.bat命令行工具里反编译异常，使用的指令为
格式：retrace.bat|retrace.sh [-verbose] mapping.txt [<stacktrace_file>]
例如：retrace.bat -verbose d:/mapping.txt d:/wyk_stacktrace.txt那么接着就验证下命令行形式的 “retrace.bat”，并不同于上面的proguardgui.bat 工具有面板可以粘贴报错信息，所以先把异常信息保存为txt文件，然后命令行进入Android SDK存放的路径sdk\tools\proguard\bin目录，根据上面的指令格式进行输入，结果如下：
结论：”proguardgui.bat”和”retrace.bat” 这两个工具包无法还原Apk线上被混淆的异常信息.
上面的截图就是使用”retrace.bat” 工具的反编译异常信息的结果，可以看到abc 的标识符依然存在，所以仍得不到完整的异常信息。反复试了很多次，依旧无果，还是找找有没有其他方式吧~~话说在Android SDK的sdk\tools\proguard\lib目录下有”proguardgui.jar”和”retrace.jar” 这两个jar包，上面使用到的”proguardgui.bat”和”retrace.bat” 这两个工具可能是基于这两个jar包的，思考如果直接使用这两jar包尝试反编译异常信息的话是否有解。先试试retrace.jar 这个jar包，命令行进入到jar包所在的目录，在命令行输入如下指令，输出的信息和上面的retrace.bat工具输出的一样，依然没有完整的异常信息.
格式：java -jar retrace.jar [-verbose] mapping.txt [<stacktrace_file>]
例如：java -jar retrace.jar -verbose d:/mapping.txt d:/error.txt
接着试试proguardgui.jar，命令行进入jar包所在的目录，输入 “java -jar proguardgui.jar” 启动proguard工具，看到的界面和proguardgui.bat 是一样的，应该说proguardgui.bat 启动的也是这个jar包，验证之后还是没有得到完整的异常信息.
结论：”proguardgui.jar”和”retrace.jar” 这两个jar包无法还原Apk线上被混淆的异常信息.
Ⅳ.根据mapping.txt文件验证
上面的工具可以还原被混淆的异常信息，其原理是因为mapping.txt存在其混淆前后的映射信息，那是不是可以根据被混淆的一小段异常信息在mapping.txt文件查找相应的映射关系，拷贝被混淆的异常信息在mapping.txt文件进行全文搜索，下面图1是收集在统计异常后台的信息，图2是在mapping.txt文件查找图1红圈部分的映射信息.图3也是异常信息和映射关系.
结论：通过上面异常信息混淆前后的映射关系，切记打包时将相应的apk和生成的mapping.txt进行对应保存，这将对上线之后的Bug追踪和维护起着非常重要的作用；
Ⅴ.其他还原混淆异常信息的方式
上面根据mapping.txt查找信息映射关系的方式，显然不适合线上Bug的追踪和应用的维护，因此就得另找出口，经常使用到的统计异常SDK有友盟+和Bugly，早前一直都在用友盟+的统计异常SDK，之后由于统计数据不及时和疏漏，所以之后的应用选择接入Bugly，Bugly针对异常的收集还是非常及时和准确的。
这些统计异常的SDK其实都有提供还原被混淆异常信息的功能，这样对开发者就非常友好了，该功能的位置在SDK后台的异常信息上边，只需要导入异常信息对应的应用版本的mapping文件，点击”解析”按钮就可以看到原始的异常信息。
在友盟+的统计后台亲测发现，被混淆的异常无法还原，探究了几番仍找不到原因.而在Bugly的统计后台亲测是有效的，可以看到下面被混淆的异常信息和还原之后的异常信息.
Ⅵ.总结
- App线上异常的追踪，可以选择友盟+、百度、诸葛IO等第三方，精细点的话可以考虑下无埋点技术等;
- 经过测试发现，Android SDK包的”proguardgui.bat” 和”retrace.bat” 这两个工具包无法还原Apk线上被混淆的异常信息;
- Apk打包后生成的的mapping文件保存着代码混淆前后的映射关系；
- 第三方SDK的统计后台一般都提供还原 “被混淆异常信息” 的功能；
- 切记 打包时将apk版本和生成的mapping.txt进行对应保存.
本篇章总结的点，有不对的地方，请多多指正.