iOS Debug 和 release(hoc 及App Store)版本Crash错误总结

在iOS开发过程当中，咱们常常会碰到莫名其妙的crash，而后咱们又很难定位到。
Debug版本：当咱们遇到EXC_BAD_ACCESS crash错误，颇有多是因为咱们引用的对象被释放，或者方法不存在，没法调用，这是因为内存操做错误引发的crash。当没法定位错误时，咱们引入NSZombieEnabled模式。设置了NSZombieEnabled后，一个对象销毁时会被转化为 _NSZombie，设置NSZombieEnabled后，当你向一个已经释放的对象发送消息，这个对象就不会向以前那样Crash或者产生 一个难以理解的行为，而是放出一个错误消息，而后以一种可预测的能够产生debug断点的方式消失， 所以咱们就能够找到具体或者大概是哪 个对象被错误的释放了。在XCODE 中设置NSZombieEnabled模式。点击菜单栏Product->Scheme->Edit Scheme->run->Argument->Environment variables ->+ 添加NSZombieEnabled 设为YES 从新运行。

 

---

ps：在应用发布时，记得去掉这一选项。

或者勾选Diagnostics选项中Enable Zombie Objects 

---

 

当咱们遇到SIGNAL SIGABRT等错误时候，咱们可使用断点，断点能够分为条件断点及异常断点。断点的做用很是重要，它可以帮咱们查看应用程序在给定时间点上的所在位置。
条件断点，顾名思义是指只会在特定条件下触发的断点：

异常断点。当咱们遇到异常状况crash的时候，系统通常都会自动指向主方法中。当咱们添加了异常断点后，就会再引起问题的地方中断。

 

Release 版本：程序的异常当咱们处于调试阶段，经过上面方法通常都能过定位到错误。那当咱们用发布app store版本或者分发版本 出现异常闪退的时候应该怎么定位错误呢？

你们在项目中通常都会加入log日志，我使用的是友盟的错误日志。当用户使用咱们的应用crash时，友盟日志会收集这些错误信息，这样咱们就能够经过dysm文件去定位到错误位置。

dysm文件是咱们编译后会自动生成的，它是保存16进制函数地址映射信息的中转文件，咱们调试的symbol 都在这文件中。这个文件很重要，咱们每次发布版本都会保存对应.xcarchive文件。有了这个文件咱们就能够在发布版中定位用户使用奔溃时的信息，而不须要经过该用户的设备log信息。那究竟应该怎么经过错误信息去定位呢？
下面介绍我使用umeng的错误日志定位错误：
one step 咱们打开友盟的错误日志。dsym uuId <Universally unique identifer>咱们须要找到咱们对应的.archives 的文件

dsym uuid  : dwarfdump --uuid xx.app.dSYM

app uuid :dwarfdump --uuid xx.app/xx

和错误文件中uuid 把.app 文件和dYSM 文件放到同一目录 一致咱们就能够查询了：

xcrun atos -arch armv7 -o Wherecom.app/Wherecom 0x2a32f 亦能够用dwarfdump 命令查询

这样咱们就能够定位到可能引发的错误函数名了。

网上也有热心的网友就这些命令写成了Mac工具附上下载地址， 可是仍是建议你们经常使用命令 熟悉这些常见的命令.