iOS 调试

引言:

程序调试技巧在开发过程中起着举足轻重的地位,熟练的使用可以加快我们捕捉问题的速度. 毕竟BUG这个词是我们程序员一直要伴随的字眼,最关键的,人不是计算机,总有那么一点点小细节容易在我们慎密的思绪中偷偷溜走,从而导致一个BUG的出现.那么本文就是为了介绍关于在开发iOS程序时有哪些好用的技巧辅助我们迅速的找到错误.

参考资料:

1:Xcode的控制台调试命令

http://blog.csdn.net/likendsl/article/details/7576549

使用:

NSLog:

通过NSLog开启了我们程序的调试之旅. 不过NSLog提供的调试信息实在太少.默认只能得到打印时间和工程名称(这个基本没用.) ,就像下面这样:

[csharp]  view plain copy

1. NSLog(@"hello world!");  

输出结果:

2013-05-30 10:01:58.704 DebugDemo[536:c07] hello world!

但在实际项目中,我们需要更多的调试信息,包括这条日志信息来自哪个函数,第几行代码等等来辅助我们梳理程序的流程.

为此,通过一些宏命令辅助,可以达到这方面的效果,代码如下:

[csharp]  view plain copy

1. #ifdef DEBUG  
2. #   define NSSLog(fmt, ...) {NSLog((@"%s [Line %d] " fmt), __PRETTY_FUNCTION__, __LINE__, ##__VA_ARGS__);}  
3. #else  
4. #   define NSSLog(...)  
5. #endif  

上面的代码是一段宏命令,需要在类方法外声明,建议放在全局头文件中以供所有业务类使用. 调用方式如下:

[csharp]  view plain copy

1. 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吧?):

[csharp]  view plain copy

1. NSLog(@"%@",[[TestClass alloc] init]);  

输出结果:

2013-05-30 11:08:56.671 DebugDemo[1042:c07] <TestClass: 0x8a57190>

或者是打印一个继承自UIView的类呢?

[csharp]  view plain copy

1. 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函数,并输出结果.

重写代码如下:

[csharp]  view plain copy

1. - (NSString *)description  
2. {  
3.     NSMutableString *mutableString = [[NSMutableString alloc] init];  
4.     [mutableString appendFormat:@"\n frame:%@",NSStringFromCGRect(self.frame)];  
5.     [mutableString appendFormat:@"\n color:%@",self.backgroundColor];  
6.     return mutableString;  
7. }  

通过重写 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的层级,直接在控制台输入如下代码:

[csharp]  view plain copy

1. 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时就意味着我们的程序更加健壮了.