iOS Debug 常用技巧
本文主要参考 My App Crashed, Now What?
由于原文是Xcode4.2 iOS5 的版本，有些Xcode略有优化，导致某些原文某些bug不能复现，但是技巧基本现在也是可以通用的。
- 发生bug的第一件事情是保持冷静，不要尝试去随机的改一些代码，祈祷这样能够让bug消失。我们应该按照一定的流程来解决bug。
- 最直接的，就是结合控制台的输出，重新去审阅你刚刚写过的代码。（这一步应该是在编译前做的，即你写完一段代码之后，应当仔细看一遍，看看是否与你所想实现的是否一致，有些时候，急着通过执行来确认自己写的代码的正确性是一种逃避责任的行为，你把检测正确性交给了编译器和你设计的正确性测试用例）重新审阅代码往往能发现很多显而易见的错误
- 第二步，便是查看警告。编译器的警告往往不是无中生有的，如果你确实注意到了警告并且认为不会出错，应该消除警告或强制编译器在该位置不警告。一个好的编程习惯是在运行前就消除所有的警告。
- 接下来是iOS特有的debug的技巧：
-
首先我们需要知道Xcode下通常有两种Crashes:
- SIGABRT: 有时也叫EXC_CRASH，往往是由于系统监测到app正在做一些非法的行为而有意中止的，是一种可控的crash。通常情况下会有比较明确的错误信息，且异常抛出点往往就是错误的地方，容易debug。
- EXC_BAD_ACCESS: 有时也叫SIGBUS或SIGSEGV。通常是由于内存管理问题导致的App奔溃，比较难以debug。往往崩溃的地方和bug的地方不在同一处。
-
iOS崩溃往往是因为跑出了异常，异常在OC中通常不会被处理，一旦出现了异常就会崩溃。我们可以通过增加异常断点来保证异常抛出的时候系统不会直接崩溃而是会挂起。当程序在异常抛出的地方挂起的时候，会出现(lldb)关键字，可以用lldb命令调试
异常断点的位置
-
灰色的地方表示没有源码，点进去只能看到汇编语言。如果没有多线程编程的话通常bug出现在thread1
-
除此之外，其他语言常用的设置断点，观察参数等在iOS中也是可以用的，有时候指针指向的值不一定是指针对象，例如NSString*的指针指向的不一定是NSString，我们需要注意灰色所展示的类型是否与我们想要的类型一致。可以右键查看内存。
习惯性的重写重要类的description和debugDescription对debug的输出信息会有帮助，此时直接输出NSLog(@"%@", objc) 就会输出有效的信息
#if DEBUG || TEST
NSLog(@"%@", objc); //保证只在debug时输出
#endif
