开篇
好久没更新简书，今天总结一下项目开发中对于已发布项目的bug监控，与发现crash后代码的调试，本文主要介绍Bugly与zombies。
Bugly
关于Bugly的接入直接可以从文档上查到详细的教程，Bugly iOS SDK 使用指南。这里我们主要说一下接入以后的使用方式。
如下图
在集成了Bugly以后出现crash会在Bugly的后台体现出来。
在问题详情处我们可以看到具体的崩溃信息。
符号表
虽然看到了崩溃信息，但是是已经转化为相关内存地址的信息我们无法看到具体是哪一行代码出现了问题，于是要进行符号表的配置，符号表配置SDK
-
符号表配置的注意事项
image.png
我们需要上传的dSYM文件的uuid要与bug提示对应的uuid一致，这样才能解析出对应的crash信息。
首先要去拿到dSYM文件
显示包内容之后在dSYMs文件夹内我们可能看到一个或者多个dSYM文件如下图所示，每次编程打包会生成一个dSYM文件。那么我们怎么知道在这么多文件中那个才是我们需要的呢？
我们可以通过文件名来知道每个dSYMs对应的uuid是多少，也可以通过命令行来查看
xcrun dwarfdump --uuid <dSYM文件>
压缩对应的dSYM文件，然后上传至Bugly后台我们就能看到对应的crash信息。
我们可以看到具体的文件和方法造成了项目的crash，甚至可以精确到对应的行数。那么问题来了？配置了符号表我们就能清楚的看到所有的崩溃信息了嘛，看下图
惊不惊喜，意不意外，虽然通过Bugly我们看到了crash次数和crash信息，但是我们仍然不清楚是哪里导致的crash，真机调试的时候也确实发现了crash，但是是崩在主线程里。真正的痛苦不是crash，而是我不知道哪里导致了crash。
zombies
面对主线程的crash一般的应对模式是，打开僵尸断点，然后进行调试，一顿操作之后我们看到了控制台的打印信息
-[CFString release]: message sent to deallocated instance 0xxxxxxx内存地址xxxxxxx
告诉我这个我也很绝望，我只是想知道崩溃的是哪一行，我又不是计算机要个锤子的内存地址，一顿操作猛如虎，一看战绩😂😂😂。。。只能乖乖打开我们的终极神器 zombies
选择zombies
之后运行项目在crash地点我们可以看到一个红色的小箭头，激动人心的时刻终于来了，
就是他，点击他你将看到真相
点击之后出现的部分里，对应的高亮部分就是对应的bug信息，这里我们已经可以明确的可以看到类名和方法等，双击高亮部分，我们甚至可以看到对应的项目中某一行，没错就是这些导致的crash，下面着手改掉他就好了。
后记
通过Bugly与zombies我们可以调试项目中出现的很大一部分问题，终于可以愉快的敲代码了。
最近半年真的是一言难尽，终于稳定了下来希望以后能多多积累，努力学习，upup。
