首页 > ios > 那些年我们一起用过的DeBug招式

那些年我们一起用过的DeBug招式

  快速解决Bug需要的是经验和技巧。
  做iOS这么长时间了,天天的DeBug,DeBug的时间有时候花的比开发的时间还长。在这现实的磨练中,不断的升级自己的DeBug技能。现在总结一下常用的那些技能。

1.僵尸调试(Zombie)

  有时候程序编译是对的,运行时做了某些操作,就跳到main函数里面了, 然后出现SIGBAT或者EXC_BAD_ACCESS的提示, 提示的信息无法正确判断出错原因。 利用僵尸调试会在控制台中输出出现SIGBAT或者EXC_BAD_ACCESS的原因, 基本80%能解决你的问题。
先打开项目下面的“Edit Scheme…”。
EditScheme
  点击到选项卡“diagnostics”里面,然后在“Enable Zombie Objects”前面勾上对号。
diagnostics

2.异常捕获(try/catch)

  随着编程生涯的不断前进,遇到的Bug也开始多种多样了。有时候僵尸治不好的Bug还有一种方法来找出,就是用try/catch机制(似乎很多语言上面都有的机制)OC的语法

	@try {
        //这里出问题的的语句
    }
    @catch (NSException *exception) {
        NSLog(@"exception = %@",exception);
    }
    @finally {
        
    }

  这个是在僵尸也打印不出来东西,但是还是报错的地方,加上这一段代码,往往就OK了。

3.LLDB调试

  在xcode中打开一个app,在想要break的行号上单击,即可生成一个深色的箭头标识–断点。如下图,在viewDidLoad:中设置了断点。
首页断点
  运行app,等待。。。就可以看到xcode在断点处进入调试模式,现在让我们把视线移到xcode右下角的控制台,有木有看到(lldb)这样一行,鼠标移到此行,输入

po [self view]

  回车,看看控制台上是不是多了一些view的信息,如下图:
调试图

  po(print object)是LLDB的一个命令,其主要功能是输出objective-c中对象(objects)的信息,与之相似的另外一个命令是   p(print),其主要功能是输出原生类型(boolean、integer、float、etc)的信息。

  控制台输入

p (int)[[[self view] subviews] count]

  结果如下

(int) $2 = 2

  注意这个使用了类型转换告知调试器应该如何处理返回值。

(1)运行时修改变量的值

  你以前怎么验证是不是某个变量的值导致整段程序不能正常工作?修改代码中的变量的值,然后cmd+r重新启动app?现在你不需要这么做了,只需要设置一个断点,当程序在这进入调试模式后,使用expr命令即可在运行时修改变量的值。
  假如有一个loginWithUsername:方法,需要两个参数:username,password。
  首先设置好断点,如下图所示:
修改变量值
  运行app,进入断点模式后,在(lldb)后输入

expr username = @"username"
expr password = @"badpassword"

  控制台会返回以下信息

(NSString *) $0 = 0x3d3504c4 @"username"
(NSString *) $1 = 0x1d18ef60 @"badpassword"

  现在跳出断点,执行断点之后的两条输出语句,控制台会有以下输出

(0x1c59aae0) A line for the breakpoint
(0x1c59aae0) Username and Password after: username:badpassword

  看到看吧,我们在运行时修改了变量的值,事情还可以变的更简单一些,我们可以编辑断点,让它自动填充需要的修改的变量的值,并且可以选择在此断点处不进入断点模式,仅仅修改指定变量的值,然后自动执行后续代码。
  右击断点选择“Edit Breakpoint…”(或者按住cmd+option,单击断点),然后如下图所示设置断点
编辑断点
  注意选中了最后一行(“Automatically continue after evaluating”)的选择框,这就保证运行到这个断点的时,填充变量的值,然后继续运行,并不在此处断点进入调试模式。
  运行app,你会得到和上述手动设置变量的值一样的输出。
  接下来单击断点,使其处于禁用状态,现在箭头的颜色应该是浅蓝色的,重新运行app,你会发现username和password的值没有在运行时被改变了。

(2)设置断点触发条件

  断点的另外一个重要作用,是可以设置触发断点生效的条件,这样我们就可以在运行时针对特定的数据进行分析,观察app是否运行在正确的轨道上。如下图:
触发条件
  上述截图可以看到如下语句

(BOOL)[(NSString*)[item valueForKey:@"ID"] isEqualToString:@"93306"]

  通过这行语句,我们告诉编译器:当item中ID等于93306时,此断点生效,进入断点调试模式。

(3)格式化输出数据

  如果你厌倦了代码里无穷无尽的NSLog,幸运的是我们可以在编辑断点使其输出格式化字符串就像平常编码时一样。不过有一点需要注意,平常编码时可能会使用NSString‘s stringWithFormat:输出格式化字符串,不过这个方法貌似在断点中木有效果,你需要使用alloc/init形式的方法,如下:

po [[NSString alloc] initWithFormat:@"Item index is: %d", index]

输出数据图

  学了这三招,妈妈再也不用担心我DeBug啦!

  1. 还没有评论
评论提交中, 请稍候...

留言


可以使用的标签: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>
Trackbacks & Pingbacks ( 0 )
  1. 还没有 trackbacks