调试程序-断点,Debug,崩溃日志分析，友盟崩溃日志

一.设置和查看断点

断点能够分为如下3种类型。

1. 文件行断点设置

添加断点->右键选择Edit Breakpoint

 

Condition:指的是条件表达式，该项容许咱们对断点生效设置条件，表示当知足某一特定条件的前提下，该断点才生效。（该条件的录入，不可以识别预处理的宏定义，也不能识别断点做用域以外的变量和方法）。eg：i == 1 ; (i == 1 || i == 2)

 

Ignore：忽略次数。它指定了在断点生效，应用暂停以前，代码忽略断点的次数。你若是但愿应用运行一段时间后断点才生效，那么就可使用这个选项。好比说在调试某一循环体的时候。eg:Ignore 2 == 前两次执行此处的代码不会触发该断点，从第三次开始触发该断点。若是数字为n,则从第n次开始触发该断点。

 

Action:动做。它表示当断点生效时，Xcode做出反应后的行为动做。点击右边的Add Action选项会弹出如图

 

图中所示红色方框中的选项，可让你指定那一种动做。默认的是Debugger Command。还有如下几种动做供选择，下面逐一介绍。

(1).AppleScript

它是苹果提供的一种脚本语言，用来执行一些预先指定的行为。选中该选项，将会出现如图所示的AppleScript语言的输入框。

 

你们可能看到了，我在输入框中输入了本门至高无上的心法秘诀，它的意思是弹出一个显示“Hello World！”的对话框。点击Compile按钮后，若是没有错误，会显示成功信息。而点击Test按钮，会测试运行效果，以下图

至于红色方框中的内容是三种特殊符号相对应的定义。

符号标记	定义
@expression@	LLDB表达式
%B	断点的名称
%H	遇到该断点的次数

 

(2).Capture GPU Frame

这个功能用于当断点生效时，捕获GPU当前所绘制的帧。该功能是辅助图形调试的。

 

(3).Debugger Command

默认的选项，可让断点执行LLDB调试命令。

po _imageArray 打印该断点上面用到的数组内容

 

(4).Log Message

使用Log命令能够生成消息队列，将相关的消息输出到控制台上，还有一个Speak Message选项，能够播报消息。

 

(5).Shell Command

该动做接收一个命令文件和参数列表。以下图所示

 

命令文件必须是一个可执行的二进制程序或者脚本。能够复制粘贴输入路径，也能够点击Choose按钮选择具体文件。
参数经过空格表示分割，也能够在两个@字符之间包含LLDB表达式。
通常状况下，Xcode会异步执行Shell Command，也就是说，Shell Command 和调试器将会同步执行。若是但愿调试器在Shell Command命令完成后运行，则能够勾选下面的Wait until done选项。

 

(6).Sound

动做会在断点被触发时，弹出声音提示。

 

 

Options: 在执行完事件以后自动继续执行。选中该选项以后，程序不会止步于该断点，遇到该断点也会继续执行，可是会响应action中的调试信息。

 

2. 符号断点设置

设置符号断点与设置文件行断点不一样，须要点击导航面板中的按钮打开断点导航面板，如图15-10所示。
在断点导航面板中，能够看到全部的断点。

 

其中有两项——Add Symbolic Breakpoint和Add Exception Breakpoint，前者能够建立符号断点，后者能够建立异常断点。这里咱们选择Add Symbolic Breakpoint菜单项，此时能够弹出建立符号断点对话框，如图

Symbol：后面能够是

1. 方法名称：会对全部具备此方法名称的类方法生效。例如 initWithFrame: 。 

2. 特定类的方法：OC类和C++类都适用，例如 ，[UIView initWithFrame:]或者 Shap::draw()。 

3. 函数名称。例如普通C函数。

 

Module：是模组的意思，用来限制知足符号的方法，编译器将只会在断点知足这个模组的符号的时候才回暂停

 

其他的选项同上。

 

3. 异常断点设置

 

Exception选项可让你选择响应Objective－C对象抛出的异常，也能够选择响应C++对象抛出的异常。

Break则是选择断点所接收的异常，是接收“Throw”语句抛出的异常仍是Catch语句的。

 

3.OpenGL ES错误断点(OpenGl ES Error Breakpoint)

这个断点的做用和异常断点相似，只不过这个断点只有在openGL ES错误发生的时候才会触发。

 

4.测试失败断点 Test Failure Breakpoint

仅在测试断点失败的时候才会执行，这个时候，应用将会暂停在引起测试失败的代码处，而不是中止在测试代码处。

 

2、调试工具栏

模拟位置按钮左边的为图层查看按钮，点击能够查看界面的各个图层

变量查看窗口

Auto。查看常用的变量。
 Local Variables。查看本地变量。
 Variables, Registers, Globals and Statics。查看所有变量，包括寄存器和全局变量等，如图15-25所示，

其中图标A是自动变量、S是静态变量、R是寄存器、L是本地变量。

Print Description of “i”  打印变量信息

Edit Value…    编辑变量的值

 

3、日志与断言输出

1. 使用NSLog函数

2. 使用NSAssert宏

NSLog函数是无条件输出，即程序运行到该语句，就会输出结果。若是想有条件输出结果，可使用NSAssert
宏。注意，NSAssert并非函数，它的定义以下：
#define NSAssert(condition, desc, ...)
其中第一个参数condition是布尔表达式，第二个参数desc是描述信息，参数后面的...是格式化desc描述信息
的。若是condition为NO，则输出desc描述信息，并抛出异常NSInternalInconsistencyException；若是

condition为YES，则不输出信息。

 

2. 移除项目中的打印信息

 

 

(1)移除NSAssert

NS_BLOCK_ASSERTIONS是Foundation框架中定义好的预处理宏，若是在编译环境中设置NS_BLOCK_ASSERTIONS，在编译的时候NSAssert宏将被移

(2) 移除NSLog

 

扩展： 

1.本身在pch文件中预约义以下宏

#ifdef MY_MACRO
#define NAME @"测试版本"
#else
#define NAME @"上线版本"

#endif

2.

设置preprocessor Macros—>Debug(添加MY_MACRO=1)

3.在项目中使用NAME宏

若是项目Scheme编译模式为Debug  输出：name = 测试版本

若是项目Scheme编译模式为release 输出：name = 上线版本

 

 

4、LLDB调试工具

p和po就是调试工具的命令，调试工具的编译器相对独立于Xcode。咱们进行Objective-C程序开发时，用过3种编译器——GCC、LLVM GCC和Apple LLVM，其中GCC是比较古老的编译器，如今咱们主要使用LLVM GCC和Apple LLVM。GCC的调试工具是GDB，是GCC Debug工具的缩写，LLVM GCC和Apple LLVM的调试工具是LLDB（或lldb）。进入LLDB调试工具的一种方式是从终端进入，另一种是从Xcode进入。Xcode工具咱们比较熟悉，这里主要介绍这种方式。具体作法很简单，就是在程序中设置断点，当程序挂起时，在输出窗口中选择Debugger Output，这时输出窗口有(lldb)

命令提示符，这就进入了LLDB调试工具了。

经常使用命令：po

5、异常堆栈报告分析

[exception reason] 异常产生的缘由

[exception callStackSymbols] 符号化打印

 

查看设备的崩溃日志

 

Window—>Devices—>View Device Logs

点击Re-Symbolicate Log 符号化日志信息

红色标注部分指出崩溃代码在ViewController0.m的第60行代码

 

6、符号化设备的崩溃日志

1.手动符号化设备的崩溃日志

咱们在ios开发中会碰到的不少crash问题，若是Debug调试模式的话，咱们能够每每很容易的根据log的输出定位到致使crash的缘由，但对于已经上线的应用，或者是release环境包致使的crash，咱们就须要一些特殊的手段来经过crash log进行分析定位了。

经过参考网上的一些资料，总结了一下，下面介绍一下经过dSYM文件以及crash log分析定位的方法。

1.导出crash log

经过Xcode的Organizer查看某台iphone设备的DeviceLog，选择须要的crash log，导出XXX.crash文件。

2.找到对应的app文件

找到当前iphone设备上安装的ipa文件，更改文件后缀名为zip，解压后获得Payload文件夹，你须要的app文件就在其中了。

3.找到对应build版本的dSYM文件

dSYM文件是iOS编译后保存16进制函数地址映射信息的文件，每次应用程序build后，都会生成对应的xxx.app, xxx.app.dSYM文件。

 

4.肯定dSYM、app以及crash文件的关系

 

首先将dSYM、app以及crash放入同一个文件夹中，经过终端进入该文件夹。

每个xx.app, xxx.app.dSYM文件都拥有相应的uuid，crash文件也有uuid,只有三者uuid一至才代表之三者能够解析出正确的日志文件。
查看xx.app文件的uuid的方法，在terminal中输入命令：

dwarfdump --uuid xxx.app/xxx (xxx工程名)

查看xx.app.dSYM文件的uuid的方法，在terminal中输入命令：

dwarfdump --uuid xxx.app.dSYM (xxx工程名)

而.crash的uuid位于，crash日志中的Binary Images:中的第一行尖括号内。如：

armv7 <8bdeaf1a0b233ac199728c2a0ebb4165>

5.经过symbolicatecrash分析crash文件

Xcode有自带的symbolicatecrash工具,能够经过dSYM文件将crash文件中的16进制地址转换成可读的函数地址。该文件是隐藏文件，能够经过以下命令查找并拷贝到系统目录下，并创建快捷方式。

1)打开终端，进入到symbolicatecrash工具所在的文件夹目录

第一步:找到symbolicatecrash工具所在的文件夹目录

find /Applications/Xcode.app -name symbolicatecrash（速度快）

或者

find /Applications/Xcode.app -name symbolicatecrash -type f

运行结果

/Applications/Xcode.app/Contents/SharedFrameworks/DVTFoundation.framework/Versions/A/Resources/symbolicatecrash

 

第二步:进入该目录

cd /Applications/Xcode.app/Contents/SharedFrameworks/DVTFoundation.framework/Versions/A/Resources/symbolicatecrash

 

2)查找确认是否存在symbolicatecrash(可省略)

ls -al | grep symbolicatecrash

 

bogon:Resources bang$ ls -al | grep symbolicatecrash

-rwxr-xr-x   1 root  wheel    37893  2 26 10:22 symbolicatecrash

 

3)将symbolicatecrash工具拷贝到dSYM、app以及crash所在的文件夹

bogon:Crash bang$ cp symbolicatecrash /Users/bang/Desktop/Crash

4)执行以下命令，便可正确解析crash文件

./symbolicatecrash xxx.crash xxx.app.dSYM > test.txt

./symbolicatecrash DemoModel.crash CA3ACCD1-F63D-3A37-9773-82B155C02DA6.dSYM >crash2.txt

 

5)打开crash2.txt就能够看到符号化的崩溃日志了

 

 

2.经过友盟符号化设备的崩溃日志

 

若是出现bug的构建版本是在本身的电脑上打包的，那么直接打开终端输入黑色部分的代码就能定位到崩溃的代码位置；

 

若是出现bug的构建版本不是在本身电脑上打包的，那么须要找到对应的构建版本拷贝到本身项目中构建版本的目录中