ios开发之crash日志收集，以及分析
在ios开发过程，当应用已经打包，iPhone设备经过ipa的包安装应用后，在使用过程发现crash，那么如何获取crash日志呢，现提供以下四种获取crash日志的方式:html
一、打开iPhone设备的设置里面的隐私中的“诊断与用量”，而后若是app崩溃了，设备会弹出提示框，用户确认以后，crash log会自动发送到苹果后台，而后用开发者帐号登录上去，能够拿到crash log。ios
二、将设备连接到mac或者windows上，同步到iTunes后再从电脑的目录下获取crash log：windows
Mac OS X：~/Library/Logs/CrashReporter/MobileDevice数组
Windows XP：C:\Documents and Settings\Application Data\Apple computer\Logs\CrashReporterxcode
Windows 7/Vista: C:\Users\计算机登陆名\AppData\Roaming\Apple Computer\Logs\CrashReporter\MobileDevice网络
三、能够经过itools工具获取crash log，打开itools，链接iPhone设备，按照下图提示，获取crash logapp
四、经过xcode获取crash log，打开xcode，链接iPhone设备，打开window下的device，能够看到你链接的设备，能够看到以下界面,点击view device logs，能够看到全部的日志，选中日志，点击右键能够处处日志工具
2、解析crash logs测试
经网上搜索解析crash logs的三种，因为未经测试，因此没有记录下，详见能够：http://www.cocoachina.com/industry/20140514/8418.htmlui
经测试可用的方法为atos -o XXX.app.dSYM/Contents/Resources/DWARF/XXX -l address0 targetAddress
其中：
a、XXX是appname
b、address0是当前进程在内存中加载的起始地址，至于为何须要这个，那就有必要去了解下ASLR
获取地址参下图：
binary Images后面第一个即为基地址（内存中加载的起始地址）
c、targetAddress就是你想要符号化的地址 ，此处通常选取以下
3 appName 0x000f462a 0x4000 + 984618
4 appName 0x00352aee 0x4000 + 3468014
以appName开头的地址
2、常见的Crash类型
一、Watchdog timeout
Exception Code：0x8badf00d， 不太直观，能够读成“eat bad food”，意思是don‘t block main thread
紧接着下面会有一段描述：
Application Specific Information：
com.xxx.yyy failed to resume in time
对于此类Crash，咱们应该去审视本身App初始化时作的事情是否正确，是否在主线程请求了网络，或者其余耗时的事情卡住了正常初始化流程。
一般系统容许一个App从启动到能够相应用户事件的时间最多为5S，若是超过了5S，App就会被系统终止掉。在Launch，resume，suspend，quit时都会有相应的时间要求。在Highlight Thread里面咱们能够看到被终止时调用到的位置，xxxAppDelegate加上行号。
PS. 在链接Xcode调试时为了便于调试，系统会暂时禁用掉Watchdog，因此此类问题的发现须要使用正常的启动模式。
二、User force-quit
Exception Codes: 0xdeadfa11, deadfall
这个强制退出跟咱们平时所说的kill掉后台任务操做还不太同样，一般在程序bug形成系统没法响应时能够采用长按电源键，当屏幕出现关机确认画面时按下Home键便可关闭当前程序。
三、Low Memory termination
跟通常的Crash结构不太同样，一般有Free pages，Wired Pages，Purgeable pages，largest process 组成，同事会列出当前时刻系统运行全部进程的信息。
关于Memory warning能够参看我以前写的一篇文章IOS 内存警告 Memory warning level。
App在运行过程当中，系统内存紧张时一般会先发警告，同时把后台挂起的程序终止掉，最终若是仍是内存不够的话就会终止掉当前前台的进程。
当接受到内存警告的过后，咱们应该释放尽量多的内存，Crash其实也能够看作是对App的一种保护。
四、Crash due to bugs
由于程序bug致使的Crash一般千奇百怪，很难一律而论。大部分状况经过Crash日志就能够定位出问题，固然也不排除部分疑难杂症看半天都不值问题出在哪儿。这个就只能看功底了，一点点找，老是能发现蛛丝马迹。是在看不出来时还能够求助于Google大神，总有人遇到和你同样的Bug
3、常见的Exception Type & Exception Code
一、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
除零错误会抛出此类异常