iOS崩溃日志的处理

在处理iOS崩溃日志之前我们先来了解一下崩溃日志里面的一些东西：

第一部分：进程信息Incident Identifier: D48383A7-0EA6-48C1-B623-4D798CEXXXXX
CrashReporter Key: 81f2c9c2093808a1832227d2b146164108f2bxxx
Hardware Model: iPhone8,2
Process: guizhouXXX [3388]
Path: /private/var/containers/Bundle/Application/F3D1AE65-1EFB-423C-AE12-E6DC3FA88XXX/guizhouXXX.app/guizhouXXX
Identifier: com.XXX.XXXXX
Version: 1 (1.1.5)
Code Type: ARM-64 (Native)
Role: Non UI
Parent Process: launchd [1]
Coalition: com.XXX.XXXXX [949]

Incident Identifier:崩溃日志的唯一标识

CrashReporter Key:与设备标识相对应的唯一键值。

Hardware Model:设备类型

Process:             guizhouXXX [3388]:应用名称[闪退时的进程ID]

第二部分:基本信息
Date/Time: 2016-09-30 11:40:14.5463 +0800
Launch Time: 2016-09-29 18:03:33.8821 +0800
OS Version: iPhone OS 10.0.1 (14A403)
Report Version: 104第二部分的信息不用多说，大家应该都能看懂
第三部分：异常信息，这一部分比较重要，这一部分告诉你崩溃的类型，以及崩溃的线程、异常编码等...Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY
Triggered by Thread: 0
第四部分:进程信息，以及崩溃的进程

Thread 0 name:  Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0   libsystem_kernel.dylib        	0x00000001919b2014 0x191993000 + 126996
1   libsystem_pthread.dylib       	0x0000000191a79460 0x191a74000 + 21600
2   libsystem_c.dylib             	0x00000001919263f4 0x1918c3000 + 406516
3   libc++abi.dylib               	0x00000001913f12d4 0x1913f0000 + 4820
4   libc++abi.dylib               	0x000000019140ecc0 0x1913f0000 + 126144
5   libobjc.A.dylib               	0x000000019141c844 0x191414000 + 34884
6   libc++abi.dylib               	0x000000019140b66c 0x1913f0000 + 112236
7   libc++abi.dylib               	0x000000019140b234 0x1913f0000 + 111156
8   libobjc.A.dylib               	0x000000019141c71c 0x191414000 + 34588
9   CoreFoundation                	0x00000001928be0bc 0x1928b5000 + 37052
10  GraphicsServices              	0x0000000194341198 0x194335000 + 49560
11  UIKit                         	0x0000000198897818 0x19881d000 + 501784
12  UIKit                         	0x0000000198892550 0x19881d000 + 480592
13  guizhouXXX                    	0x00000001000e5134 0x100038000 + 708916
14  libdyld.dylib                 	0x00000001918a05b8 0x19189c000 + 17848

Thread 1 name:  com.apple.uikit.eventfetch-thread
Thread 1:
0   libsystem_kernel.dylib        	0x000000019199416c 0x191993000 + 4460
1   libsystem_kernel.dylib        	0x0000000191993fdc 0x191993000 + 4060
2   CoreFoundation                	0x0000000192991cec 0x1928b5000 + 904428
3   CoreFoundation                	0x000000019298f908 0x1928b5000 + 895240
4   CoreFoundation                	0x00000001928be048 0x1928b5000 + 36936
5   Foundation                    	0x00000001933ccb1c 0x1933c0000 + 51996
6   Foundation                    	0x00000001933ed60c 0x1933c0000 + 185868
7   UIKit                         	0x000000019920ce6c 0x19881d000 + 10419820
8   Foundation                    	0x00000001934ca50c 0x1933c0000 + 1090828
9   libsystem_pthread.dylib       	0x0000000191a77860 0x191a74000 + 14432
10  libsystem_pthread.dylib       	0x0000000191a77770 0x191a74000 + 14192
11  libsystem_pthread.dylib       	0x0000000191a74dbc 0x191a74000 + 3516

从进程信息中我们可以明确的看到是那一个进程崩溃了，以及崩溃的时候加载了那些库，

看了这些崩溃信息我们并不知道是崩溃在哪一个文件的那一行代码，下面介绍如何处理崩溃日志。

一、首先我们需要找到和崩溃日志相对应的dSYM文件，这个文件很好找，一行代码解决cd ~/Library/Developer/Xcode/Archives/yyyy-mm-dd/appname.xcarchive/dSYMs/appname.app.dSYM/Contents/Resources/DWARF然后在当前文件下执行

atos -arch arm64 -o guizhouXXX
 0x00000001000e5134

这里需要讲解一下这是使用arm64还是arm7在第一部分我们就可以看到CPU对应的是arm64就是用arm64，是arm7就使用arm7，地址就是崩溃线程应用名称对应的地址，

执行过后就能获取到是哪一个文件的那一行出现 崩溃，一般在处理崩溃日志之前我们需要查看一下崩溃日志的Incident Identifier是否和dSYM的UUID是否相同，

二、如何查看dSYM的UUID

dwarfdump --uuid xx.app.dSYM，执行这段代码就能得到UUID一般会等到两个UUID这两个UUID分别是arm64和arm7的。