iOS开发之Crash日志获取与分析

当在非调试状态下，我们用真机测试app，crash或者说闪退是一件很常见的事，最让我们开发人员头疼的是，自己在开发过程中总是不会遇到crash，安装到别人的设备，就出现了闪退崩溃现象。这种偶现的、概率比较低的闪退是最令人头疼。
这时iOS crash log 派上用场了，程序的大多数crash都会记录在用户的手机中，获取crash log的方法有两种：
- 用户把设备连接到电脑上，打开xcode－window，选中Devices－当前连接设备－Device Log，就可以查看所有当前设备的crash log，这个时候打开每一份crash的时候，发现这些文件的部分地址都会被转换成，类名，方法名和行号等。设备上的日志只用刚刚查看过都会被同步到organizer种,在LIBRARY下的Device Log可以查看。
- 如果你的应用已经上架，那么开发者可以通过iTunes Connect（Manage Your Applications - View Details - Crash Reports）获取用户的crash日志。不过这并不是100%有效的，而且大多数开发者并不依赖于此，因为这需要用户设备同意上传相关信息，详情可参见iOS: Providing Apple with diagnostics and usage information摘要。

当上面方法都不行时，就是说在Devices看不到logs时，那就用下面的方法来获取crash日志文件
设备连接iTune，选择设备和mac同步文件,然后保存在手机里的crash日志文件将会同步到电脑，目录在
~/Library/Logs/CrashReporter/MobileDevice/xxx的 iPhone
如下图，就是所有的crash文件：

打开crash日志文件，你会有点蒙圈，因为全都是十六进制的数据

常见的Exception Type & Exception Code
1、Exception Type
1）EXC_BAD_ACCESS
此类型的Excpetion是我们最长碰到的Crash，通常用于访问了不改访问的内存导致。一般EXC_BAD_ACCESS后面的”()”还会带有补充信息。
SIGSEGV: 通常由于重复释放对象导致，这种类型在切换了ARC以后应该已经很少见到了。
SIGABRT:  收到Abort信号退出，通常Foundation库中的容器为了保护状态正常会做一些检测，例如插入nil到数组中等会遇到此类错误。
SEGV:（Segmentation  Violation），代表无效内存地址，比如空指针，未初始化指针，栈溢出等；
SIGBUS：总线错误，与 SIGSEGV 不同的是，SIGSEGV 访问的是无效地址，而 SIGBUS 访问的是有效地址，但总线访问异常(如地址对齐问题)
SIGILL：尝试执行非法的指令，可能不被识别或者没有权限
2）EXC_BAD_INSTRUCTION
此类异常通常由于线程执行非法指令导致
3）EXC_ARITHMETIC
除零错误会抛出此类异常
2、Exception Code
0xbaaaaaad 此种类型的log意味着该Crash log并非一个真正的Crash，它仅仅只是包含了整个系统某一时刻的运行状态。通常可以通过同时按Home键和音量键，可能由于用户不小心触发
0xbad22222当VOIP程序在后台太过频繁的激活时，系统可能会终止此类程序
0x8badf00d这个前面已经介绍了，程序启动或者恢复时间过长被watch dog终止
0xc00010ff程序执行大量耗费CPU和GPU的运算，导致设备过热，触发系统过热保护被系统终止
0xdead10cc程序退到后台时还占用系统资源，如通讯录被系统终止
0xdeadfa11前面也提到过，程序无响应用户强制关闭

其实，crash log里关键的信息就在backtrace，对linux有一定了解的相信对backtrace是有所了解的，其实Linux下常常利用backtrace追踪函数调用堆栈以及定位段错误

那关键的来了，把Backtrace的十六进制数据转成我们能看懂的文字，这个过程我们称之为符号化，那么我们就一步一步讲解
- 1.上述获取到log后，我们首先找到相对应的.dSYM文件，在哪呢？就在这个目录里： ~/Library/Developer/Xcode/Archives/
- 2.进入这个目录后，可能会有多个archive文件，找到对应时间的，然后右键显示包内容，可以看到，xxx.app.dSYM文件，如下图：

• 3.然后再找到上述图片Products/Applications/xxx.app文件
• 4.将上面crash log文件，xxx.app.dSYM和xxx.app文件拷贝到同一个文件里
  

  怎么确定.dSYM和.app文件是同一个编译出来的呢？
  打开终端，使用命令查看两个文件的uuid是否一致，一致则表示.dSYM文件和.app文件是相匹配的,命令如下：
  dwarfdump  –uuid xxx.app/xxx
  dwarfdump  –uuid xxx.app.dSYM/ （xxx为app name）

• 5.然后使用命令行工具symbolicatecrash来符号化crash log

  怎么找到symbolicatecrash呢？
  其实symbolicatecrash工具是Xcode自带的一个命令行工具，找它，当然是去xcode的安装目录咯
  先到xcode安装去，一层一层往下走 /Applications/Xcode.app/Contents/SharedFrameworks
  这里偷个懒不去找symbolicatecrash在哪个目录了，直接输入查找命令来找find ./ -name “symbolicatecrash”，如下图
  
  到这个目录去，把这个工具拷贝到和上述文件同一个目录
  sudo cp symbolicatecrash ~/Desktop/xxxxx/xxx

  然后就开始符号化，执行命令：
  ./symbolicatecrash appName-2016-10-26-201420.crash  appName.app.dSYM/ > xxxxx.log
  （如果执行命令出现错误:Error: “DEVELOPER_DIR” is not defined at ./symbolicatecrash,请设置环境变量:export DEVELOPER_DIR=/Applications/Xcode.app/Contents/Developer;）
  打开日志文件，你会发现，backtrace就变成我们可以读懂的代码方法和精准定位到了哪一行了，哈哈

太好用了，这样就遇到偶现的闪退，我们就可以比较轻松的定位问题，最快的定位问题，最好解决问题。

######总结
总结一下，整个过程就是，获取crash log －》找到相匹配的 app文件 －》 获取symbolicatecrash工具 －》 符号化crash文件。希望这个对大家有所帮助。