首页 > 其他分享> 文章详细

【iOS】崩溃收集和解析

2021-10-12 19:03:30 阅读：220 来源： 互联网

标签：文件 Crash dSYM app iOS crash 崩溃解析

背景

在日常开发中，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

标签：文件,Crash,dSYM,app,iOS,crash,崩溃,解析
来源： https://blog.csdn.net/weixin_43861113/article/details/120729785

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

ICode9