引言:
程序调试技巧在开发过程中起着举足轻重的地位,熟练的使用可以加快我们捕捉问题的速度. 毕竟BUG这个词是我们程序员一直要伴随的字眼,最关键的,人不是计算机,总有那么一点点小细节容易在我们慎密的思绪中偷偷溜走,从而导致一个BUG的出现.那么本文就是为了介绍关于在开发iOS程序时有哪些好用的技巧辅助我们迅速的找到错误.
参考资料:
1:Xcode的控制台调试命令
http://blog.csdn.net/likendsl/article/details/7576549
使用:
NSLog:
通过NSLog开启了我们程序的调试之旅. 不过NSLog提供的调试信息实在太少.默认只能得到打印时间和工程名称(这个基本没用.) ,就像下面这样:
NSLog(@"hello world!");
输出结果:
2013-05-30 10:01:58.704 DebugDemo[536:c07] hello world!
但在实际项目中,我们需要更多的调试信息,包括这条日志信息来自哪个函数,第几行代码等等来辅助我们梳理程序的流程.
为此,通过一些宏命令辅助,可以达到这方面的效果,代码如下:
#ifdef DEBUG
# define NSSLog(fmt, ...) {NSLog((@"%s [Line %d] " fmt), __PRETTY_FUNCTION__, __LINE__, ##__VA_ARGS__);}
#else
# define NSSLog(...)
#endif
上面的代码是一段宏命令,需要在类方法外声明,建议放在全局头文件中以供所有业务类使用. 调用方式如下:
NSSLog(@"hello world!");
输出结果:
2013-05-30 10:24:21.868 DebugDemo[782:c07] -[ViewController strongNSLog:] [Line 44] hello world!
可以看到,打印的信息提供类名称,函数名称,代码在第几行等非常有用的参考信息.当然这些信息的输出是需要消耗系统资源的,也就是说如果频繁的去使用函数打印日志,将很有可能导致UI界面卡住,程序运行不流畅等不利因素.不过呢,通过上面的代码我们已经很好的规避了这个问题,我们只在程序的DEBUG模式下才打印信息,如果不是DEBUG模式就以三个点的方式来表达代码不做任何事情,我们只需要理解这个目的就好了.
到此,我们增强了我们的NSLog,让它可以做更多的事情.
Description:
description是来自NSObject的一个类成员方法, 通常我们可能需要输出某个类实例的相关信息,就像下面这样(你的自定义类,肯定继承自NSObject吧?):
NSLog(@"%@",[[TestClass alloc] init]);
输出结果:
2013-05-30 11:08:56.671 DebugDemo[1042:c07] <TestClass: 0x8a57190>
或者是打印一个继承自UIView的类呢?
NSLog(@"%@",[[UICustomView alloc] init]);
输出结果:
2013-05-30 11:13:42.899 DebugDemo[1081:c07] <UIView: 0x71c0fd0; frame = (0 0; 0 0); layer = <CALayer: 0x71c10f0>>
观察输出结果发现这两个类打印出来的信息并不一样, 这是因为UIView本身也是继承自NSObject,但是它自己已经重写了description函数.所以结果不一样.
也就是说,一旦我们重写了description函数,我们再次对类通过 %@的方式输出信息,目标类会直接调用重写后的description函数,并输出结果.
重写代码如下:
- (NSString *)description
{
NSMutableString *mutableString = [[NSMutableString alloc] init];
[mutableString appendFormat:@"\n frame:%@",NSStringFromCGRect(self.frame)];
[mutableString appendFormat:@"\n color:%@",self.backgroundColor];
return mutableString;
}
通过重写description函数可以辅助我们在开发调试过程中去获取更多自定义类方面的信息
调试:
为了进入调试状态,我们随时需要在代码中的某一行设定一个断点,当程序执行到这行代码时,大部分运行时的进程都被强制的阻塞(计时器,网络类方面无法阻塞).
将接下来的执行权利交由给开发者.就像下面这样:
为了加快我们的操作速度,我们应该牢记调试相关的快捷键:
清空控制台: command+K
显示隐藏控制台:shift+command+Y
Continue/Pause program exeecution: control+command+Y
Step over:F6
Step into:F7
Step out:F8
当进入调试状态时,我们有几个常用的调试技巧
1:我们随时可以打印当前类的成员变量和局部变量,就像下面这样操作:
点击后,相当于执行 NSLog(@"%@",object); 会将结果立刻显示到控制台.
2:打印某个View,或者是当前方法体内的局部View的层级,直接在控制台输入如下代码:
po [[[[UIApplication sharedApplication] delegate] window] recursiveDescription]
如下图所示:
Crash:
我们在开发过程中,总是不可避免的产生你无法预期的Crash.其实拥有了ARC以后,Crash的机会相对少了很多,只不过偶尔还是要来那么几次.最怕的,就像下面这样,产生了Crash,却停留在main.m代码里:
这样的Crash提示对于我们来说没有任何帮助,当然有经验的开发者会去查看控制台自动输出的Crash信息,如下:
通过exception和reason来定位产生Crash的主要原由.
可是在这样的情况,我们只能去猜测错误大概在哪个类,尝试着在可能出现Crash的代码上面设置一个断点,一步一步调试最终定位到真正产生Crash的那一行代码.
这样效率明显是非常低的,那有没有办法可以迅速的定位错误的具体位置呢?
有!
在我们的XCode中找到Show the Breakpoint Navigator,按照下图中来设置一个全局异常断点
当我们再次运行程序并尝试模拟刚刚产生的Crash, 结果发现,XCode准确的定位到了产生Crash的具体位置.这实在太棒了!
以上是在开发人员开发过程中遇到Crash的跟进方式.
那么交付给测试人员测试时遇到Crash呢?此时又应该怎么收集呢?
正因为有这样的需求iConsole诞生了, 详细使用请查阅我的另一篇关于iConsole介绍的博客
又那么产品正式发布了,还是遇到Crash了呢?
所以Crashlytics也诞生了,具体的使用可以参考这篇关于介绍如何使用Crashlytics的博客:
小技巧:
我们每一次编码完成后紧接着便是编译运行起来,看看程序运行的结果是否达到了我们的预期,此时,我们离不开控制台给我们输出必要的信息,为此,
当程序跑起来时,我们的控制台遍自己弹出来,这是不是蛮好的? 又当我们结束调试需要继续编码时控制台自动隐藏是不是更好? 那么,就按如下设置吧:
1:当编译运行起来以后自动显示控制台
2:当结束运行状态时自动隐藏控制台:
总结:
迅速的解决问题是一件非常愉快的事情,每当修复一个BUG时就意味着我们的程序更加健壮了.