如何记录并分析CRASH日志方法二

这种方法比较麻烦,但内容要详细些

ios程序在崩溃的时候会在设备以下路径自动生成日志

/Library/Logs/CrashRepoter

用ITUNES同步后这个文件会自动复制到电脑里(未验证过,我现在设备是越狱的,都是直接看设备里的文件)MAC~/Libary/Logs/CrashRepoter/MobileDevicewindows 7c:\Users\<user name\Appdata\roaming\apple computer\logs\crashreporter\mobiledevice\

这个plist文件用记事本打开,是无法看明白的需要配套的dsym文件(这是符号文件,可以帮助你翻译错误内容和地址)

默认这个文件在类似以下位置

/Users/ljw/Library/Developer/Xcode/DerivedData/APSIOS-ekmcahprvecdgldkiddssvibzvlu/ArchiveIntermediates/APSIOS/BuildProductsPath/Release-iphoneos

其中APSIOS是你的程序名

这时可以用symbolicatecrash程序来查看日志,这个程序在/Developer/Platforms/iPhoneOSplatform/Developer/Library/PrivateFrameworks/DTDeviceKitframework/Versions/A/Resources下

在终端里运行

就可以看到比较详细的崩溃日志了

------------------------------

Last Exception Backtrace:

0 CoreFoundation 0x37f808bf __exceptionPreprocess + 163

1 libobjcAdylib 0x37acc1e5 objc_exception_throw + 33

2 CoreFoundation 0x37f83acb -[NSObject doesNotRecognizeSelector:] + 175

3 CoreFoundation 0x37f82945 ___forwarding___ + 301

4 CoreFoundation 0x37edd680 _CF_forwarding_prep_0 + 48

5 APSIOS1 0x0003e56b -[PhotoSync GetFiles:] (PhotoSyncm:203)

6 APSIOS1 0x0003eb05 -[PhotoSync DownloadPhotoFromMachineThread:] (PhotoSyncm:320)

7 Foundation 0x35225a91 -[NSThread main] + 73

8 Foundation 0x352b95a1 __NSThread__main__ + 1049

9 libsystem_cdylib 0x37a44c1d _pthread_start + 321

有几种方法可以从设备上获取崩溃日志。

设备与电脑上的iTunes Store同步后，会将崩溃日志保存在电脑上。根据电脑 *** 作系统的不同，崩溃日志将保存在以下位置:

Mac OS X:~/Library/Logs/CrashReporter/MobileDevice/

Windows XP: C:Documents and Settings<USERNAME>Application DataApple ComputerLogsCrashReporterMobileDevice<DEVICE_NAME>

Windows Vista or 7: C:Users<USERNAME>AppDataRoamingApple ComputerLogsCrashReporterMobileDevice<DEVICE_NAME>

当用户抱怨闪退时，你可以要求他让设备与iTunes同步，并根据 *** 作系统的不同，到上述位置把崩溃日志下载下来，然后通过电子邮件发送给你。

你必需尽量获取用户设备生成的所有崩溃日志。因为崩溃日志越多，就越容易诊断问题所在!

另外，如果你装了Xcode，也能很容易通过Xcode从你的设备上获得崩溃日志。将iOS设备连接到电脑上，然后打开Xcode。从菜单栏上选择 Window 菜单, 然后选择 Organizer (快捷方式是 Shift-CMD-2)

在 Organizer 窗口上, 选中 Devices 标签栏 在左侧的导航面板上，选中 Device Logs,

应用提交到App Store后，你也能从 iTunes Connect 获取到用户的崩溃日志 登录到 iTunes Connect 上, 选择Manage Your Applications, 点击相应的应用, 点击应用图标下面的 View Details 按钮, 然后点击右栏Links部分的 Crash Reports 。

一、如何获得crash日志

当一个iOS应用程序崩溃时，系统会创建一份crash日志保存在设备上。这份crash日志记录着应用程序崩溃时的信息，通常包含着每个执行线程的栈调用信息（低内存闪退日志例外），对于开发人员定位问题很有帮助。

如果设备就在身边，可以连接设备，打开Xcode

-

Window

-

Organizer，在左侧面板中选择Device

Logs（可以选择具体设备的Device

Logs或者Library下所有设备的Device

Logs），然后根据时间排序查看设备上的crash日志。这是开发、测试阶段最经常采用的方式。

如果应用程序已经提交到App

Store发布，用户已经安装使用了，那么开发者可以通过iTunes

Connect（Manage

Your

Applications

-

View

Details

-

Crash

Reports）获取用户的crash日志。不过这并不是100%有效的，而且大多数开发者并不依赖于此，因为这需要用户设备同意上传相关信息，详情可参见iOS:

Providing

Apple

with

diagnostics

and

usage

information摘要。

（一）什么是崩溃日志，从哪里能得到它：

iOS设备上的应用闪退时， *** 作系统会生成一个崩溃报告，也叫崩溃日志，保存在设备上，崩溃日志上有很多有用的信息，包括应用是什么情况下闪退的。通常，上面有每个正在执行线程的完整堆栈跟踪信息，所以你能从中了解到闪退发生时各线程都在做什么，并分辨出闪退发生在哪个线程上。

（二）获取崩溃日志的几种方法：

1、当用户抱怨闪退时，你可以要求他让设备与iTunes同步，设备与电脑上的iTunes Store同步后，会将崩溃日志保存在电脑上(路径：Mac OS X:~/Library/Logs/CrashReporter/MobileDevice/)到上述位置把崩溃日志下载下来，然后通过电子邮件发送给你；用这个方法获取崩溃日志时，你必需尽量获取用户设备生成的所有崩溃日志。因为崩溃日志越多，就越容易诊断问题所在。

2、如果你装了Xcode，也能很容易通过Xcode从你的设备上获得崩溃日志；将iOS设备连接到电脑上，然后打开Xcode；从菜单栏上选择 Window菜单, 然后选择 Organizer (快捷方式是 Shift-CMD-2)在Organizer 窗口上, 选中 Devices 标签栏，在左侧的导航面板上，选中Device Logs；LIBRARY下面的Device Logs是你所有设备（曾经连接到Xcode的）的日志；每个设备下面的Device Logs是对应设备的日志。

3、应用提交到App Store后，你也能从 iTunes Connect 获取到用户的崩溃日志，登录到 iTunes Connect 上，选择 Manage Your Applications， 点击相应的应用，点击应用图标下面的View Details按钮， 然后点击右栏Links部分的 Crash Reports；如果没有崩溃日志，试试点击Refresh按钮刷新一下。如果你的应用用户量还不多，或者刚上架不久，iTunes Connect账号上也可能还没有任何崩溃日志；如果有的话你就会看到不同iOS版本用户下的崩溃信息。

4、使用工具来获取应用程序崩溃日志，现在小编来推荐一款好用的工具（名称：Bugly，网址：>

在开发过程中往往会遇见有个别用户或者测试人员反馈app的闪退现象，而项目一般集成的统计闪退的第三方库是笼统的统计了所有的闪退信息，无法去定位某一个用户提出的某一个时间点的某一个闪退问题，于是乎这个时候需要我们能快速的去获取指定用户提出的指定闪退，并能够解析闪退日志，快速的定位到问题。下面将自己的做法大概的做个总结(可能还有别的方法，但是我觉得下面讲述的方法已经足够了)。

先和用户确定iPhone是否打开如下设置（以iOS120的iPhone为参考）：

设置->隐私->分析->共享iPhone分析->与应用开发者共享

只有打开了上述设置闪退日志才会被收集，然后进入设置->隐私->分析->分析数据,找到以自己项目开头拼接出现闪退大致时间点文件名的ips文件。

获取到的ips文件双击打开是没有解析的日志，现在需要修改后缀名为crash，然后双击打开出现下面的d窗

可以选中当时打包的项目，预览并且打开，这时候你会发现打开后的项目会显示闪退的地方。

没错，就是这么简单。不过前提条件是你还有当时打包的项目源码，不然要是用改动过当前闪退所在文件的源码，定位的位置是不对的。

具体步骤：

1首先在桌面新建一个文件夹crashFile，用于存放解析闪退日志用到的文件。

2找到前面获取到的ips文件，拷贝ips文件放到crashFile中

3获取symbolicatecrash文件。

找到当时打包所用的xcode（可能笔记本安装了好几个Xcode），然后进入下面的路径：/Xcodeapp/Contents/SharedFrameworks/DVTFoundationframework/Versions/A/Resources/symbolicatecrash

拷贝symbolicatecrash工具拷贝到crashFile中

4获取dSYM文件

从当时打包的xcode->Window->Organizer->Archives找到当时的xcarchive文件,选中xcarchive文件右键点击显示包内容，拷贝dSYMs文件下的dSYM文件，放到crashFile中。

至此，crashFile文件中总共有3个文件：ips文件、symbolicatecrash工具、dSYM文件。

这时候会发现crashFile文件夹下多了个crashlog文件

双击打开crashlog文件，你会发现崩溃信息已经成功解析

好了，大功告成！！！

下面将附上参考的地址（可以验证闪退的ips文件和dsym文件对应的app是否是同一个）：

>

首先在进入到mac的指定的文件进行获取到crash的文件，一般的crash的文件在这个路径下，~/Library/Logs/CrashReporter/MobileDevice/，就到找需要的crash的文件。

然后找到mac中的电脑中的生成app的路径下中，即是xcode开发完成并编译成功的app的文件都是会在路径下，/Users/luo/Library/Developer/Xcode/DerivedData/TestAutomation-eawlwelvvpqdzsbdqoptakrdprvn/Build/Products/Debug-iphonesimulator/,即是生成app的路径，进行该路径下。把crash的文件复制该目录下。

需要crash的查看uuid的是否一致，进行执行dwarfdump --uuid TestAutomationapp/TestAutomation,生成的结果中就可以查看到uuid的值，方法一致，一一查看crash的文件。

需要找到symbolicatecrash ，进入到该文件下/Applications/Xcodeapp/Contents/Developer/Platforms/iPhoneOSplatform/Developer/Library/PrivateFrameworks/DTDeviceKitframework/Versions/A/Resources/，就可以找到。

然后进行执行symbolicatecrash crash app >testapplog,

这样就把crash的log文件，转换成可以查看的文件内容信息。根据这个log日志信息，进行分析日志信息。

二、解析crash logs

经网上搜索解析crash logs的三种，由于未经测试，所以没有记录下，详见可以：

经测试可用的方法为atos -o XXXappdSYM/Contents/Resources/DWARF/XXX -l address0 targetAddress

其中：

a、XXX是appname

b、address0是当前进程在内存中加载的起始地址，至于为什么需要这个，那就有必要去了解下ASLR

获取地址参下图：

binary Images后面第一个即为基地址（内存中加载的起始地址）

c、targetAddress就是你想要符号化的地址 ，此处一般选取如下

3 appName 0x000f462a 0x4000 + 984618

4 appName 0x00352aee 0x4000 + 3468014

以appName开头的地址

二、常见的Crash类型

1、Watchdog timeout

Exception Code：0x8badf00d， 不太直观，可以读成“eat bad food”，意思是don‘t block main thread

紧接着下面会有一段描述：

Application Specific Information：

comxxxyyy failed to resume in time

对于此类Crash，我们应该去审视自己App初始化时做的事情是否正确，是否在主线程请求了网络，或者其他耗时的事情卡住了正常初始化流程。

通常系统允许一个App从启动到可以相应用户事件的时间最多为5S，如果超过了5S，App就会被系统终止掉。在Launch，resume，suspend，quit时都会有相应的时间要求。在Highlight Thread里面我们可以看到被终止时调用到的位置，xxxAppDelegate加上行号。

PS 在连接Xcode调试时为了便于调试，系统会暂时禁用掉Watchdog，所以此类问题的发现需要使用正常的启动模式。

2、User force-quit

Exception Codes: 0xdeadfa11, deadfall

这个强制退出跟我们平时所说的kill掉后台任务 *** 作还不太一样，通常在程序bug造成系统无法响应时可以采用长按电源键，当屏幕出现关机确认画面时按下Home键即可关闭当前程序。

3、Low Memory termination

跟一般的Crash结构不太一样，通常有Free pages，Wired Pages，Purgeable pages，largest process 组成，同事会列出当前时刻系统运行所有进程的信息。

关于Memory warning可以参看我之前写的一篇文章IOS 内存警告 Memory warning level。

App在运行过程中，系统内存紧张时通常会先发警告，同时把后台挂起的程序终止掉，最终如果还是内存不够的话就会终止掉当前前台的进程。

当接受到内存警告的事后，我们应该释放尽可能多的内存，Crash其实也可以看做是对App的一种保护。

4、Crash due to bugs

因为程序bug导致的Crash通常千奇百怪，很难一概而论。大部分情况通过Crash日志就可以定位出问题，当然也不排除部分疑难杂症看半天都不值问题出在哪儿。这个就只能看功底了，一点点找，总是能发现蛛丝马迹。是在看不出来时还可以求助于Google大神，总有人遇到和你一样的Bug

三、常见的Exception Type & Exception Code

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

除零错误会抛出此类异常

这时候我们就需要根据符号表来监测奔溃位置

什么是符号表

符号表就是指在Xcode项目编译后，在编译生成的二进制文件app的同级目录下生成的同名的dSYM文件。

dSYM文件其实是一个目录，在子目录中包含了一个16进制的保存函数地址映射信息的中转文件，所有Debug的symbols都在这个文件中(包括文件名、函数名、行号等)，所以也称之为调试符号信息文件。

如何得到dsYM文件

我们在Archive的时候会生成xcarchive文件，然后显示包内容就能够在里面找到dsYM文件和app文件。

如何使用dsYM

如果是使用友盟的话，我们能在错误列表里看到一些错误，然后可以导出奔溃信息，导出的文件为csv文件。友盟有一个分析工具，使用那个工具可以看到一些错误的函数，行号等。但是很容易分析失败，不知道为什么？

注意：使用的时候要确保你的xcarchive在 ~/Library/Developer/Xcode/或该路径的子目录下。

xcarchive里的dsYM文件和app文件是有对应的UUID的。然后你的错误详情里也是有UUID，只有当UUID相等时才能分析对。

我犯的错误：因为我们是两个人开发，Archive的时候都是在另一个人的电脑上Archive的，所以我的电脑里根本没有对应的xcarchive文件。所以我在我电脑上用友盟的分析工具分析是时候是监测不出来错误的。问过我ITJob朋友后回答的，希望能帮到你

以上就是关于如何记录并分析CRASH日志方法二全部的内容，包括:如何记录并分析CRASH日志方法二、ios 手机应用 崩掉用什么工具抓取log、应用提交到app store后，怎么样获取用户的崩溃日志等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！