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 为我们提供了条件断点。

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

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

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

Symbolic Breakpoint

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

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

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

监控断点

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

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

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

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

日志信息断点

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

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

  1. 无法在运行时添加
  2. 添加数量过多之后干扰视线,又需要麻烦地删除或注释掉
  3. 会编译进 App,在正式版本中需要关闭(当然,我们可以通过宏来判断是否应该编译,但这也需要额外的操作不是吗)

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

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

运行效果如下图所示

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

发声断点

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

总结

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

时间: 2024-10-13 23:28:18

xcode debug的相关文章

iOS开发技巧(系列十七:使用Xcode DEBUG模式和RELEASE模式)

在开发过程中,我们经常需要用到NSLog输出一些信息,甚至有的开发过程,必须在控制台查看输出,有经验的程序员通过控制台输出就能知道整个数据交互的一个流程.但是一个发布的程序,里面带有太多的NSLog输出,肯定对于App性能有所影响,这时候我们可以使用一个宏定义来处理,在开发的时候使用DEBUG模式,在发布的时候使用RELEASE模式.这样,发布的App就不会在程序内部做大量的NSLog输出了. 简单的代码如下, #if defined(DEBUG)||defined(_DEBUG)     NS

Xcode Debug之添加断点

1.添加全局断点(Add Exception Breakpoint) 通过添加全局断点,可以快速定位导致程序奔溃所在的代码行. 在Xcode 中找到Breakpoint navigator(也可以通过快捷键command + 7跳转),在最下面点击加号,第一个就是: 这样就添加了一个全局断点: 程序只要一奔溃,就会触发该断点,并定位到导致奔溃所在的代码行. 2.添加符号断点(Add Symbolic Breakpoint) Symbolic Breakpoint 是一种非常强大的断点. 如上步骤

Xcode Debug 指令,不污染源码的添加判断的调试方式

触类旁通,使用C#时,惊讶于Visual Studio细节的设计 今天,突发奇想,Xcode是不是也有类似的功能,在不污染源码时,添加判断条件,符合提交debug断点才生效,且可以输出指定内容. 双击断点或右击选择Edit 1. 恭喜你已经进入断点的编辑功能 2. 可以设置condition,断点生效条件:action,生效的时候打印的内容 这样子就实现了不污染任何源码,做到断点调试:尤其是在循环内,指定条件生效,有效避免了手动处理断点下一步,或者将判断写入源码内的问题,超赞!!! 原文地址:h

iOS 8:【转】最大化 Xcode Debug Console 窗口

源地址:http://fann.im/blog/2012/03/23/maximize-xcode-debug-console-window/ 参考 How to get back the Console window in XCode4 做了一点点改动,Run 的时候自动切换到 Console Tab 并且是最大化展示,效果还不错. 打开 Tab 支持,View - Show Tab Bar. 双击或点 + 添加一个 Tab. 双击新加的 Tab 改名,比如 CONSOLE. 激活 Conso

IOS中(Xcode) DEBUG模式(RELEASE模式)控制NSLog输出,NSLog两种不同情况的输出方式

[新年新气象,2016/01/04] 俺们在开发IOS程序过程中,经常需要用到NSLog输出一些信息,甚至有的开发过程,必须在控制台查看输出,有经验的程序员通过控制台输出就能知道整个数据交互的一个流程.但是一个发布的程序,里面带有太多的NSLog输出,肯定对于App性能有所影响,这时候我们可以使用一个宏定义来处理,在开发的时候使用DEBUG模式,在发布的时候使用RELEASE模式.这样,发布的App就不会在程序内部做大量的NSLog输出了

xcode debug的时候打印变量为空的问题

昨天打包, 将build configuration 设置为release了,然后再次进行调试的时候没有改回来,发现很多变量的值都不正常为空. 诧异了半天,才找到原因,下次打包后要将这个值改为debug不然,影响调试.

XCode debug中添加查找debug和控制台的办法

我们每一次编码完成后紧接着便是编译运行起来,看看程序运行的结果是否达到了我们的预期,此时,我们离不开控制台给我们输出必要的信息,为此, 当程序跑起来时,我们的控制台遍自己弹出来,这是不是蛮好的?  又当我们结束调试需要继续编码时控制台自动隐藏是不是更好? 那么,就按如下设置吧: 1:当编译运行起来以后自动显示控制台 2:当结束运行状态时自动隐藏控制台: 二.查看 Crash: 我们在开发过程中,总是不可避免的产生你无法预期的Crash.其实拥有了ARC以后,Crash的机会相对少了很多,只不过偶

Xcode如何查看内存中的数据

在  debug 模式下如何在断点处,查看字符指针变量内存中的值,像vs2008的调试工具一样的内存查看器,现在只能查看第一个内存中的值可以在输出窗口采用gdb命令:x /nfu <addr> n表示要显示的内存单元的个数 ----------------------------------------- f表示显示方式, 可取如下值:x 按十六进制格式显示变量d 按十进制格式显示变量u 按十进制格式显示无符号整型o 按八进制格式显示变量t 按二进制格式显示变量a 按十六进制格式显示变量i 指

iOS开发之Xcode常用调试技巧总结

两种最常见最普通的方法: 1.NSLog,最简单的方法,查看变结 中是否有值,有什么值,是不是自己需要的值,然后找到bug. 2.po命令,在程序进入断点处,在控制台中输入po 变量名,也可以像NSLog一样查看变量是否有值,有什么值. 今天主要介绍点高大上的方法. 一.Memory Graph Xcode8新增:Memory Graph解决闭包引用循环问题 这个时候就进入了断点模式,可以查看issue面板,注意选择右边Runtime: 有很多叹号说明就有问题了.看内存中object的名字,有一