开篇小故事：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用的什么编译器

编译器相关知识小通道1
编译器相关知识小通道2

一些命令：
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个人用的很多
============栗子C============
一个数组越界的crash

// 打印可疑地址信息 image lookup -a 0x000000010e10478d

错误行数也标出来了，有的人说我一个全局异常断点就ok了，何必这么麻烦

嘿嘿，这个也只是抛砖引玉

4. 利用IDE

见图知意，我就不解释了

编辑断点，这里边也有很多好玩的东西比如说听声音debug等，这篇就不详解了

---

5.再推荐

UI调试神器：Reveal
接口调试神器：Charles

6.非主流调试

GitHub地址

如图效果，再也不怕UI说我这个高度不对了，我用数字告诉她！

7.