iOS调试之 crash log分析

一、crash log的获取

当你的app
在三哥大上crash的时候,会在大哥大上自动生成一个崩溃日志,也就是大家说的Crash
Log

CrashLog的岗位位于:
iPhone设备的var/mobile/Library/Logs/CrashReporter

咱俩要赢得的就是设备中的这一个CrashLog

1、获取用户的 crash log

小心。这里的用户指的是你的app已经上架到AppStore上后的用户。

作为开发者,你想要获取到您的用户的夭折日志的话就得经过 iTunes Connect
了。在 iTunes Connect 上的
Manage Your Applications -> View Details -> Crash Reports

这种形式有个前提,就是用户设备同意上传相关音信,打开了诊断与用量那些选项设置->隐私->诊断与用量
(由于作者还未有app上架,所以这一个情势笔者未用过,so 就此打住。
希望有用过的大牛来拍砖或者补充,Thx)

2、获取测试机的crash log

诸多测试人员在测试途中,或者开发者在自测的中途,会遭遇APP crash的气象。

诚如的bug,一个通关的测试可以提交明确的重现步骤让开发者清晰地通晓bug原因;

也有诸多bug,很多时候是偶现的,很可能不能再度再次出现出来,不可以重现出来的bug是开发者感冒的,测试一般会给出bug的截图和复发步骤;

而一般crash是相比严重的问题了(所以相对无法当什么都没爆发过,不然会被打的233),那么些时候崩溃日志就越是首要了,把崩溃日志send给开发人士,如此才能让开发者急迅稳定到不当的案由和职务。

这就是说测试怎么样拿到crash日志呢?

艺术一:连接电脑,通过iTools高级选项来博取崩溃日志(Mac版的找不到高档选项T.T,望赐教补充)

iOS崩溃日志分析_itools.png

形式二:连接电脑,去本地目录找

Mac : ~/Library/Logs/CrashReporter/MobileDevice/<DEVICE_NAME>

Windows : C://Users/<USERNAME>/AppDataRoamingApple/ComputerLogsCrashReporterMobileDevice/<DEVICE_NAME>/
其一时候你会意识一大堆的.crash文件和.ips文件

iOS崩溃日志分析_finder.png

情势三:通过Xcode获取到崩溃日志,方法是Xcode->Window->Devices

iOS崩溃日志分析_devices(1).png


二、Crash Log的符号化

得到到了.crash或者.ips文件的时候(憋纠结这六个公文有咋样差,改下后缀名就ok),用文件编辑器打开文件是一堆十六进制的内存地址,你会心烦的意识压根看不懂。

log(脱敏后有点丑).png

Q:十六进制内存地址可以改成看得懂的么?

A:当然,将那多少个十六进制地址转化成方法名称和行数的历程称之为Symbolication(符号化)。符号化很粗略,只要您把您的.crash文件拉到上边提到过的Xcode的device
log里面,然后几分钟后就会符号化。不过此间有个前提,就是以此爆发crash的本子包必须是您协调的Xcode里面Archive出来的(这么些是苹果自带的点子,会自动检测是否含有相当的.dSYM文件和运用二进制文件)。

Q:那如若只要在新电脑上也想符号化怎么做?

答案是,只有相匹配的.dSYM文件和采纳二进制文件就可以符号化。必需完全匹配才行。否则,日志将不可能被全然符号化。

.dSYM文件地方在编的.xcarchive的包内容之中

上图是.dSYM文件的职位,应用的二进制文件就是打的包得.ipa后缀改成.zip,然后解压后其中有个.app文件就是利用的二进制文件。
将.dSYM文件与.app文件
和crash文件放一个索引下,然后再用deviceLog方法就可以符号化了。
另外还有此外符号化iOS
Crash文件的3种方法
有大牛已经组成得不行好了,给个链接,这里就不赘述了。
符号化将来是这么的~

粉红色的都是app的名字

如此看起来就翻番爽了\_

三、Crash Log的分析

接下去就让大家对曾经符号化以后的crash文件举办解析。
网上已部分分类相比多,我这边直接把自己眼前相似找crash原因的模块映现出来,其他的就留待各位自己去商量了,分别是设备和crash信息、卓殊音讯、线程音讯
1、首先是设备和crash音信

Incident Identifier: F3573A...E2F244A              //crash的id
CrashReporter Key:   cc2298...es77eeb              //crash的设备id
Hardware Model:      iPhone7,2                     //手机型号
Process:             [AppName] [1816]              //APP的名字[进程的id]
Path:                /private/.../Application...   //APP的位置
Identifier:          com....                       //bundle ID
Version:             14 (2.3.5)                    //版本号
Code Type:           ARM-64 (Native)               //app的应用架构之类不大清楚,^_^
Parent Process:      launchd [1]

Date/Time:           2015-10-26 15:03:29.29 +0800    //crash发生时间
Launch Time:         2015-10-26 14:58:28.28 +0800    //进入应用时间
OS Version:          iOS 9.1 (13B143)                //iOS版本
Report Version:      105

当你有恢宏的crash文件的时候,你就足以对crash文件里面的 Hardware
Model,Version , OS
Version等开展分拣,就足以获知到不少新闻,比如说,你会分晓crash一般暴发原因是因为手机型号,还是App版本,或者仍然手机版本的缘由。(笔者暂时没碰过大量的crash文件,所以只能纸上谈兵了\_

2、其次是老大信息

Exception Type:  EXC_BAD_ACCESS (SIGABRT)                      //异常的类型
Exception Subtype: KERN_INVALID_ADDRESS at 0x0000000000000118  //异常子类型
Triggered by Thread:  0                    //异常发生的线程(0为主线程,其他为子线程)

3、线程消息

Last Exception Backtrace:
0   CoreFoundation                  0x182780f48 __exceptionPreprocess + 124
1   libobjc.A.dylib                 0x197333f80 objc_exception_throw + 56
2   CoreFoundation                  0x182780e90 +[NSException raise:format:] + 120
3   [AppName]                           0x100c42a40 UmengSignalHandler + 144
4   libsystem_platform.dylib        0x197d6193c _sigtramp + 52
5   [AppName]                           0x1005d9f38 CScopePtr<IAVGAudioLogic>::operator IAVGAudioLogic*<IAVGAudioLogic>() (xprefc.h:165)
6   [AppName]                           0x1005d3b8c tencent::av::AVRoomMultiImpl::GetAudioLogic() (av_room_multi_impl.h:119)
7   [AppName]                           0x10057076c tencent::av::AVAudioCtrlImpl::SetAudioOutputMode(int) (av_audio_ctrl_impl.cpp:443)
8   [AppName]                           0x10044dc3c -[AVBasicManager changeSpeakerMode:] (AVManager.mm:525)
9   [AppName]                           0x100296e1c -[KTQAVRoom enableSpeakerMode:] (KTQAVRoom.m:345)
10  [AppName]                           0x1002970d0 -[KTQAVRoom settingSpeaker:] (KTQAVRoom.m:362)
11  [AppName]                           0x1003d5464 -[KTChatView onAudioNotificationReceived:] (KTChatView.m:685)

恩。。。这符号化未来应该可以看懂了呢,那一个crash的问题应有是腾讯第三方的一个争论呢233

相似的话,通过丰盛新闻和线程信息就足以找到crash的由来了。

补充部分非凡类型信息

这里参考了无数信息,有众多的异常类型,有些没遭逢过,这里就厚颜摘抄过来了(这里是原文地址:iOS
Crash文件的解析
,再一次感谢大牛们的经历)

1、Exception Type

1)EXC_BAD_ACCESS

此类型的Excpetion是我们最长碰着的Crash,平常用于访问了不改访问的内存导致。一般EXC_BAD_ACCESS后边的”()”还会包含补充消息。

SIGSEGV:
平日由于重复释放对象造成,这连串型在切换了ARC将来应该早就很少见到了。
SIGABRT:
收到Abort信号退出,通常Foundation库中的容器为了珍贵情形正常会做一些检测,例如插入nil到数组中等会遇上此类错误。
SEGV:(Segmentation
Violation),代表无效内存地址,比如空指针,未起头化指针,栈溢出等;
SIGBUS:总线错误,与 SIGSEGV 不同的是,SIGSEGV 访问的是行不通地址,而
SIGBUS 访问的是行得通地址,但总线访问分外(如地址对齐问题)
SIGILL:尝试举行非法的授命,可能不被辨认或者尚未权力

2)EXC_BAD_INSTRUCTION

该类很是平常由于线程执行非法命令导致

3)EXC_ARITHMETIC

除零错误会抛出此类异常

2、Exception Code

0xbaaaaaad 此系列型的log意味着该Crash
log并非一个真正的Crash,它仅仅只是包含了全副系统某一随时的运行境况。平常能够透过并且按Home键和音量键,可能出于用户不小心触发
0xbad22222 当VOIP程序在后台太过多次的激活时,系统或者会告一段落此类程序
0x8badf00d 程序启动或者复苏时间过长被watch dog终止
0xc00010ff
程序执行大量消耗CPU和GPU的演算,导致设备过热,触发系统过热敬服被系统终止
0xdead10cc 程序退到后台时还占据系统资源,如通讯录被系统终止
0xdeadfa11 前边也论及过,程序无响应用户强制关闭

总结

末尾总括一些可能会对各位有用的博文:
1、iOS应用崩溃日志分析(这最后有一个板栗很有意思)
2、获取 iOS crash
log
(分析得很详细)
3、WWDC视频(2010年的WWDC视频)
4、官网文档——Analyzing iOS Application Crash
Reports

最末尾得PS下:笔者用的是Xcode7.1+iOS9.1

相关文章