使用atos分析iOS崩溃日志
当APP出现崩溃时，一般会在XCode的Device界面里面出现崩溃日志，大概像这样：
Incident Identifier: FBF87174-405D-4F1C-A745-E3D9F7858F4F
CrashReporter Key: 31da19c0a9879bc6ca613ad7611c14ccebe2a82d
Hardware Model: iPhone4,1
Process: MyProj [285]
Path: /var/mobile/Applications/C6E9AF9C-ACF3-4C8D-8623-DC432CBCF1AB/MyProj.app/MyProj
Identifier: MyProj
Version: ??? (???)
Code Type: ARM (Native)
Parent Process: launchd [1]
Date/Time: 2014-09-30 17:09:08.491 +0800
OS Version: iOS 6.1.3 (10B329)
Report Version: 104
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Crashed Thread: 0
Last Exception Backtrace:
0 CoreFoundation 0x323ed29e 0x3232b000 + 795294
1 libobjc.A.dylib 0x3a11597a 0x3a10d000 + 35194
2 CoreFoundation 0x323ed1c0 0x3232b000 + 795072
3 MyProj 0x0065732c 0x4000 + 6632236
4 libsystem_c.dylib 0x3a593e86 0x3a55b000 + 233094
5 WebCore 0x3851d6be 0x3833d000 + 1967806
6 WebCore 0x3851d6be 0x3833d000 + 1967806
7 WebCore 0x383c5eb8 0x3833d000 + 560824
8 WebCore 0x383c4f60 0x3833d000 + 556896
9 WebCore 0x383c4de4 0x3833d000 + 556516
10 WebCore 0x383c4db6 0x3833d000 + 556470
11 WebCore 0x383a6a1e 0x3833d000 + 432670
12 WebCore 0x383a69d4 0x3833d000 + 432596
13 WebCore 0x383a69f0 0x3833d000 + 432624
14 WebCore 0x383a69d4 0x3833d000 + 432596
15 WebCore 0x383a69f0 0x3833d000 + 432624
16 WebCore 0x383a69d4 0x3833d000 + 432596
17 WebCore 0x383a69f0 0x3833d000 + 432624
18 WebCore 0x383a69d4 0x3833d000 + 432596
19 WebCore 0x383a69f0 0x3833d000 + 432624
20 WebCore 0x383a69d4 0x3833d000 + 432596
21 WebCore 0x383a69f0 0x3833d000 + 432624
22 WebCore 0x383a69d4 0x3833d000 + 432596
23 WebCore 0x383a69f0 0x3833d000 + 432624
24 WebCore 0x383a69d4 0x3833d000 + 432596
25 WebCore 0x383a69f0 0x3833d000 + 432624
26 WebCore 0x383a69d4 0x3833d000 + 432596
27 WebCore 0x383a69f0 0x3833d000 + 432624
28 WebCore 0x383a69d4 0x3833d000 + 432596
29 WebCore 0x383a69f0 0x3833d000 + 432624
30 WebCore 0x383a69d4 0x3833d000 + 432596
31 WebCore 0x383a69f0 0x3833d000 + 432624
32 WebCore 0x383c4a4a 0x3833d000 + 555594
33 WebCore 0x3835c12a 0x3833d000 + 127274
34 WebCore 0x385aa944 0x3833d000 + 2545988
35 WebKit 0x38cf2614 0x38c6d000 + 546324
36 WebCore 0x38349d30 0x3833d000 + 52528
37 CoreFoundation 0x323c267e 0x3232b000 + 620158
38 CoreFoundation 0x323c1f7a 0x3232b000 + 618362
39 CoreFoundation 0x323c0cb2 0x3232b000 + 613554
40 CoreFoundation 0x32333eb8 0x3232b000 + 36536
41 CoreFoundation 0x32333d44 0x3232b000 + 36164
42 WebCore 0x38347500 0x3833d000 + 42240
43 libsystem_c.dylib 0x3a56c30c 0x3a55b000 + 70412
44 libsystem_c.dylib 0x3a56c1d4 0x3a55b000 + 70100
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 libsystem_kernel.dylib 0x3a613350 0x3a602000 + 70480
1 libsystem_c.dylib 0x3a58a11e 0x3a55b000 + 192798
2 libsystem_c.dylib 0x3a5c696e 0x3a55b000 + 440686
3 libc++abi.dylib 0x39b64d4a 0x39b61000 + 15690
4 libc++abi.dylib 0x39b61ff4 0x39b61000 + 4084
5 libobjc.A.dylib 0x3a115a74 0x3a10d000 + 35444
6 libc++abi.dylib 0x39b62078 0x39b61000 + 4216
7 libc++abi.dylib 0x39b62110 0x39b61000 + 4368
8 libc++abi.dylib 0x39b63594 0x39b61000 + 9620
9 libobjc.A.dylib 0x3a1159cc 0x3a10d000 + 35276
10 CoreFoundation 0x32333f1c 0x3232b000 + 36636
11 CoreFoundation 0x32333d44 0x3232b000 + 36164
12 GraphicsServices 0x35f0c2e6 0x35f07000 + 21222
13 UIKit 0x342492fc 0x341f2000 + 357116
14 MyProj 0x00054b9a 0x4000 + 330650
15 MyProj 0x00009884 0x4000 + 22660
Thread 1 name: Dispatch queue: com.apple.libdispatch-manager
Thread 1:
0 libsystem_kernel.dylib 0x3a603648 0x3a602000 + 5704
1 libdispatch.dylib 0x3a533974 0x3a52b000 + 35188
2 libdispatch.dylib 0x3a533654 0x3a52b000 + 34388
Thread 0 crashed with ARM Thread State (32-bit):
r0: 0x00000000 r1: 0x00000000 r2: 0x00000000 r3: 0x3c0dc534
r4: 0x00000006 r5: 0x3c0dcb88 r6: 0x00eaf164 r7: 0x2fdffa14
r8: 0x00eaf140 r9: 0x00000400 r10: 0xffffffff r11: 0x00000005
ip: 0x00000148 sp: 0x2fdffa08 lr: 0x3a58a123 pc: 0x3a613350
cpsr: 0x00080010
Binary Images:
0x4000 - 0x853fff +MyProj armv7 <3559ce647eda37a9a26f9aecbf7b6923> /var/mobile/Applications/C6E9AF9C-ACF3-4C8D-8623-DC432CBCF1AB/MyProj.app/MyProj
0x2fe22000 - 0x2fe42fff dyld armv7 <280610df5ed43ec7aa00629a27009302> /usr/lib/dyld
0x31321000 - 0x313f2fff RawCamera armv7 <8752cce31e8e3ceab5d88c84e3481db2> /System/Library/CoreServices/RawCamera.bundle/RawCamera
有的时候日志里面会给出详细的类和方法名称，但是有的时候给出的是像这种二进制类型的东西，我们需要把它人工转换为可以看得懂的类和方法名称，即所谓的符号化。
有一点需要注意的是，崩溃日志、.APP包和.dSYM文件是严格对应的，一个崩溃日志只有和对应的的.APP包和.dSYM文件在一起的时候才能够被符号化，所以在应用程序打包的时候，保留对应的.ARCHIVER文件是一个相当好的办法。
1：.APP包和.dSYM文件的取得
这个比较简单，在对应的.ARCIVER文件里面，点击『显示包内容』，就可以直接看见这两个文件了，拷到其他地方备用。
.dSYM文件拷出来以后，在.dSYM里面还有一个MyProj文件，也拷出来备用。
2：如何查看日志、.APP包和.dSYM文件的对应关系
打开TERMINAL，进入.APP和.dSYM文件所在的目录，输入以下命令：
$ dwarfdump -u MyProj.app/MyProj
即可以看到MyProj.app对应的UUID
如果输入命令
$ dwarfdump -u MyProj
则可查看.dSYM文件对应的UUID
定位到崩溃日志的Binary Images行的第一行，你的工程名后面用尖括号围起来的那一圈就是日志文件对应的UUID，两个UUID一定要对应起来才可以。
3：用atos手动符号化日志文件
定位到.APP和.dSYM文件所在的目录，打开TERMINAL，输入：
xcrun atos -arch armv7 -o MyProj 0xXXXXXXXX(你想要解析的地址)
这里所说到的地址，就是
3 MyProj 0x0065732c 0x4000 + 6632236
日志文件这一行里面的0x0065732c，atos可以通过.dSYM文件直接把它转译成可以读懂的类名和方法名。
