【iOS】崩溃收集和解析

2024-03-11 21:17:55

背景

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

获取崩溃信息方式

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

使用友盟、云测、百度等第三方崩溃统计工具。
自己实现应用内崩溃收集，并上传服务器。
Xcode-Devices中直接查看某个设备的崩溃信息。
使用苹果提供的Crash崩溃收集服务。（少用） Xcode->Window->Organizer->Crashes

使用苹果提供的Crash崩溃收集服务
官方提供的线上包崩溃日志的查看方法, 但是存在72小时的延迟可能, 并且需要用户配合开启"与应用开发者共享"才能获取得到。
用户开启"与应用程序开发者共享"方法：设置-隐私-分析与改进
Window->Device->View Device Logs
从手机上获取
设置-隐私-分析与改进这种方法最粗暴简单, 适合所有用户操作。根据"进程名+时间"的命名格式寻找到崩溃日志, 然后通过"分享"功能导出即可。
从第三方助手软件获取
如果是越狱手机的话, 通过使用助手软件可以直接从手机里找出来
使用友盟、云测、百度、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

码农公寓

背景