iOS故障排除指南基本技巧2.docVIP

家可以设置条件（例如i==12）或者设定循环中断点被忽略的次数。当然，我们也可以采取其它一些自动触发机制，例如在调试命令输出值时启用断点。 提示: 利用快捷键组合coomand+能够快速添加或删除断点。 另一项值得关注的断点技巧是添加“exception breakpoint（异常断点）”。不知道大家有没有注意到，当我们遇到异常情况时，Xcode会有99%的机率将我们引向主方法中的自动释放池。 感谢Xocde……你可真会帮倒忙。 通过设定异常断点，我们就能够精确定位引发异常情况的代码行。要做到这一点，首先得打开异常断点选项卡（快捷键为command+6）。在窗口底部会出现一个“+”按钮，点选该按钮即可添加“异常断点”。现在，一旦Xcode在运行中遭遇异常，即会在引发问题的代码处中断。 在控制台端实现手动输出如果我们在应用的特定点进行中断，一般来说是为了检查对象的当前状态。Xcode为我们提供了一套“variables view（变量视图）”，该视图位于Xcode底部、与控制台相邻。理论上讲它的作用是显示与当前环境相关的所有值的实时状态。但在实践中，这一作用有时无法正常生效。或者是无法列出值，或者是并有将值更新为中断时的最新状态，总之问题不少。 幸运的是，我们可以利用一些非常实用的控制台命令自己进行对象检查工作。在控制台中输入“po”来获取特定对象的当前细节信息（我们使用‘p’来处理纯量值）。 这种方式在检查某对象是否已经存在（如果对象不存在则输出结果为nil）、确定对象值、查询某数组/字典在当前运行状态下的内容以及对两个对象进行比较等方面效果拔群。由于这条命令会输出相关对象的内存地址，因此我们可以对本应相同的两个对象进行输出，查看二者是否正确拥有相同的内存地址。 另一条实用但却常常被忽视的命令则是recursiveDescription，我们可以用它轻松检查视图。运行该命令后，系统会将视图结构作为结果输出。 有效日志记录在调试程序的过程中，大家常常希望能将特定消息记录到控制台中。而“NSLog”函数允许用户将任何想要的结果输出至控制台。对于希望以特定途径梳理应用程序或者无法根据特定情况一一设定断点却仍然想要进行值比较的用户而言，它的作用相当重要。NSLog的使用格式与[NSString StringWithFormat]相同（如下图所示）。 提示: 大家可以访问/libr ... /FormatStrings.html了解更多Objictive-C中的格式化字符知识。 聪明地使用NSLog尽管NSLog自身功能已经可圈可点，但我们还得在实际应用中再动动脑子。任何由NSLog输出的内容都会成为成品代码的一部分，也就是说会被任何接触到应用的人看到。只要把设备接入信息管理工具，每个人都能查看控制台信息并查询每一条日志记录。没错，这必然会引发一系列严重后果。试想一下，如果我们曾经向控制台输出过机密逻辑算法或者者用户密码，这些信息一旦被他人获得将带来恶劣影响。有鉴于此，苹果公司会在App Store的审核流程中检测控制台信息。一旦发现其中包含太多输出结果，应用程序将被直接打回开发者处进行调整。 幸运的是，我们还有更好的办法实现日志记录工作。根据大家精力与时间的富裕程度，我们拥有几种不同的处理方案。最简单的办法是做一个宏，其中只包含调试版本中的NSLog。如果时间充实，也可以采用全局可访问的头文件；我们可以把所有日志记录都灌进去，而且不用担心它们会出现在成品代码当中（前提是我们没有对预设的默认宏值做出改动——看不懂也没关系，直接用就好）。 #ifdef DEBUG #define DMLog(...) NSLog(@%s %@, __PRETTY_FUNCTION__, [NSString stringWithFormat:__VA_ARGS__]) #else #define DMLog(...) do { } while (0) 现在如果我们使用DMLog（这个名称可以随便起），它将只向调试版本输出结果，任何成品代码都不会受到影响。_PRETTY_FUNCTION_也帮上了大忙，它会根据日志信息来源为函数命名。 采取下一个步骤虽然NSLog表现卓越，但其局限性也不可忽视： 它只能向本地输出结果； 我们无法为其添加日志“等级”（例如严重、警告等等）； NSLog速度很慢。在进行大量处理时它会严重拖慢应用程序的运行效果。 对于想给自己来点挑战的开发者来说，还有两款框架能够回避NSLog的短板——但前辈是大家得有足够的时间和精力投入其中。下面来看这两款个人推荐： Cocoa LumberJack –一款专为Cocoa打造的知名通用型日志框架，学习起来略困难但功能非常强大。 SNLog –NSLog的替换方案