ios开发准备篇-(7)Xcode调试技巧_3

小鱼儿 2022-08-27 10:39 260阅读 0赞

**引言:**

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

**参考资料:**

1:Xcode的控制台调试命令

[http://blog.csdn.net/likendsl/article/details/7576549][http_blog.csdn.net_likendsl_article_details_7576549]

**使用:**

**NSLog:**

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

**\[csharp\]** [view plain][] [copy][view plain]

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

输出结果:

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

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

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

**\[csharp\]** [view plain][] [copy][view plain]

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][view plain]

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][view plain]

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

输出结果:

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

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

**\[csharp\]** [view plain][] [copy][view plain]

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][view plain]

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** 函数可以辅助我们在开发调试过程中去获取更多 自定义类 方面的信息

**调试:**

为了进入调试状态,我们随时需要在代码中的某一行设定一个**断点**,当程序执行到这行代码时,大部分运行时的进程都被强制的阻塞(计时器,网络类方面无法阻塞).

将接下来的执行权利交由给开发者.就像下面这样:

![20130530133930847][]

为了加快我们的操作速度,我们应该牢记调试相关的快捷键:

清空控制台: command+K

显示隐藏控制台:shift+command+Y

Continue/Pause program exeecution: control+command+Y

Step over:F6

Step into:F7

Step out:F8

当进入调试状态时,我们有几个常用的调试技巧

1:我们随时可以打印当前类的成员变量和局部变量,就像下面这样操作:

![20130530134929675][]

点击后,相当于执行 **NSLog(@"%@",object);** 会将结果立刻显示到控制台.

2:打印某个View,或者是当前方法体内的局部View的层级,直接在控制台输入如下代码:

**\[csharp\]** [view plain][] [copy][view plain]

1.  po \[\[\[\[UIApplication sharedApplication\] **delegate**\] window\] recursiveDescription\]

如下图所示:

![SouthEast][]

**Crash:**

我们在开发过程中,总是不可避免的产生你无法预期的**Crash**.其实拥有了**ARC**以后,**Crash**的机会相对少了很多,只不过偶尔还是要来那么几次.最怕的,就像下面这样,产生了**Crash**,却停留在**main.m**代码里:

![20130530141124826][]

这样的**Crash**提示对于我们来说没有任何帮助,当然有经验的开发者会去查看控制台自动输出的Crash信息,如下:

![20130530141642175][]

通过**exception**和**reason**来定位产生Crash的主要原由.

可是在这样的情况,我们只能去猜测错误大概在哪个类,尝试着在可能出现Crash的代码上面设置一个断点,一步一步调试最终定位到真正产生Crash的那一行代码.

这样效率明显是非常低的,那有没有办法可以迅速的定位错误的具体位置呢?

有!

在我们的XCode中找到Show the Breakpoint Navigator,按照下图中来设置一个全局异常断点

![20130530142914042][]

当我们再次运行程序并尝试模拟刚刚产生的**Crash**, 结果发现,**XCode**准确的定位到了产生**Crash**的具体位置.**这实在太棒了!**

以上是在开发人员开发过程中遇到**Crash**的跟进方式.

那么交付给测试人员测试时遇到**Crash**呢?此时又应该怎么收集呢?

正因为有这样的需求**iConsole**诞生了, 详细使用请查阅我的另一篇关于[iConsole介绍][iConsole]的博客

又那么产品正式发布了,还是遇到Crash了呢?

所以Crashlytics也诞生了,具体的使用可以参考这篇关于介绍如何[使用Crashlytics][Crashlytics]的博客:

**小技巧:**

我们每一次编码完成后紧接着便是编译运行起来,看看程序运行的结果是否达到了我们的预期,此时,我们离不开控制台给我们输出必要的信息,为此,

当程序跑起来时,我们的控制台遍自己弹出来,这是不是蛮好的? 又当我们结束调试需要继续编码时控制台自动隐藏是不是更好? 那么,就按如下设置吧:

1:当编译运行起来以后自动显示控制台

![SouthEast 1][]

2:当结束运行状态时自动隐藏控制台:

![SouthEast 2][]

**总结:**

迅速的解决问题是一件非常愉快的事情,每当修复一个BUG时就意味着我们的程序更加健壮了.

[http_blog.csdn.net_likendsl_article_details_7576549]: http://blog.csdn.net/likendsl/article/details/7576549
[view plain]: http://blog.csdn.net/ysy441088327/article/details/8992393#
[20130530133930847]: /images/20220824/4718f47e318d42a5bf595679e78b31a8.png
[20130530134929675]: /images/20220824/8156ab7817e046a39fed7274e3337cb9.png
[SouthEast]: /images/20220824/ac0ece7671844aa49c396485fdf7f201.png
[20130530141124826]: /images/20220824/d0f26e6d19814f78adf10340dededb01.png
[20130530141642175]: /images/20220824/58712d4a0af2477fb7cbe80d9d8dc8f5.png
[20130530142914042]: /images/20220824/70fe38c166104803a17ce8d159ffabca.png
[iConsole]: http://blog.csdn.net/ysy441088327/article/details/8439877
[Crashlytics]: http://blog.devtang.com/blog/2013/07/24/use-crashlytics/
[SouthEast 1]: /images/20220824/a4f727a26f8349ea8e7eeceee87b5b10.png
[SouthEast 2]: /images/20220824/92423e4cb6c74ffcab62e8891732c2be.png