【iOS】崩溃收集和解析

背景

在日常开发中,app难免会发生崩溃。简单的崩溃还好说,复杂的崩溃就需要我们通过解析Crash文件来分析了,解析Crash文件在iOS开发中是比较常见的。

获取崩溃信息方式

在iOS中获取崩溃信息的方式有很多,比较常见的是使用友盟、云测、百度等第三方分析工具,或者自己收集崩溃信息并上传公司服务器。
下面列举一些我们常用的崩溃分析方式:

  • 使用友盟、云测、百度等第三方崩溃统计工具。
  • 自己实现应用内崩溃收集,并上传服务器。
  • Xcode-Devices中直接查看某个设备的崩溃信息。
  • 使用苹果提供的Crash崩溃收集服务。(少用) Xcode->Window->Organizer->Crashes
  1. 使用苹果提供的Crash崩溃收集服务
    官方提供的线上包崩溃日志的查看方法, 但是存在72小时的延迟可能, 并且需要用户配合开启"与应用开发者共享"才能获取得到。
    用户开启"与应用程序开发者共享"方法:设置-隐私-分析与改进

  2. Window->Device->View Device Logs

  3. 从手机上获取
    设置-隐私-分析与改进 这种方法最粗暴简单, 适合所有用户操作。根据"进程名+时间"的命名格式寻找到崩溃日志, 然后通过"分享"功能导出即可。

  4. 从第三方助手软件获取
    如果是越狱手机的话, 通过使用助手软件可以直接从手机里找出来

  5. 使用友盟、云测、百度、bugly等第三方崩溃统计工具
    这些第三方库主要都是通过重写UncaughtExceptionHandler()方法来收集崩溃信息,

代码收集崩溃信息

苹果给我们提供了异常处理的类,NSException类。这个类可以创建一个异常对象,也可以通过这个类获取一个异常对象。

这个类中我们最常用的还是一个获取崩溃信息的C函数,我们可以通过这个函数在程序发生异常的时候收集这个异常。

// 将系统提供的获取崩溃信息函数写在这个方法中,以保证在程序开始运行就具有获取崩溃信息的功能
  - (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
     // 将下面C函数的函数地址当做参数
     NSSetUncaughtExceptionHandler(&UncaughtExceptionHandler);
     return YES;
  }
  // 设置一个C函数,用来接收崩溃信息
  void UncaughtExceptionHandler(NSException *exception){
      // 可以通过exception对象获取一些崩溃信息,我们就是通过这些崩溃信息来进行解析的,例如下面的symbols数组就是我们的崩溃堆栈。
      NSArray *symbols = [exception callStackSymbols];
      NSString *reason = [exception reason];
      NSString *name = [exception name];
  }

我们也可以通过下面方法获取崩溃统计的函数指针:

 NSUncaughtExceptionHandler *handler = NSGetUncaughtExceptionHandler();

dSYM 符号集

  • 符号集是我们对ipa文件进行打包之后,和.app文件同级的后缀名为.dSYM的文件,这个文件必须使用Xcode进行打包才有。
  • 每一个.dSYM文件都有一个UUID,和.app文件中的UUID对应,代表着是一个应用。而.dSYM文件中每一条崩溃信息也有一个单独的UUID,用来和程序的UUID进行校对。
  • 我们如果不使用.dSYM文件获取到的崩溃信息都是不准确的。
  • 符号集中存储着文件名、方法名、行号的信息,是和可执行文件的16进制函数地址对应的,通过分析崩溃的.Crash文件可以准确知道具体的崩溃信息。

我们每次Archive一个包之后,都会随之生成一个dSYM文件。每次发布一个版本,我们都需要备份这个文件,以方便以后的调试。进行崩溃信息符号化的时候,必须使用当前应用打包的电脑所生成的dSYM文件,其他电脑生成的文件可能会导致分析不准确的问题。

当程序崩溃的时候,我们可以获得到崩溃的错误堆栈,但是这个错误堆栈都是0x开头的16进制地址,需要我们使用Xcode自带的symbolicatecrash工具来将.Crash和.dSYM文件进行符号化,就可以得到详细崩溃的信息。

dSYM 在Window -> Organizer -> archive -> xcarchive 里 一般发布成功后,把这个文件.xcarchive直接提交到代码版本库对应的版本分支里,这样就不会搞丢了

命令行工具symbolicatecrash解析Crash文件

准备symbolicatecrash .Crash .dSYM

通过Mac自带的命令行工具解析Crash文件需要具备三个文件

  • symbolicatecrash,Xcode自带的崩溃分析工具,使用这个工具可以更精确的定位崩溃所在的位置,将0x开头的地址替换为响应的代码和具体行数。
  • 我们打包时产生的dSYM文件。
  • 崩溃时产生的crash文件,例如:*.crash。

我在解析崩溃信息的时候,首先在桌面上建立一个Crash文件夹,然后将.Crash、.dSYM、symbolicatecrash放在这个文件夹中,这样进入这个文件夹下,直接一行命令就解决了。

symbolicatecrash 文件在XCode8.0以上版本时 我们可以在下面路径下可以找到

/Applications/Xcode.app/Contents/SharedFrameworks/DVTFoundation.framework/Versions/A/Resources/symbolicatecrash

选中archive的版本右击,选择Show in Finder就可以选中xcarchive 文件然后显示包内容,就可以找到dSYM文件了。
将.Crash、.dSYM、symbolicatecrash三个文件都放在我们在桌面建立的Crash文件夹中。

进行解析的工作

开启命令行工具,进入崩溃文件夹crash中

cd /Users/自己MacPro上的名字/Desktop/崩溃文件夹crash

使用命令解析Crash文件,*号指的是具体的文件名 ./symbolicatecrash {.crash文件名} {.dSYM文件名} > symbol.crash

./symbolicatecrash ./*.crash ./*.app.dSYM > symbol.crash

如果上面命令不成功,使用命令检查一下环境变量

xcode-select -print-path

返回结果:

/Applications/Xcode.app/Contents/Developer/

如果不是上面的结果,需要使用下面命令设置一下导出的环境变量,然后重复上面解析的操作。(这一步很重要)

export DEVELOPER_DIR=/Applications/XCode.app/Contents/Developer

解析完成后会生成一个新的.Crash文件,这个文件中就是崩溃详细信息。找到具体的代码崩溃。

注意,以下情况不会有崩溃信息产生:

  • 内存访问错误(不是野指针错误)
  • 低内存,当程序内存使用过多会造成系统低内存的问题,系统会将程序内存回收
  • 因为某种原因触发看门狗机制

通过Xcode查看设备崩溃信息

除了上面的系统分析工具来进行分析,如果是我们自己直接使用手机连接崩溃或者崩溃之后连接手机,选择window-> devices -> 选择自己的手机 -> view device logs 就可以查看我们的崩溃信息了。

只要手机上的应用是这台电脑安装打包的,这样的崩溃信息系统已经为我们符号化好了,我们只需要进去之后等一会就行(不要相信这里面的进度刷新,并不准确),如果还是没有符号化完毕 ,我们选择文件,然后右击选择Re-Sysbomlicate就可以。

如果是使用其他电脑进行的打包,我们可以在这里面将Crash文件导出,自己通过命令行的方式进行解析。
参考 https://www.jianshu.com/p/0b6f5148dab8

单独解析crash的某个地址

配合友盟收集:友盟没有集成.dSYM文件,只能显示错误的地址,无法显示详细的信息。
友盟错误日志

-[__NSCFString containsString:]: unrecognized selector sent to instance 0x15daada0
(null)
((
    0   CoreFoundation                      0x2e55ff9b  + 154
    1   libobjc.A.dylib                     0x38d10ccf objc_exception_throw + 38
    2   CoreFoundation                      0x2e563917  + 202
    3   CoreFoundation                      0x2e562203  + 706
    4   CoreFoundation                      0x2e4b1768 _CF_forwarding_prep_0 + 24
    5   *****                               0x953b1 ***** + 594865
    6   *****                               0xa6f57 ***** + 667479
    7   UIKit                               0x30db2037  + 90
    8   UIKit                               0x30f18c45  + 120
    9   UIKit                               0x30db2037  + 90
    10  UIKit                               0x30db1fd7  + 30
    11  UIKit                               0x30db1fb1  + 44
    12  UIKit                               0x30d9d717  + 374
    13  UIKit                               0x30db1a2f  + 590
    14  UIKit                               0x30db1701  + 528
    15  UIKit                               0x30dac6cb  + 758
    16  UIKit                               0x30d818cd  + 196
    17  UIKit                               0x30d7ff77  + 7102
    18  CoreFoundation                      0x2e52b20b  + 14
    19  CoreFoundation                      0x2e52a6db  + 206
    20  CoreFoundation                      0x2e528ecf  + 622
    21  CoreFoundation                      0x2e493ebf CFRunLoopRunSpecific + 522
    22  CoreFoundation                      0x2e493ca3 CFRunLoopRunInMode + 106
    23  GraphicsServices                    0x33399663 GSEventRunModal + 138
    24  UIKit                               0x30de014d UIApplicationMain + 1136
    25  *****                               0xd5b63 ***** + 858979
    26  libdyld.dylib                       0x3921dab7  + 2
)

dSYM UUID: B1AB4CD3-1E60-3EAD-949D-8626046421E6
CPU Type: armv7
Slide Address: 0x00004000
Binary Image: *****
Base Address: 0x000e2000

命令行工具atos 单独解析crash的某个地址

把应用 aaaaaa.app和 .dSYM文件放到一个目录中,执行

atos -arch armv7 -o 'xxxxxx.app/xxxxxx' -l 0x953b1

xcrun atos -arch armv7 -o xxxxxx.app/xxxxxx  0x953b1

这样就得到了程序错误的对应的源代码地址
其中:
armv7为错误日志中对应的CUP Type:armv7

0x953b1为错误内存地址,一般为友盟错误详情中可以点击的第一个项目内存地址

如果你有多个“.ipa”文件,多个".dSYMB"文件,你并不太确定到底“dSYMB”文件对应哪个".ipa"文件,那么,这个方法就非常适合你。
特别当你的应用发布到多个渠道的时候,你需要对不同渠道的crash文件,写一个自动化的分析脚本的时候,这个方法就极其有用。

参考 https://www.cnblogs.com/chlewsz/p/5109652.html

使用工具解析crash - dSYM解析工具

1.0.3版下载:http://pan.baidu.com/s/1mg01Qha
Git: https://github.com/answer-huang/dSYMTools

用法

1.找到闪退的信息,左边为 内存地址 ,右边为 Slide Address ,部分日志第三方也有直接标明 Slide Address 项。
2.将 dSYM 拉入窗口的第一部分,
双击 dSYM 名称后,右边显示可选archive编译类型,
UUID 是自动的,请对好类型,
根据闪退信息填入对应的内存地址和Slide Address,
点击分析按钮,就会显示可能错误的地方了。

需要 dSYM解析工具 dSYM文件和它的UUID 错误信息内存地址+Slide Address

参考 https://www.jianshu.com/p/59c40cc7268f

需要的文件都在哪

.app 应用程序文件 (appName.app文件,把IPA文件后缀改为zip,然后解压,Payload目录下的appName.app文件), 这里的appName是你的应用程序的名称。

.crash
dSYM 在Window -> Organizer -> archive -> xcarchive 里 一般发布成功后,把这个文件.xcarchive直接提交到代码版本库对应的版本分支里,这样就不会搞丢了
symbolicatecrash:/Applications/Xcode.app/Contents/SharedFrameworks/DVTFoundation.framework/Versions/A/Resources/symbolicatecrash

dwarfdump命令 匹配.crash和.dSYM

每个ipa都有一个标识–uuid, 通过终端命令可以查看 拿到xx.app

dwarfdump --uuid xx

dSYM的uuid

dwarfdump --uuid xx.app.dSYM 
dwarfdump --lookup 0x12b45d -arch armv7 xx.app.dSYM  使错误的日志能看懂,把相应的内存地址对应到正确的地方。

.crash的uuid
搜索UUID可找到 如果已符号化

Binary Images:
       0x1b9bbc000 -        0x1b9beefff libsystem_kernel.dylib arm64e  <ef6b203fbeed30698623bf884b0f2bad> /usr/lib/system/libsystem_kernel.dylib

ef6b203fbeed30698623bf884b0f2bad 即是uuid
参考 https://www.jianshu.com/p/690564bf81bc

上一篇:unity+xlua开发中的问题笔记


下一篇:如何定位Obj-C野指针随机Crash(一):先提高野指针Crash率