开篇小故事：bug的由来
从电脑诞生之日起，就有了电脑BUG。第一个有记载的bug是美国海军的编程员，编译器的发明者格蕾斯·哈珀（GraceHopper）发现的。哈珀后来成了美国海军的一个将军，领导了著名计算机语言Cobol的开发。
1945年9月9日，下午三点。哈珀中尉正领着她的小组构造一个称为“马克二型”的计算机。这还不是一个完全的电子计算机，它使用了大量的继电器，一种电子机械装置。第二次世界大战还没有结束。哈珀的小组日以继夜地工作。机房是一间第一次世界大战时建造的老建筑。那是一个炎热的夏天，房间没有空调，所有窗户都敞开散热。突然，马克二型死机了。技术人员试了很多办法，最后定位到第70号继电器出错。
哈珀观察这个出错的继电器，发现一只飞蛾躺在中间，已经被继电器打死。她小心地用摄子将蛾子夹出来，用透明胶布帖到“事件记录本”中，并注明“第一个发现虫子的实例。”
从此以后，人们将计算机错误戏称为虫子（bug），而把找寻错误的工作称为（debug）。
步入正题：
1.视图调试
- 视图调试A
效果：
每个视图的frame都清晰展现
关于debug的其他选项可以自己点开玩玩，也挺有意思的
-
视图调试B:
苹果称之为Debug View Hierarchy 视图层级调试
举个栗子：
@interface ViewController ()
@end
@implementation ViewController
- (void)viewDidLoad {
[super viewDidLoad];
// Do any additional setup after loading the view, typically from a nib.
self.title = @"debug";
self.view.backgroundColor = [UIColor colorWithDisplayP3Red:.5 green:.5 blue:.5 alpha:.5];
[self layoutUI];
}
- (void)layoutUI {
UIBarButtonItem* item = [[UIBarButtonItem alloc]initWithTitle:@"test" style:UIBarButtonItemStylePlain target:self action:@selector(test)];
self.navigationItem.leftBarButtonItem = item;
}
- (void)test {
}
这个视图层级一目了然，UINavigationBar的子视图有4个，有箭头指示的代表还有子视图eg：ButtonItem里还有个Label
看到这个处理视图就容易多了，比如我们要将NavigationBar设为透明，但是上面的按钮，title等还看得到（话说这个需求很常见，处理方式也很多，这里提供一个根据View Hierarchy的处理方式）
实现上面代码中的test方法
思路：如上路，我们看到_UIBarBackground为navigationBar子视图的第0个对象
- (void)test {
NSArray* arr = self.navigationController.navigationBar.subviews;
NSObject* obj = arr[0];
Class class = [obj class];
NSString* className = NSStringFromClass(class);
NSLog(@"%@",className);
UIView* view = (UIView*)obj;
view.alpha = 0;
}
控制台打印与View Hierarchy一模一样
点击test按钮后的效果：
这里你可能会问，你怎么知道_UIBarBackground是View类型（哈哈，既然我能拿到这个对象，我就可以拿到它的父对象）这里就不演示了，父对象确实是UIView类型
2. Analyze对代码进行代码静态检查
可以分析出大致有如下图几种问题
嘿嘿，我来翻译下
前提：都仅仅是可能出现的问题哈
- 逻辑错误
- 无效数据
- 内存错误
- Core Foundation 内存错误
- Core Foundation错误
- API滥用
下面举几个栗子：
============栗子A============
双击蓝色框得到如下：
IDE帮我们分析的还挺详细的嘛：代码运行的步骤及可能出现的问题
本地化要看需求是否需要了，Xcode8以后静态分析才会报这个问题
如果不想IDE报这个呢（毕竟大多app是没有本地化的）Missing Localizability 设为NO，如图：
============栗子B============
应该是最常见的
============栗子C============
CellNum没有被初始化，当然这样写也没错，（IDE毕竟是静态分析）只是有强迫症的我，不希望工程静态分析有一堆问题
声明变量的同时就初始化是一个好习惯
这点Swift做的特别好，只要声明变量就必须要初始化，如果不初始化需要定义为optional的，没有初值话值为nil，BOOL也可能为nil
============栗子D============
可能存在的内存泄漏，一旦data为NULL成立直接返回，但并没有release context对象 so加上这句
CGContextRelease(context);
CoreGraphics框架下是需要我们手动管理内存的
============栗子E============
OC字典或数组中是不允许存放nil的，一旦有nil就会crash
这就是为什么建议字典用如下方式赋值
3. Memory Graph(Xcode8新增)
举个栗子，我们写个循环引用，如下
- (void)viewDidLoad {
[super viewDidLoad];
[self test2];
}
- (void)test2 {
NSMutableArray* arr1 = [@[@1]mutableCopy];
NSMutableArray* arr2 = [@[@2]mutableCopy];
[arr1 addObject:arr2];
[arr2 addObject:arr1];
}
运行后，点击如图
多贴心，环都帮我们画好了
3. 利用编译器
首先看看我们的IDE用的什么编译器
一些命令：
po:(print object),打印对象
p: 打印基本数据类型
expr:动态执行指定表达式
bt:打印当前线程堆栈信息(bt all:打印所有线程堆栈信息)
image:常用来寻找栈地址对应代码位置
下面举几个栗子：
============栗子A============
一个学生model
注意断点的位置与控制台打印的内容：
我们发现无论是NSLog还是po控制台都是打印对象的地址，这个信息对我们来说作用并不大
so ,重写description与debugDescription
@implementation Student
- (NSString *)description
{
return [NSString stringWithFormat:@"name = %@ \n age = %ld", _name,_age];
}
- (NSString *)debugDescription
{
return [NSString stringWithFormat:@"<%@: %p> name = %@ \n age = %ld", [self class], self, _name,_age];
}
@end
发现NSLog走的是description，而po走的是debugDescription，想要什么有用的信息就往这个地方写吧（个人推荐用po！）
============栗子B============
重点讲下：expr
如图，这段代码只能执行真，那我们怎么让其执行false呢？
见证expr的威力吧
注意：
expr 中文的时候会报错
原因请参考：http://stackoverflow.com/questions/17192505/error-in-breakpoint-condition
解决方法：如图
============栗子C============
一个数组越界的crash
// 打印可疑地址信息
image lookup -a 0x000000010e10478d
错误行数也标出来了，有的人说我一个全局异常断点就ok了，何必这么麻烦
嘿嘿，这个也只是抛砖引玉
4. 利用IDE
见图知意，我就不解释了
编辑断点，这里边也有很多好玩的东西比如说听声音debug等，这篇就不详解了
5.再推荐
UI调试神器：Reveal
接口调试神器：Charles
6.非主流调试
如图效果，再也不怕UI说我这个高度不对了，我用数字告诉她！
7.
如图，发表这篇文章的时候
作者和珏猫也发表了类似的文章iOS �Xcode调试技巧总结
写的很详细、很nice，极力推荐阅读
希望会给大家带来帮助(o)/~
扩充之强力推荐：chisel
Facebook出品必属精品，强大到令人发指https://github.com/facebook/chisel
放张图感受下
安装与使用都有详细介绍
贴一下将这个脚本放到lldbinit目录下的命令（你可能会用到😝）
echo command script import /usr/local/opt/chisel/libexec/fblldb.py >> ~/.lldbinit
touch ~/.lldbinit
