iOS崩溃日志分析及搜集

当一个iOS应用程序崩溃时，系统会创建一份crash日志保存在设备上。这份crash日志记录着应用程序崩溃时的信息，通常包含着每个执行线程的栈调用信息（低内存闪退日志例外）。

1.日志获取

方式1

开发、测试阶段设备就在身边，可以连接设备，打开Xcode - Window - Devices - View Device Log 能够看到设备上的崩溃信息，但是如果缺少符号化崩溃日志的必要文件时，可能导致Xcode无法完成符号化的操作，而且默认是对所有的崩溃信息进行操作，如果长时间未进行这样的查看操作，这个符号化的过程会花费较长时间。对于着急解决问题的情况，显然有些捉急，这时我们应该自己找到想要符号化的.crash文件，手动进行这一操作。

方式2

！符号化的过程中我们需要三个文件： .ipa .crash .dSYM 三者缺一不可，同时需要依赖Xcode的符号化工具——symbolicatecrash 下面我们对每一个文件的查找及工具的使用进行说明

• 1>.ipa文件，也就是我们的iOS程序的安装文件
• 2>.crash文件

设备与电脑上的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>
    
在这个路径下可以查看到与你的Mac连接过的设备的各个程序的崩溃日志，可以看到每一个.crash文件都是按照工程名称和时间来进行命名的，这样很方便开发者找到自己想要查看的那次崩溃日志。不要高兴太早，现在看到的这个.crash文件并不像我们在Xcode中看到的崩溃之后的堆栈信息那样易读，而是一大堆的地址信息。这时我们需要完成一步符号化的操作，使文件以我们熟悉的方式展现出来。 
 ```
 ![crash image](file:///Users/lvejuedexiaohao/Desktop/Snip20160927_10.png)
* 3>.dSYM文件

这个在 Archive 中的 release 版本的 应用程序.xcarchive可以找到，只要在对应的文件上面 右键 显示包内容，可以看到有一个 dSYMs的文件夹，里面就有我们要的 XXXXX.app.dSYM 文件

* 4> symbolicatecrash工具

symbolicatecrash symbolicatecrash是一个隐藏工具，它在我的Mac中的具体路径如下(Xcode.app请换成你的Xcode名称)/Applications/Xcode.app/Contents/SharedFrameworks/DTDeviceKitBase.framework/Versions/A/Resources/symbolicatecrash ``` * 5> 符号化终端操作

将我们前面准备好的三个文件及symbolicatecrash放在桌面的同一个文件夹中，用终端进入 这个目录 然后 用输入终端命令
./symbolicatecrash /Users/xxxx/Desktop/directory/InOrder.crash /Users/xxxx/Desktop/directory/InOrder.app.dSYM > output.crash

上述命令中，"xxxx"和"InOrder"请自行替换成对应的名称,directory是你自己在桌面创建的文件夹。output.crash是输出的文件 >右侧。 运行，

这时候终端可能会报错Error: "DEVELOPER_DIR" is not defined at /usr/local/bin/symbolicatecrash line 53. "

这时候在终端中再输入如下命令:

export DEVELOPER_DIR="/Applications/XCode.app/Contents/Developer"
然后再跑一下刚刚的那个命令，这时候看一下桌面的directory文件夹下就会多出一个名为“output.crash”的文件，我们打开看一下。

至此，对于崩溃日志的符号化已经完成，下面就该对这些可读的日志信息进行分析了。

2.日志分析

（1）Process Information

这部分给出了进程crash后的部分信息

- Incident Identifier crash报告的唯一标识
- CrashReporter Key crash报告映射到Device Identifier的唯一键值（key）。表面上看上去没有任何含义，但实际上给我们提供了一个有用信息，假如我们所获得的大量crash log拥有同样的Crashreport Key，一定程度上说明这个crash问题并不是普遍存在，也许只是对一些特定的设备存在。
- Hardware Model 当前设备类型。假如我们所获得的大量crash log拥有同样的Hardware Model，很大程度上可以说明app在该类设备上运行存在适配的问题。
- Process app的名字。

（2）Basic Information

    这部分给出了crash的一些基本信息：crash发生的时间，当前设备上操作系统的版本等。如果多数crash log拥有相同的iOS版本号，一定程度上说明app对于该版本iOS系统存在适配问题。

（3）Exception

    这部分给出了crash的异常类型，异常错误码和抛出异常的线程。

（4）Threads backtraces

    这部分给出了crash时app所有线程的堆栈记录，列出crash时函数调用堆栈。包含四列：编号，调用的库或工程的名称，函数指针（被调用的方法的地址），文件地址+行编号

（5）Thread state

    这部分给出了crash时寄存器中的值。事实上，堆栈记录已经提供了类似的信息。

（6）Binary images

    这部分列出了crahs时加载的所有文件。

关于一些详细的分析案例，请查看这里http://www.cocoachina.com/industry/20130725/6677.html