在程序中，无论是你想弄清楚为什么数组中有3个对象而不是5个，或者为什么一个新的玩家开始之后，游戏在倒退——调试在这些处理过程中是比较重要的一部 分。通过本文的学习，我们将知道在程序中，可以使用的大多数重要调试功能，并如何利用这些调试功能来帮助你以更少的时间解决bug。
本文将介绍如下内容：
在进行调试程序的时候，可能Xcode底部的小黑框会是你最好的朋友。它能输出日志信息，错误信息以及其它各种有用的内容——这可以帮助你进行错误的跟踪。除了可以在看到日志的输出，我们还可以在某个断点出停留住，并检查程序中的变量信息。
本文假设你以及知道断点是如何工作的了（即使不知道的话，也不用担心，看完本文之后，你将明白！）。
在某个特定的时间点命中断点是非常重要的，在有些断点中，有些时候需要通过一个痛苦的循环或者递归函数才能让我们的对象等于某个确定的值。此时我们可以使用条件断点！
条件断点是这样的一类断点：只有当满足某个确定的条件时，才会命中断点。可以想象一下：我们只希望当对象在某个确定的状态，或者循环迭代到第nth次时才 命中断点。单击Xcode editor中的‘gutter’可以添加一个断点，在断点上单击右键，然后选择‘edit breakpoint’，就可以设置特定的条件了。
conditionalBreakpoints
可以提供一个条件（例如i==12），或者断点忽略次数。另外还可以添加动作，该动作可根据断点自动发生，例如一个debugger command——打印一个值。
提示：添加/删除断点的键盘快捷键是command+\
另外一个重要的断点技巧是添加一个异常断点(exception breakpoint)。当遇到异常时，基本99%次Xcode都会自动转到main方法中的autorelease pool中。
unhelpful_break
感谢Xcode…真的太有用了！
通过异常断点，可以方便的定位到引起异常发生的具体代码行。异常断点的添加方法：打开异常断点tab（command+6）。选择窗口左下角的”+”按 钮，并添加一个‘exception breakpoint’，这样，当Xcode遇到异常时，将会在引起异常代码的地方发生断点停留。
Exception-breakpoint
一般情况下，我们在程序代码中添加断点，是为了通过Xcode提供的‘variables view’（该view在Xcode底部console旁边）来查看变量的状态 。理论上，该窗口可以显示出与当前上下文相关的所有值的状态。实际上，这有点小问题，有时候断点过了之后，该窗口并不会进行相关的更新。
variables view
很不错的一个功能是：我们可以使用控制台的命令来检查某个特定的对象——这非常有用。在控制台输入‘po’就可以打印出指定对象的即时信息（处理scalar值时使用‘p’）。
po_command
在查看一个已经存在的对象时，这非常有用（如果对象不存在的话会打印出nil）——确定对象的值，查看数组/字典在运行时的信息，甚至是两个对象的比较（这个命令可以打印出相关对象的内存地址，我们可以打印出两个对象的信息，然后看看它们的内存地址是否相同）。
另外非常有用（但是被隐藏的命令）可以非常容易的对view进行检查——therecursiveDescription命令——在view上调用这个命令可以打印出view的继承关系。
recursiveDescription
有时候在进行程序调试的某个确定时间里，我们希望将消息打印到控制台，此时可以使用NSLog函数，通过该函数可以将任意的输出打印到控制台。在不使用断点时，这个功能非常有用。NSLog遵从的格式与[NSString StringWithFormat]方法遵从的格式一样。
nslog_use
提示：这里可以看到Objective-C中关于字符串格式化的信息： String Programming Guide
虽然NSLog非常有用，但是在真机上，从NSLog打印出来的任何内容都会被保留，隐藏所有人都可以看到——只需要将设备连接到电脑，然后打开 XCode中的organiser，并定位到console，就可以看到每条log信息。可能你会意识到，这会带来一些严重的影响！想一下，如果你将一些 保密的算法逻辑，或者用户密码打印到控制台！因此，如果苹果检测到在production build中，输出许多内容到控制台时，你的应用可能会被苹果拒绝上架到商店。
nslog_public
幸运的是，这里有一个最简单的办法进行log——通过一个宏，让NSLog只在debug build的时候起作用。将这个功能添加到全局都能访问得到的头文件中。这样你就可以尽情的使用log了，并且当进行production时，不会包含log相关代码。如下代码：
#ifdef DEBUG
#define DMLog(...) NSLog(@"%s %@", __PRETTY_FUNCTION__, [NSString stringWithFormat:__VA_ARGS__])
#else
#define DMLog(...) do { } while (0)
现在如果使用DMLog，那么将只会在debug build期间打印出log。而production build时则不会有任何log。通过__PRETTY_FUNCTION\__ 可以打印出打印log所在的函数。
虽然NSLog非常出色，但它也有一些限制：
互联网上也有一些框架可以进行日志记录，通过这些框架可以避免NSLog的一些限制。下面有两个不错的：
虽然ARC可以对内存进行有效的管理，不过在对象的生命周期内跟踪一些重要的事件仍然是重要的。毕竟ARC并不能完全消除内存泄露的可能性，或者确保访问 的是一个被release掉的对象（ARC只是尽量避免这样的情况发生）。为此，我们可以使用一些方法和工具来观察并留意对象在做些什么。
在一个Objective-C对象的生命周期中有两个重要的方法：init和dealloc。将这两个方法调用的事件log到控制台是不错的选择——你可以通过控制台观察到对象生命的开始，更重要的是，可以确保对象的释放。
- (id)init
{
self = [super init];
if (self)
{
NSLog(@"%@: %@", NSStringFromSelector(_cmd), self);
}
return self;
}
- (void)dealloc
{
NSLog(@"%@: %@", NSStringFromSelector(_cmd), self);
}
在Xcode中有两个工具可以用来清理代码，以减少代码的错误率。静态分析器工具可以对我们的代码提出改进意见，比如检测出没有使用过的对象，没有 release对象（针对Core Foundation对象，ARC仍然会有这样的问题）。通过选择Product菜单中的‘Anlayze’可以查看到相关建议。
analyse
检查器是非常强大的一组工具，通过检查器不仅可以从不同的角度检查我们程序对内存的使用情况，文件系统的使用情况（增加、删除、修改等），甚至还提供了自动UI交互的方法。通过选择Product菜单中的‘Profile’可以查看到这些检查器。
选择‘Profile’会打开一个Instrument窗口，这里可以选择一个配置模板进行运行。最常用的模板有zombies（稍后会讨论），activity monitor和leaks。在程序运行时，对内存泄露进行捕捉时，Leaks可能是最有用的一个模板。
Screen-Shot-2012-12-09-at-1.23.38-PM
Zombies是你的朋友
虽然在有ARC的地方很难再遇到让人难受的EXC_BAD_ACCESS错误了，但是在某些确定的情况下，该错误还是会发生的。当在处理 UIPopoverController或者core foundation对象时，我们可以访问一个已经被release掉的对象。一般，当我们release内存中的一个对象时，该对象将被销毁。但是，当 Zombies开启时，只是将对象标记为release，实际上该对象还停留在内存中。当我们访问一个Zombie对象时，Xcode可以告诉我们正在访 问的对象是一个不应该存在的对象了。因为Xcode知道这个对象是什么，所以可以让我们知道这个对象在哪里，以及这是什么时候发生的。
这里有两种方法可以查找出Zombies对象。使用检查器中的Zombie配置模板，或者在‘Run’ build选项中开启Zombie诊断选项。在Stop按钮的旁边，点击scheme名称，然后选择‘Edit Scheme’，点击diagnostic tab项，并勾选上‘Enable Zombie Objects’。注意，Zombie只能用在模拟器调试中，真机上不能使用。
Enabling-Zombies
希望上面的这些关于调试技巧能给你带来帮助。通过上面的这些技巧，可以帮助你减少修改bug的时间，从而把更多的时间用在重要的地方——构建出色的程序！
上面列出来的不是一个完整的调试技巧。另外还有许多技术没有进行讨论，例如在真机中调试问题，远程bug报告，crash报告等。
祝编程愉快！
原文地址：http://www.cnblogs.com/yaoji/p/3739389.html
