至于红色方框中的内容是三种特殊符号相对应的定义。
符号标记 定义 @expression@ LLDB表达式 %B 断点的名称 %H 遇到该断点的次数
参数通过空格表示分割,也可以在两个@字符之间包含LLDB表达式。
一般情况下,Xcode会异步执行Shell Command,也就是说,Shell Command 和调试器将会同步执行。如果希望调试器在Shell Command命令完成后运行,则可以勾选下面的Wait until done选项。
在断点导航面板中,可以看到所有的断点。
这个断点的作用和异常断点类似,只不过这个断点只有在openGL ES错误发生的时候才会触发。
Local Variables。查看本地变量。
Variables, Registers, Globals and Statics。查看全部变量,包括寄存器和全局变量等,如图 15-25 所示,
宏。注意, NSAssert 并不是函数,它的定义如下:
#define NSAssert(condition, desc, ...)
其中第一个参数 condition 是布尔表达式,第二个参数 desc 是描述信息,参数后面的 ... 是格式化 desc 描述信息
的。如果 condition 为 NO ,则输出 desc 描述信息,并抛出异常 NSInternalInconsistencyException ;如果
#define NAME @ " 测试版本 "
#else
#define NAME @ " 上线版本 "
我们在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文件
3.找到对应build版本的dSYM文件
每一个xx.app, xxx.app.dSYM文件都拥有相应的uuid,crash文件也有uuid,只有三者uuid一至才表明之三者可以解析出正确的日志文件。
查看xx.app文件的uuid的方法,在terminal中输入命令:
查看xx.app.dSYM文件的uuid的方法,在terminal中输入命令:
而.crash的uuid位于,crash日志中的Binary Images:中的第一行尖括号内。如:
armv7 <8bdeaf1a0b233ac199728c2a0ebb4165>
5.通过symbolicatecrash分析crash文件