崩溃日志的产生
iOS中运行App过程中如果发生程序崩溃，会生成一个崩溃日志文件。这个文件会保存的特定系统目录下，扩展名是crash。当手机连接到iTunes时，会将该文件同步到电脑上。
在Mac系统中这些文件会同步到“~/Library/Logs/CrashReporter/MobileDevice”下。
小田提示：右击finder -》前往文件夹 上面的拷贝-》前往 就可以看到
/或者连接设备 command+shift+2 看log
崩溃日志的上传
iOS中崩溃日志是可以上传的App Store的服务器，并由开发者查看的。用户可以通过系统设置中的“通用－诊断与用量”来设定是否上传崩溃日志。同时开发者也可以通过捕获异常信号自己定制异常上报。
崩溃日志的格式
一般崩溃日志头部有如下字段
ExceptionType: EXC_BAD_ACCESS (SIGSEGV)ExceptionCodes: KERN_INVALID_ADDRESS at0x20000008Crashed Thread:0
其中Exception Type是异常类型，Exception Codes是异常代码。Crashed Thread指示异常的线程编号。上面表示Crash的线程编号是0（主线程的线程编号是0）。
常见类型：1.1 低内存闪退
我们使用Xcode 5和iOS 7的设备模拟一次低内存闪退，然后通过Organizer查看产生的crash日志，可以发现Process和Type都为Unknown：
第一部分是崩溃信息，包括识别标识、软硬件信息和时间信息等。
第二部分是内存页分配信息，以及当前占用内存最多的进程，上图中为crashTypeDemo。
第三部分是具体的进程列表，描述着每个进程使用内存的情况以及当前状态。在较早的版本中可以在某些进程后面看到“jettisoned”字样，表明这些进程使用过多内存被终止了，而现在我们看到的是“vm-pageshortage”字样。
当iOS检测到内存过低时，它（的VM系统）会发出低内存警告通知，尝试回收一些内存；如果情况没有得到足够的改善，iOS会终止后台应用以回收更多内存；最后，如果内存还是不足，那么正在运行的应用可能会被终止掉。
所以，我们的应用应该合理地响应系统抛出来的低内存警告通知，对一些缓存数据和可重新创建的对象进行释放，同时要避免出现内存泄露等问题。
1.2 Watchdog超时Apple的iOS Developer Library网站上，QA1693文档中描述了Watchdog机制，包括生效场景和表现。如果我们的应用程序对一些特定的UI事件（比如启动、挂起、恢复、结束）响应不及时，Watchdog会把我们的应用程序干掉，并生成一份响应的crash报告。
这份crash报告的有趣之处在于异常代码：“0x8badf00d”，即“ate bad food”。
1.3 用户强制退出一看到“用户强制退出”，首先可能想到的双击Home键，然后关闭应用程序。不过这种场景是不会产生crash日志的，因为双击Home键后，所有的应用程序都处于后台状态，而iOS随时都有可能关闭后台进程，所以这种场景没有crash日志。
另一种场景是用户同时按住电源键和Home键，让iPhone重启。这种场景会产生日志（仅验证过一次），但并不针对特定应用程序。
这里指的“用户强制退出”场景，是稍微比较复杂点的操作：先按住电源键，直到出现“滑动关机”的界面时，再按住Home键，这时候当前应用程序会被终止掉，并且产生一份相应事件的crash日志。通常，用户应该是遇到应用程序卡死，并且影响到了iOS响应，才会进行这样的操作——不过感觉这操作好高级，所以这样的crash日志应该比较少见。
2. 常见错误标识
2.1 Exception codes
上面“用户强制退出”的crash日志中的Exception Codes是“0xdeadfa11”，再上面“Watchdog超时”的crash日志中的Exception Codes是“0x8badf00d”，这些都是特有的Exception codes。
根据官方文档描述，至少有以下几种特定异常代码：
0x8badf00d错误码：Watchdog超时，意为“ate bad food”。
0xdeadfa11错误码：用户强制退出，意为“dead fall”。
0xbaaaaaad错误码：用户按住Home键和音量键，获取当前内存状态，不代表崩溃
0xbad22222错误码：VoIP应用（因为太频繁？）被iOS干掉。
0xc00010ff错误码：因为太烫了被干掉，意为“cool off”。
0xdead10cc错误码：因为在后台时仍然占据系统资源（比如通讯录）被干掉，意为“dead lock”。
2.2 Exception types
查看我们的crash分析报告邮件，会发现最经常遇到的错误类型是SEGV（Segmentation Violation，段违例），表明内存操作不当，比如访问一个没有权限的内存地址。
当我们收到SIGSEGV信号时，可以往以下几个方面考虑：
访问无效内存地址，比如访问Zombie对象；
尝试往只读区域写数据；
解引用空指针；
使用未初始化的指针；
栈溢出；
此外，还有其它常见信号：
SIGABRT：收到Abort信号，可能自身调用abort()或者收到外部发送过来的信号；
SIGBUS：总线错误。与SIGSEGV不同的是，SIGSEGV访问的是无效地址（比如虚存映射不到物理内存），而SIGBUS访问的是有效地址，但总线访问异常（比如地址对齐问题）；
SIGILL：尝试执行非法的指令，可能不被识别或者没有权限；
SIGFPE：Floating Point Error，数学计算相关问题（可能不限于浮点计算），比如除零操作；
SIGPIPE：管道另一端没有进程接手数据；
代码中如何捕获，苹果给我们提供的Api
小田提示
启动的时候加上这句话NSSetUncaughtExceptionHandler (&UncaughtExceptionHandler);
voidUncaughtExceptionHandler(NSException*exception) {
NSArray*arr = [exceptioncallStackSymbols];//得到当前调用栈信息
NSString*reason = [exceptionreason];//非常重要，就是崩溃的原因
NSString*name = [exceptionname];//异常类型
NSLog(@"exception type : %@ \n crash reason : %@ \n call stack info : %@", name, reason, arr);
}
对于日志怎么出去，很简单。
抛出错误的代码
[cpp]view plaincopy
//如果返回的报文是错误信息，则抛出错误
if([outParams count] <= 0)
{
[NSException raise:@"WebService error"format:@"%@", returnJson4SOAP];
}
在调用中捕获错误代码
[cpp]view plaincopy
//从soap 信息中解析出CusotmerDetail 对象
@try
{
customerDetail = [[[SoapRtnJsonParser alloc] init] parse2CustomerDtail:[returnSoapXML dataUsingEncoding:NSUTF8StringEncoding]];
}@catch(NSException * e) {
NSLog(@"Exception: %@", e);
UIAlertView * alert =
[[UIAlertView alloc]
initWithTitle:@"错误"
message: [[NSString alloc] initWithFormat:@"%@",e]
delegate:self
cancelButtonTitle:nil
otherButtonTitles:@"OK", nil];
[alert show];
[alert release];
return;
}
