iOS开发中的崩溃有两种，一种是正常崩溃在代码段，能指出来崩溃在哪一句代码，而且会给出crash reason，
这个一般来讲随便找找就能解决问题了第二种 就是致命到没朋友的崩溃在Main入口函数
如下图所示，根本在控制台没有任何打印信息，只是停在了main入口
如何通过Xcode来找到崩溃在Main入口函数的原因？？
首先你要明白，很多这种情况是已经释放的对象再调用其方法就会产生EXC_BAD_ACCESS这样的报错
Xcode自带Zombie检测的开关
第一：点这里，选择edit scheme
第二：勾上zombie对象开关
这个时候，你把刚才崩溃的程序再来一遍，令人发指的打印出现了
控制台输出
2016-11-10 16:59:17.272 XXXXX[14999:433907] *** -[XXXXXXXX respondsToSelector:]:
message sent to deallocated instance 0x7fa37d8a0c00
这太强了有没有，瞬间定位到了哪个对象成为了僵尸对象，而你还在对他进行访问，死也死不瞑目，然后你就炸了！
以后遇到蹦在main函数的坏访问，多半是这种情况导致的，直接开启僵尸检测，就能定位到原因的所在
下面对我这个恶心的bug做下留念，浪费我那么久去找他
分析下过程：
1.有两个页面，A push到 B页面 正常情况下不会有问题，pop回来也正常
2.但是我在B上面加了个View，view里面是个searchBar
[self.navigationController.navigationBar addSubview:self.searBackView];
3.这里需要注意的是我用addSubView的方式加的（如果我加到系统的left or rightItem上去，pop回去的时候会自动回收）
这就埋下了隐患，我pop回去的时候在dealloc没有做任何处理
4.这就导致了B页面的顶部View还活着！！！（因为导航栏是共享的）,但是B页面已经dealloc了
dealloc --> SortCategoryProductsViewController
5.当我A页面的searchBar动画下来的时候或者再次Push的时候，会去调用顶部View的拥有者也就是B页面，但是B
已经挂了，这个时候直接炸了
6.你以为结束了么，我擦，这在iOS 9 以上版本根本没事好么，9以下就炸了，血淋淋的教训啊，以后一定在低适配的
模拟器上多跑跑。这种版本花式炸最烦了
7.这个故事告诉我们，addsubView的方式加到导航栏上东西，最好在页面死的时候移除
dealloc能做的事情不多，也就是清理干净一些不必要的麻烦，一定要注意
[objc] view plain copy
- (void)dealloc
{
[self.searBackView removeFromSuperview];
self.searBackView = nil;
DDLogVerbose(@"dealloc --> %s",object_getClassName(self));
}
iOS不同版本有不同的兼容BUG，还要注意一点的事，在searchBar初始化的时候最好加上
[self.searchController.searchBar sizeToFit];