understanding and analyzing ios application crashreports
这个TN涉及了与崩溃相关的 内存耗尽信息，堆栈信息 以及 异常编号 等信息
内存耗尽
内存不足时，虚存系统需要app的协助释放部分内存，内存不足的通知会发送给所有正在运行的app。如果内存压力依然存在，系统会终止后台进程以缓解内存压力。如果释放的内存足够，你的app仍可以运行且不会有crash report产生。否则，app将被终止且产生crash report。
low memory report与其他crash report不同在于没有应用线程的stack trace，每个进程的内存占用是由内存页数标识的，每页4K。且每个被 ios终止的进程名后面都会有一串字符 "(jettisoned）"。如果你的app名旁边有这个字串，则可以确认你的应用是因为内存占用过多而被终止的。否则则不是因为内存压力而崩溃的，这时应该寻找.crash文件。可以checkout WWDC2010 session的 Advanced Memory Analysis with Instruments
需要注意的是，泄漏和分配工具并不会跟踪显存。你需要使用VM tracker工具（instruments Allocations template中）运行app以查看显存使用量。
分析crash report
符号化
crash report 最有趣的部分是应用执行中止时应用的栈回溯信息，这与在调试器中停止执行时的栈trace类似但不同的是其中并未带符号信息（即函数方法名），你所看到的会是十六进制的地址和可执行代码，你需要将这些地址映射成符号，即源代码地址和行数。这个过程需要 上传到app store的二进制app文件及此文件对应的.dsym文件，文件需要完全匹配，否则符号化会不完全。使用 product->Archive命令可以将app与dsym文件打包到你的home/library/developer/xcode/archives目录下。
如果上传app二进制包到 appstore的时候添加了Archive则此应用的crash可以导入 xcode organizer的crash reports tab中。如果要分析开发过程中的crash可能就只能在Devices中view device logs里面查看crash了
异常码
crash log中以 Exception Codes: + 一个或多个十六进制value 为标志的行，这行是特定于处理器的代号，用于辨识crash的进一步信息
0xbaaaaaad: 当前log为整个系统的栈快照，并不是crash report文件（home+volume键可以取stack快照)
0xbad22222: VoIP app 由于重启太频繁而被ios中止
0x8badf00d:watchdog超时（大概是1分钟未向约定的数据空间写数据导致），比如app启动或者退出，或者响应系统事件 花费的时间太长。通常的原因一般是在主线程上做同步的网络操作，无论如何，耗时的操作应该从主线程中移除，以免阻塞主线程。
0xc00010ff: app由于过热引发的系统事件而被系统中止。
0xdead10cc: app由于在后台运行时hold on to 系统资源（比如地址簿数据库)
0xdeadfa11: app 被用户强制中止。用户长按 开机键直到出现“滑动关机”，然后长按home按钮。（需要注意的是，从多任务托盘中移除暂停的app并不会产生crash文件，因为一旦app暂停，ios即可随时将它中止，所以不会有crash文件产生）
