Xcode的debug调试

程序员日常开发中有大量时间都会花费在 debug 上,从事 iOS 开发不可避免地需要使用 Xcode。这篇博客就主要介绍了 Xcode 中几种能够大幅提升代码调试效率的方式。

“If debugging is the process of removing bugs, then programming must be the process of putting them in.”
——Edsger W. Dijkstra

添加条件

有时候我们可能会在某个循环中创建断点,但一次又一次地点击 continue 直到我们想要的条件出现,显然是一种非常低效的方式。好在 Xcode 为我们提供了条件断点。

首先在下列代码中插入一个普通的断点

Xcode的debug调试_第1张图片

右键点击断点,选择 Edit Breakpoint,在 Condition 一栏输入 i > 50

Xcode的debug调试_第2张图片

这样一来,只有当程序运行满足条件之后才会触发断点了。

Symbolic Breakpoint

Symbolic Breakpoint 是一种非常强大的断点。在 Xcode 中找到 Breakpoint navigator(你可以通过快捷键 command + 7),在最下方点击加号,可以看到它。

Xcode的debug调试_第3张图片

添加之后在 Symbol 一栏输入 viewDidLoad。
这样一来,在程序中所有的 viewDidLoad 方法被调用时都会触发断点。

当然,我们也可以仅仅为特定的某个类的方法添加断点。在 Symbol 一栏输入 [ClassName viewDidLoad] (Objective-C) 或 ClassName.viewDidLoad (Swift) 即可。

监控断点

我们调试程序的大部分时候都是为了监控某个变量的变化,在代码中变量出现的地方添加断点不仅累而且还可能漏掉,事后还得一个一个删掉,实在很累。

我们可以通过为变量添加监控断点来简单地做到这一点。

找到变量第一次出现的地方,添加一个普通断点,进入 debug 模式后在 Variables View 中右键变量,选择 Watch 变量名。这样,每一次该变量被改变都会触发断点告知我们。

Xcode的debug调试_第4张图片

我们可以在 Console 中看到其变化。(注:在 Xcode 6.1.1 版本中,在监控 Swift 变量时似乎还有一些问题,无法正确地显示变量的值)

Xcode的debug调试_第5张图片

日志信息断点

最常见的 Debug 方式应该就是 NSLog and println 了。通常我们会通过这种方式来打印输出各种实例信息以检测程序运行状态。

但这一调试方式也有很明显缺陷:

无法在运行时添加

添加数量过多之后干扰视线,又需要麻烦地删除或注释掉

会编译进 App,在正式版本中需要关闭(当然,我们可以通过宏来判断是否应该编译,但这也需要额外的操作不是吗)

所幸在 Xcode 中我们还有另一种选项。

在如下代码中添加一个普通的断点,选择 Edit Breakpoint,然后点击 Add Action,选择 Log Message,在输入框中输入 The number is: @number@。

运行效果如下图所示

Xcode的debug调试_第6张图片

这里因为有日志输出,所以我们可以勾选上最下面的 Automatically continue after evaluating actions,这样这个断点就只会安安静静地为我们输出日志了。

发声断点

同日志信息断点,编辑普通断点,Action 选择 Sound。当触发断点时会发出设置的声音。此 Action 配合 Automatically continue after evaluating actions 选项,可以做到酷炫的听声识 Bug。:)

总结

上述的日志信息断点及发生断点都是可以添加触发条件的。通过这些断点操作,自然是能够极大地提升日常开发中调试代码的效率了。

你可能感兴趣的:(ios,debug,开发,xcode,调试)