参考:http://blog.csdn.net/xunyn/article/details/39473251
开胃小菜--简单的断点调试
在xcode中打开一个app，在想要break的行号上单击，即可生成一个深色的箭头标识--断点。如下图，在viewDidLoad:中设置了断点。
运行app，等待。。。就可以看到xcode在断点处进入调试模式，现在让我们把视线移到xcode右下角的控制台，有木有看到（lldb）这样一行，鼠标移到此行，输入
|
1
|
po
[self view] |
po（print object）是LLDB的一个命令，其主要功能是输出objective-c中对象（objects）的信息，与之相似的另外一个命令是 p（print），其主要功能是输出原生类型（boolean、integer、float、etc）的信息。
注意这个使用了类型转换告知调试器应该如何处理返回值。
技巧一：运行时修改变量的值
你以前怎么验证是不是某个变量的值导致整段程序不能正常工作？修改代码中的变量的值，然后cmd+r重新启动app？现在你不需要这么做了，只需要设置一个断点，当程序在这进入调试模式后，使用expr命令即可在运行时修改变量的值。
假如有一个loginWithUsername:方法，需要两个参数：username，password。
首先设置好断点，如下图所示：
运行app，进入断点模式后，在（lldb）后输入
|
1
2
|
expr
username = @"username"expr
password = @"badpassword" |
|
1
2
|
(NSString
*) $0 = 0x3d3504c4 @"username"(NSString
*) $1 = 0x1d18ef60 @"badpassword" |
|
1
2
|
(0x1c59aae0)
A line forthe
breakpoint(0x1c59aae0)
Username and Password after: username:badpassword |
右击断点选择“Edit Breakpoint...”（或者按住cmd+option，单击断点），然后如下图所示设置断点
注意选中了最后一行（“Automatically continue after evaluating”）的选择框，这就保证运行到这个断点的时，填充变量的值，然后继续运行，并不在此处断点进入调试模式。
运行app，你会得到和上述手动设置变量的值一样的输出。
接下来单击断点，使其处于禁用状态，现在箭头的颜色应该是浅蓝色的，重新运行app，你会发现username和password的值没有在运行时被改变了。
技巧二：设置断点触发条件
断点的另外一个重要作用，是可以设置触发断点生效的条件，这样我们就可以在运行时针对特定的数据进行分析，观察app是否运行在正确的轨道上。如下图：
上述截图可以看到如下语句
|
1
|
(BOOL)[(NSString*)[item
valueForKey:@"ID"]
isEqualToString:@"93306"] |
技巧三：格式化输出数据
如果你厌倦了代码里无穷无尽的NSLog，幸运的是我们可以在编辑断点使其输出格式化字符串就像平常编码时一样。不过有一点需要注意，平常编码时可能会使用NSString‘s stringWithFormat:输出格式化字符串，不过这个方法貌似在断点中木有效果，你需要使用alloc/init形式的方法，如下：
|
1
|
po
[[NSString alloc] initWithFormat:@"Item
index is: %d",
index] |
运行app，就能在控制台看到想要的输出啦！
虽然NSLog非常有用，但是在真机上，从NSLog打印出来的任何内容都会被保留，隐藏所有人都可以看到——只需要将设备连接到电脑，然后打开Xcode中的organiser，并定位到console，就可以看到每条log信息。可能你会意识到，这会带来一些严重的影响！想一下，如果你将一些保密的算法逻辑，或者用户密码打印到控制台！因此，如果苹果检测到在production build中，输出许多内容到控制台时，你的应用可能会被苹果拒绝上架到商店。
幸运的是，这里有一个最简单的办法进行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非常出色，但它也有一些限制：
- 只能在本地打印
- 不支持带级别的log（例如严重、警告等）
- NSLog效率低。在进行大量处理时，NSLog会严重影响程序的执行效率
互联网上也有一些框架可以进行日志记录，通过这些框架可以避免NSLog的一些限制。下面有两个不错的：
- Cocoa LumberJack – 这是针对Cocoa非常出名的一个日志框架。虽然刚开始用的时候会费劲点，但是它非常强大。
- SNLog – NSLog的一个替代品。
虽然ARC可以对内存进行有效的管理，不过在对象的生命周期内跟踪一些重要的事件仍然是重要的。毕竟ARC并不能完全消除内存泄露的可能性，或者确保访问的是一个被release掉的对象（ARC只是尽量避免这样的情况发生）。为此，我们可以使用一些方法和工具来观察并留意对象在做些什么。
在一个Objective-C对象的生命周期中有两个重要的方法：init和dealloc。将这两个方法调用的事件log到控制台是不错的选择——你可以通过控制台观察到对象生命的开始，更重要的是，可以确保对象的释放。
技巧四：the recursiveDescription
另外非常有用（但是被隐藏的命令）可以非常容易的对view进行检查——the recursiveDescription 命令——在view上调用这个命令可以打印出view的继承关系。
