引言:
程序调试技巧在开发过程中起着举足轻重的地位,熟练的使用可以加快我们捕捉问题的速度. 毕竟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时就意味着我们的程序更加健壮了.
