一、崩溃日志的获取
1、iOS设备可以直接查看
路径：
ios 10之后：设置 -> 隐私 -> 分析 -> 数据分析
ios 10之前：设置 -> 隐私 -> 诊断与用量
2、链接设备到电脑 Itunes同步后，日志会保存在电脑上
mac路径：~/Library/Logs/CrashReporter/MobileDevice/
可以看到所有和该电脑同步过的设备的崩溃日志(.crash文件)
为什么有部分crash无法收集到？
3、xcode获取
xcode查看设备日志并导出日志
Window - Devices - 选择设备 - 点击View Device Logs -> All logs可以看到所有的崩溃日志。
4、线上的崩溃，没有设备
1、三方：bugly、crashlytics
2、后台、异步线程将上面描述的捕获到的崩溃上传服务器
3、线上的ITC上可能会有部分日志，可以通过Xcode同步下来崩溃与能耗日志：Xcode Window - Organizer - Crashes
二、崩溃日志的解析
1、崩溃日志的实例
下面是一份测试过程产生的崩溃日志
//进程信息
Incident Identifier: 3C3F8BF8-3099-4E82-92E1-8690212E8FF9
CrashReporter Key: bb5f9839ae661ab755f25eff65fee8fd41369628
Hardware Model: iPod5,1
Process: demo [973]
Path: /private/var/containers/Bundle/Application/0D3657DE-DE1E-4FF0-A0F7-C09EBC002763/demo.app/demo
Identifier: com.yanghuang.demo
Version: 17 (1.1.9)
Code Type: ARM (Native)
Parent Process: launchd [1]
//基本信息
Date/Time: 2017-08-22 16:11:49.49 +0800
Launch Time: 2017-08-22 16:11:40.40 +0800
OS Version: iOS 9.3.5 (13G36)
Report Version: 104
//异常
Exception Type: EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000001, 0x00000000e7ffdefe
Triggered by Thread: 0
Filtered syslog:
None found
//线程回溯
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 libswiftCore.dylib 0x0033788c 0x1ac000 + 1620108
//二进制映像
Binary Images0x24000 - 0x33fff demo armv7 /var/containers/Bundle/Application/0D3657DE-DE1E-4FF0-A0F7-C09EBC002763/demo.app/demo
0x140000 - 0x15bfff Masonry armv7 <9615e97c54d335f7821568396c65d324> /var/containers/Bundle/Application/0D3657DE-DE1E-4FF0-A0F7-C09EBC002763/demo.app/Frameworks/Masonry.framework/Masonry
1.进程信息
第一部分是闪退进程的相关信息。
Incident Identifier 是崩溃报告的唯一标识符。
CrashReporter Key 是与设备标识相对应的唯一键值。虽然它不是真正的设备标识符，但也是一个非常有用的情报:如果你看到100个崩溃日志的CrashReporter Key值都是相同的，或者只有少数几个不同的CrashReport值，说明这不是一个普遍的问题，只发生在一个或少数几个设备上。
Hardware Model 标识设备类型。 如果很多崩溃日志都是来自相同的设备类型，说明应用只在某特定类型的设备上有问题。
Process 是应用名称。中括号里面的数字是闪退时应用的进程ID。
2.基本信息
这部分给出了一些基本信息，包括闪退发生的日期和时间，设备的iOS版本。如果有很多崩溃日志都来自iOS 6.0，说明问题只发生在iOS 6.0上。
Version: 崩溃进程的版本号. 这个值包含在 CFBundleVersion and CFBundleVersionString中.
Code Type: 崩溃日志所在设备的架构. 会是ARM-64, ARM, x86-64, or x86中的一个.
OS Version: 崩溃发生时的系统版本
3.异常信息
异常信息会列出异常的类型、位置。
在这部分，你可以看到闪退发生时抛出的异常类型。还能看到异常编码和抛出异常的线程。根据崩溃报告类型的不同，在这部分你还能看到一些另外的信息。
Exception Codes: 处理器的具体信息有关的异常编码成一个或多个64位进制数。通常情况下，这个区域不会被呈现，因为将异常代码解析成人们可以看懂的描述是在其它区域进行的。
Exception Subtype: 供人们可读的异常代码的名字
Exception Message: 从异常代码中提取的额外的可供人们阅读的信息.
Exception Note: 不是特定于一个异常类型的额外信息.如果这个区域包含SIMULATED (这不是一个崩溃)然后进程没有崩溃，但是被watchdog杀掉了
Termination Reason: 当一个进程被终止的时的原因。
Triggered by Thread: 异常所在的线程.
4.线程回溯
这部分提供应用中所有线程的回溯日志。 回溯是闪退发生时所有活动帧清单。它包含闪退发生时调用函数的清单。看下面这行日志:
2 demo 0x00029288 0x24000 + 21128
它包括四列:
帧编号—— 此处是2。
二进制库的名称 ——此处是 demo.
调用方法的地址 ——此处是 0x00029288.
第四列分为两个子列，一个基本地址和一个偏移量。此处是0×0x24000 + 21128, 第一个数字指向文件，第二个数字指向文件中的代码行。
5.二进制映像
这部分列出了闪退时已经加载的二进制文件。
如何通过.crash文件反编译得到明文的crash文件
需要文件：
1、demo.app
2、demo.app.dSYM
3、demo.crash (已获得)
4、symbolicatecrash
符号化前先检查一下三者的uuid是不是一致的,只有是一致的才能符号化成功。
查看xx.app文件的uuid的方法：
dwarfdump --uuid xxx.app/xxx (xxx工程名)
查看xx.app.dSYM文件的uuid的方法令：
dwarfdump --uuid xxx.app.dSYM (xxx工程名)
而.crash的uuid位于，crash日志中的Binary Images:中的第一行尖括号内。如：armv7<8bdeaf1a0b233ac199728c2a0ebb4165>
步骤如下:
1、首先我们找到Archives目录(/Users/用户名/Library/Developer/Xcode/Archives/2017-08-22/demo)
2、找到对应app目录、对应的Archives文件、显示包内容打开。在dSYMs文件夹中找到demo.app.dSYM
在Products->Applications文件夹中找到 demo.app
3、找到symbolicatecrash
find /Applications/Xcode.app -name symbolicatecrash -type f
//终端输入上面命令、得到一个路径，这个路径就是symbolicatecrash的路径
（或者：根据以下目录找到symbolicatecrash工具：/Applications/Xcode.app/Contents/SharedFrameworks/DVTFoundation.framework/Versions/A/Resources/symbolicatecrash）
拷贝到和上面文件同一目录
4: 在终端中输入以下命令
./symbolicatecrash -v demo.crash demo.app.dSYM
如果出现Error: "DEVELOPER_DIR" is not defined 再执行下面一句后再次执行
export DEVELOPER_DIR="/Applications/XCode.app/Contents/Developer"
然后用控制台打开你的demo.crash文件, 你就会看到编译后的crash文件, 同Xcode看到的崩溃日志一致。通过查看崩溃日志，可以轻易的找到崩溃原因并修正。
异常编码
下面是一些常见的异常编码:
0x8badf00d: 该编码表示应用是因为发生watchdog超时而被iOS终止的。 通常是应用花费太多时间而无法启动、终止或响应用系统事件。
0xbad22222: 该编码表示 VoIP 应用因为过于频繁重启而被终止。
0xdead10cc: 该代码表明应用因为在后台运行时占用系统资源，如通讯录数据库不释放而被终止 。
0xdeadfa11: 该代码表示应用是被用户强制退出的。根据苹果文档, 强制退出发生在用户长按开关按钮直到出现 “滑动来关机”, 然后长按 Home按钮。强制退出将产生 包含0xdeadfa11 异常编码的崩溃日志, 因为大多数是强制退出是因为应用阻塞了界面。
EXC_CRASH // SIGABRT: 进程异常退出。该异常类型崩溃最常见的原因是未捕获的Objective-C和C++异常和调用abort()。如果他们需要太多的时间来初始化，程序将被终止，因为触发了看门狗。如果是因为启动的时候被挂起，所产生的崩溃报告异常类型(Exception Subtype)将是launch_hang。
EXC_BREAKPOINT // SIGTRAP：进程试图执行非法或未定义指令。这个进程可能试图通过一个配置错误的函数指针，跳到一个无效的地址。
SIGSEGV、SIGBUS 这些在前面捕获异常的内容有描述
信号中断(SGIABRT)、
非法指令信号(SIGILL)、
总线错误信号(SIGBUS)、
段错误信号(SIGSEGV)、
访问一个已经释放的对象(EXC_BAD_ACCESS)
注意: 在后台任务列表中关闭已挂起的应用不会产生崩溃日志。 一旦应用被挂起，它何时被终止都是合理的。所以不会产生崩溃日志。
http://www.cocoachina.com/articles/25704