崩溃日志的获取
崩溃日志的获取：ios设备上的应用闪退之后会生成崩溃报告存储在设备上，可以通过这样几种途径获取设备上的日志
1 设备与iTunes Store同步后，会将崩溃日志保存在电脑上，在mac上存储路径是~/Library/Logs/CrashReporter/MobileDevice/，windows xp上 C:/Documents and Settings/Application Data/Apple Computer/Logs/CrashReporter/MobileDevice/DEVICE_NAME，windows vista/7 上C:/Users/AppData/Roaming/Apple Computer/Logs/CrashReporter/MobileDevice/DEVICE_NAME,可以让用户将上述位置的日志发送过来
2 安装了xcode之后，可以从device log中获取崩溃日志
3 应用提交到app store之后，可以从iTunes Connect获取到用户崩溃日志，登录到iTunes Connect之后选择Manage Your Applications，在相应应用图标下的view details按钮然后点击links部分的crash reports
崩溃日志的产生
崩溃日志的产生情况有两种：1 违反操作系统规则：比如启动恢复挂起退出时watchdog超时，用户强制退出或者低内存终止 2 应用程序异常退出 （崩溃报告内容可以参考崩溃报告）
watchdog超时
对应的错误码为0x8badf00d，应用退出时不会立即终止，而是退到后台，如果应用响应不够快，系统有可能终止此应用，并产生一个崩溃日志。这些需要响应的事件包括与下列UIApplicationDelegate方法相对应的：
application:didFinishLaunchingWithOptions:
applicationWillResignActive:
applicationDidEnterBackground:
applicationWillEnterForeground:
applicationDidBecomeActive:
applicationWillTerminate:
为了避免watchdog超时，需要注意的是不要把耗时的网络操作放在主线程
用户强制退出
应用阻塞界面并停止响应之后，用户可以双击home，并将其终止，同时生成崩溃日志，但如果用户正常操作下终止应用并不会产生崩溃。通常按home退出应用之后10分钟左右应用会被系统中止，此时不产生崩溃文件。
低内存终止
前台运行的应用会拥有访问和使用内存的最高优先级，但并不意味着它可以使用所有内存：每个应用只能使用一部分可用内存。在应用要求的内存系统无法供应的时候，系统会释放后台应用的内存以满足它，这种情况下被终止的后台应用不会产生崩溃报告，如果仍然无法满足，则会中止此应用，并为其产生崩溃报告。
通常低内存崩溃报告的process和type在Xcode的日志页面都显示成"Unknown"
崩溃报告
Incident Identifier是崩溃报告的唯一标识符
CrashReporter Key 是与设备标识相对应的唯一键值，虽然它不是真正的设备标识符
Hardware Model 标识设备类型
process是进程名称，紧跟着的数字是进程ID
从Exception type开始的部分是异常信息，接着是线程栈回溯信息
各线程栈信息之后是线程状态，即线程退出时寄存器中的值
紧接着是二进制映像，即崩溃发生时加载的二进制文件
将十六进制地址转化为源代码文件名称及行数偏移的过程称为符号化，已经Archive的应用版本会保存有相应的.dSYM文件，xcode在打开有对应的.dSYM文件的崩溃文件时会自动进行符号化。注意，就算是同一份源代码，多次构建产生的应用二进制文件和.dSYM文件都会不同。
如果你使用Build 和 Archive 命令,这些文件会自动放在适当位置。 如果不是使用Build 和 Archive命令，放在Spotlight能够搜索到的位置（比如Home目录）即可
低内存闪退
低内存崩溃报告上并没有应用线程的堆栈回溯，而会显示以内存页数为单位的进程内存使用量，被iOS因释放内存页终止的进程名称后面你会看到jettisoned 字样，xcode 6.3中的低内存崩溃文件是这样
Free pages 可用内存页数，每页4KB
Purgeable pages 是那部分可被清除或重用的内存
Largest process是闪退时使用大部分内存的应用名称
Processes显示了闪退时各进程列表，还包含内存使用量。包含进程名, 进程唯一标识符, 进程使用的内存页数。最后一列是每个应用的状态。通常，发生闪退的应用的状态是 frontmost
此低内存崩溃报告中占用最大内存的进程占用内存页为166401页，即近665.6MB的内存，总共1GB的内存就这么被生吃了，难怪被终止。
此报告中，占用最大内存的进程与frontmost的进程为同一个，可以确定是其引起了低内存崩溃，当然也有内存与frontmost不一样的时候，比如SpringBoard进程是显示主屏幕应用的，双击home情况下会出现，而且它一直是活动的，其有可能会成为最大进程。
当然，为了避免这样的崩溃发生，在收到低内存通知时，尽可能多地空出内存是不二选择。
