使用dSYM分析App崩溃日志
前言
我们在开发App过程中,因为连接到控制台,所以遇到问题会很容易找到问题代码。但是对于线上的App出现Crash的时候,我们不可能通过这种方式,也不现实,所以我们只能通过收集Crash信息,来解决Bug。而这种收集Crash信息并且分析定位到具体代码的第三方SDK很多。但是今天我们来自己实现一下。
收集 Crash 信息
Apple
提供了NSException
类来帮助我们收集异常信息。
NSException is used to implement exception handling and contains information about an exception — Apple Documentation.
点击这里来查看官方文档具体内容。
我们的确可以通过NSException
来收集信息,但是,我们怎么把这个信息保存下来,并且上传到我们后台服务器,收集起来呢。这就需要用到另一个函数:NSUncaughtExceptionHandler
Sets the top-level error-handling function where you can perform last-minute logging before the program terminates.http://www.90168.org/
意思就是我们可以在App异常退出的之前有一分钟的时间来处理异常信息,利用这段时间,我们可以把Crash信息写入本地,也可以上传到服务器,但是考虑到网络阻塞原因,我们可能在这一分钟不能操作完毕,所以我们把上传放到下一次App启动时执行。
具体的代码如下:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
- (void)lyCarshLog { [self uploadExceptionLog]; NSSetUncaughtExceptionHandler(&catchExceptionLog); } - (void)uploadExceptionLog { if (log != nil) { // 在这里上传 Crash 信息,上传完毕后要记得清空。 } } void catchExceptionLog(NSException *exception) { // 获取 Crash 信息 NSArray *symbols = [exception callStackSymbols]; NSString *reason = [exception reason]; NSString *name = [exception name]; NSDictionary *userInfo = [exception userInfo]; //... /*另外,我们可能需要一些别的信息,比如说发生 Crash 的设备的系统版本,设备型号,App的版本号*/ struct utsname systemInfo; // 需要导入`sys/utsname.h`头文件。 uname(&systemInfo); NSString *deviceString = [NSString stringWithCString:systemInfo.machine encoding:NSUTF8StringEncoding]; NSDictionary *appInfo = [[NSBundle mainBundle] infoDictionary]; NSString *appVersion = [appInfo objectForKey:@"CFBundleShortVersionString"]; NSString *result = [NSString stringWithFormat:@"CarshReason = %@ \n name = %@ \n userInfo = %@ \n log = %@ \n systemVersion = %f \n deviceInfo = %@ \n appVersion = %@ ",reason,name,userInfo,symbols,[UIDevice currentDevice].systemVersion.floatValue,deviceString,appVersion]; // 把 result 写入本地。 } |
Crash
信息至此已经收集完毕,等待下次App启动的时候,我们把本地的Crash信息上传到服务器就OK了。
处理 Crash 信息 - 符号化(Fully Symbolicated)
我们得到的信息可能如下(Partially Symbolicated):
Tips: 堆栈跟踪是
自下而上
展示的,也就是最先调用的方法在最下面。
每行信息中包含的信息:
其中:
Binary name
表明代码所在App
或者Framework
的位置。比如:line 0 是在CoreFoundation
中,line 3 在CrashDemo
中…Address
方法的内存地址。Class name
当前的类名。Method name
当前调用的方法名。Offset
相对加载地址/基地址(load address)
的偏移量。
我们得到这个半符号化(Partially Symbolicated)的日志对我们分析Crash原因的帮助很有限,因为我们可能只能知道__NSArrayI objectAtIndex:
调用出现了问题,但是不能定位到具体代码。所以我们要把它完全符号化(Fully Symbolicated)。
dSYM
我们需要借助dSYM
来帮助我们完成符号化,对于dSYM
文件的获取,我们可以通过多种方法,我这里只说一种:
先打开Xcode
,Windows
->Organize
->找到对应的app包,然后右键
->Show in finder
,找到appName. xcarchive
->显示包内容
->把dSYMs拷贝出来(或者就在里面操作)
。
atos
The atos command converts numeric addresses to their symbolic equivalents
我们使用atos
命令来完成符号化,具体命令如下: $ atos -arch <Binary Architecture> -o <Path to dSYM file>/Contents/Resources/DWARF/<binary image name> -l <load address> <address to symbolicate>
其中:
- Binary Architecture:
arm64
、armv6
、armv7
armv7s
根据自己的情况来写。 - Path to dSYM file: dSYM文件的路径。
- binary image name: 你工程的名字。
- load address: 基地址,如果我们的崩溃日志中没有这个信息(比如上面的Crash信息中就没有包含),就需要我们手动去计算这个
load address
:laod address = address to symbolicate - offset
,比如:0x0000000102838119
转化为十进制为4337139993
,再减去偏移量265
,为4337139728
,在转化为十六进制0x0000000102838010
- address to symbolicate:当前方法的内存地址。
所以,上图为例:
1 2 |
$ cd CrashDemo/dSYMs $ atos -arch arm64 -o CrashDemo.app.dSYM/Contents/Resources/DWARF/CrashDemo -l 0x0000000102838010 0x0000000102838119 |
这时命令就会输出已经符号化过的信息: -[ViewController viewDidLoad] (in CrashDemo) (ViewController.m:45)
其中45
就是问题代码在ViewController.m
中的具体位置。
其实符号化
的过程有多种方式,你可以参考Apple文档,对于其中UUID
,只是为了我们找到App对应版本的dSYM
文件,所以如果你能确定两者的对应,不需要我们再去获取。而且,使用上面方法,我们可以找到每一个版本对应的dSYM
文件(假如你没有删除的话)。
最后
愉快的改Bug吧
使用dSYM分析App崩溃日志的更多相关文章
- iOS系统app崩溃日志手动符号化
iOS系统app崩溃日志手动符号化步骤: 1.在桌面建立一个crash文件夹,将symbolicatecrash工具..crash文件..dSYM文件放到该文件夹中 a.如何查询symbolicate ...
- android app崩溃日志收集以及上传
源代码获取请到github:https://github.com/DrJia/AndroidLogCollector 已经做成sdk的形式,源代码已公开,源代码看不懂的请自行google. 假设想定制 ...
- 如何通过友盟分析发布后App崩溃日志-b
要分析崩溃日志,首先需要保留发布时的编译出来的.xcarchive文件.这个文件包含了.DSYM文件. 我一般的做法是,发布成功后,把这个文件.xcarchive直接提交到代码版本库对应的版本分支里, ...
- 如何通过友盟分析发布后App崩溃日志
http://blog.csdn.net/totogo2010/article/details/39892467 要分析崩溃日志,首先需要保留发布时的编译出来的.xcarchive文件.这个文件包含了 ...
- iOS Crash 分析 符号化崩溃日志
参考: http://blog.csdn.net/diyagoanyhacker/article/details/41247367 http://blog.csdn.net/diyagoanyhack ...
- iOS----- Crash 分析(文二)-崩溃日志组成
iOS Crash 分析(文二)-崩溃日志组成 现在我们看一个淘宝iOS主客崩溃的例子: ### 1.进程信息 ### Incident Identifier: E4201F10-6F5F-40F9- ...
- iOS----- Crash 分析(文三)- 符号化崩溃日志
未符号化的崩溃日志就象一本天书,看不懂,更别谈分析崩溃原因了.所以我们在分析日志之前,要把日志翻译成我们可以看得懂的文字.这一步我们称之为符号化. 在iOS Crash分析(文一)中已经提到过符号化的 ...
- 【转】iOS应用崩溃日志分析
作为一名应用开发者,你是否有过如下经历? 为确保你的应用正确无误,在将其提交到应用商店之前,你必定进行了大量的测试工作.它在你的设备上也运行得很好,但是,上了应用商店后,还是有用户抱怨会闪退 ! ...
- iOS:crash崩溃日志分析
一.前言: 作为一个合格的iOS开发者,除了具有规范强悍的编码能力外,还应该具有过硬的查错纠错能力.在项目运行时,程序崩溃是不可避免的,遇到这个问题,有时会出现一大堆的crash日志,艹,貌似看不懂呀 ...
随机推荐
- sql语句按照汉字拼音首字母排序
oracle : 在oracle9i中新增了按照拼音.部首.笔画排序功能.设置NLS_SORT值SCHINESE_RADICAL_M 按照部首(第一顺序).笔划(第二顺序)排序SCHINESE_STR ...
- 网站上点击自定义按钮发起QQ聊天的解决方案
一.背景 最近由于开发需要,需要在网站上自定义一个立即交谈的按钮,现将解决方式分享给大家. 二.解决方案 1.首先访问:http://shang.qq.com/widget/consult.php,适 ...
- @RequestMapping详解
简介: @RequestMapping RequestMapping是一个用来处理请求地址映射的注解,可用于类或方法上.用于类上,表示类中的所有响应请求的方法都是以该地址作为父路径. RequestM ...
- python基础——面向对象编程
python基础——面向对象编程 面向对象编程——Object Oriented Programming,简称OOP,是一种程序设计思想.OOP把对象作为程序的基本单元,一个对象包含了数据和操作数据的 ...
- python基础——迭代器
python基础——迭代器 我们已经知道,可以直接作用于for循环的数据类型有以下几种: 一类是集合数据类型,如list.tuple.dict.set.str等: 一类是generator,包括生成器 ...
- Mysql复制语句
可分为三组(Group):用于Master ,用于Slave,用于任何复制服务.
- #import、#include、#import<>和#import””的区别
一.#import与#include #import不会引起交叉编译的问题.因为在Objective-C中会存在C/C++和Object-C混编的问题,如果用#include引入头文件,会导致交叉编译 ...
- hdu2108(判断凸多边形)
题目链接:http://acm.hdu.edu.cn/showproblem.php?pid=2108 题意: 给出一个多边形的所有顶点,判断是不是凸多边形: 思路: 判断凸多边形的方法比较多,如:若 ...
- 报错 - Command /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/lex failed with exit code 1
这里有两种情况:第一种是某xxx.m文件不存在或路径不对,而且里面有5.1什么的解决方法如下:在Build Phases-->Complie Sources中找到有两个xxx.m文件,一个正常, ...
- SQLServer系统监控
http://blog.sina.com.cn/s/blog_519d269c0100gx09.html http://blog.csdn.net/qxlwuyuhui0801/article/det ...