首页 > 代码库 > 使用atos分析iOS崩溃日志
使用atos分析iOS崩溃日志
当APP出现崩溃时，一般会在XCode的Device界面里面出现崩溃日志，大概像这样：
Incident Identifier: FBF87174-405D-4F1C-A745-E3D9F7858F4FCrashReporter Key: 31da19c0a9879bc6ca613ad7611c14ccebe2a82dHardware Model: iPhone4,1Process: MyProj [285]Path: /var/mobile/Applications/C6E9AF9C-ACF3-4C8D-8623-DC432CBCF1AB/MyProj.app/MyProjIdentifier: MyProjVersion: ??? (???)Code Type: ARM (Native)Parent Process: launchd [1]Date/Time: 2014-09-30 17:09:08.491 +0800OS Version: iOS 6.1.3 (10B329)Report Version: 104Exception Type: EXC_CRASH (SIGABRT)Exception Codes: 0x0000000000000000, 0x0000000000000000Crashed Thread: 0Last Exception Backtrace:0 CoreFoundation 0x323ed29e 0x3232b000 + 7952941 libobjc.A.dylib 0x3a11597a 0x3a10d000 + 351942 CoreFoundation 0x323ed1c0 0x3232b000 + 7950723 MyProj 0x0065732c 0x4000 + 66322364 libsystem_c.dylib 0x3a593e86 0x3a55b000 + 2330945 WebCore 0x3851d6be 0x3833d000 + 19678066 WebCore 0x3851d6be 0x3833d000 + 19678067 WebCore 0x383c5eb8 0x3833d000 + 5608248 WebCore 0x383c4f60 0x3833d000 + 5568969 WebCore 0x383c4de4 0x3833d000 + 55651610 WebCore 0x383c4db6 0x3833d000 + 55647011 WebCore 0x383a6a1e 0x3833d000 + 43267012 WebCore 0x383a69d4 0x3833d000 + 43259613 WebCore 0x383a69f0 0x3833d000 + 43262414 WebCore 0x383a69d4 0x3833d000 + 43259615 WebCore 0x383a69f0 0x3833d000 + 43262416 WebCore 0x383a69d4 0x3833d000 + 43259617 WebCore 0x383a69f0 0x3833d000 + 43262418 WebCore 0x383a69d4 0x3833d000 + 43259619 WebCore 0x383a69f0 0x3833d000 + 43262420 WebCore 0x383a69d4 0x3833d000 + 43259621 WebCore 0x383a69f0 0x3833d000 + 43262422 WebCore 0x383a69d4 0x3833d000 + 43259623 WebCore 0x383a69f0 0x3833d000 + 43262424 WebCore 0x383a69d4 0x3833d000 + 43259625 WebCore 0x383a69f0 0x3833d000 + 43262426 WebCore 0x383a69d4 0x3833d000 + 43259627 WebCore 0x383a69f0 0x3833d000 + 43262428 WebCore 0x383a69d4 0x3833d000 + 43259629 WebCore 0x383a69f0 0x3833d000 + 43262430 WebCore 0x383a69d4 0x3833d000 + 43259631 WebCore 0x383a69f0 0x3833d000 + 43262432 WebCore 0x383c4a4a 0x3833d000 + 55559433 WebCore 0x3835c12a 0x3833d000 + 12727434 WebCore 0x385aa944 0x3833d000 + 254598835 WebKit 0x38cf2614 0x38c6d000 + 54632436 WebCore 0x38349d30 0x3833d000 + 5252837 CoreFoundation 0x323c267e 0x3232b000 + 62015838 CoreFoundation 0x323c1f7a 0x3232b000 + 61836239 CoreFoundation 0x323c0cb2 0x3232b000 + 61355440 CoreFoundation 0x32333eb8 0x3232b000 + 3653641 CoreFoundation 0x32333d44 0x3232b000 + 3616442 WebCore 0x38347500 0x3833d000 + 4224043 libsystem_c.dylib 0x3a56c30c 0x3a55b000 + 7041244 libsystem_c.dylib 0x3a56c1d4 0x3a55b000 + 70100Thread 0 name: Dispatch queue: com.apple.main-threadThread 0 Crashed:0 libsystem_kernel.dylib 0x3a613350 0x3a602000 + 704801 libsystem_c.dylib 0x3a58a11e 0x3a55b000 + 1927982 libsystem_c.dylib 0x3a5c696e 0x3a55b000 + 4406863 libc++abi.dylib 0x39b64d4a 0x39b61000 + 156904 libc++abi.dylib 0x39b61ff4 0x39b61000 + 40845 libobjc.A.dylib 0x3a115a74 0x3a10d000 + 354446 libc++abi.dylib 0x39b62078 0x39b61000 + 42167 libc++abi.dylib 0x39b62110 0x39b61000 + 43688 libc++abi.dylib 0x39b63594 0x39b61000 + 96209 libobjc.A.dylib 0x3a1159cc 0x3a10d000 + 3527610 CoreFoundation 0x32333f1c 0x3232b000 + 3663611 CoreFoundation 0x32333d44 0x3232b000 + 3616412 GraphicsServices 0x35f0c2e6 0x35f07000 + 2122213 UIKit 0x342492fc 0x341f2000 + 35711614 MyProj 0x00054b9a 0x4000 + 33065015 MyProj 0x00009884 0x4000 + 22660Thread 1 name: Dispatch queue: com.apple.libdispatch-managerThread 1:0 libsystem_kernel.dylib 0x3a603648 0x3a602000 + 57041 libdispatch.dylib 0x3a533974 0x3a52b000 + 351882 libdispatch.dylib 0x3a533654 0x3a52b000 + 34388Thread 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: 0x00080010Binary Images: 0x4000 - 0x853fff +MyProj armv7 <3559ce647eda37a9a26f9aecbf7b6923> /var/mobile/Applications/C6E9AF9C-ACF3-4C8D-8623-DC432CBCF1AB/MyProj.app/MyProj0x2fe22000 - 0x2fe42fff dyld armv7 <280610df5ed43ec7aa00629a27009302> /usr/lib/dyld0x31321000 - 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文件直接把它转译成可以读懂的类名和方法名。
使用atos分析iOS崩溃日志
声明：以上内容来自用户投稿及互联网公开渠道收集整理发布，本网站不拥有所有权，未作人工编辑处理，也不承担相关法律责任，若内容有误或涉及侵权可进行投诉： 投诉/举报 工作人员会在5个工作日内联系你，一经查实，本站将立刻删除涉嫌侵权内容。