tableView滑动删除返回错误

测试提了一个bug，说滑动cell显示删除按钮的状态下，点击返回，执行了“popviewcontroller”，竟然崩溃了，如果没有滑动显示删除按钮，返回不会有任何问题！

我试了下在模拟器和iPhone6以上的手机上没问题，iPhone4和iPhone5都蹦了，很奇怪！接上手机也没有打印任何日志，直接carsh到大家觉得最恶心的main文件那边了，仅显示了一个“坏得地址”。

既然是滑动到删除状态，也就是Editing状态才会蹦，那我就消失的时候设置成非编辑状态试试吧，果然还真的好了！但是有点“知其然不知其所以然”！百度了下转载以下博文大伙可以看看哈！

（虽然偶第一时间解决了问题，但是感觉有点小失误，在没有报错的情况下，没有尝试去勾选“僵尸对象”的监听排查错误，下次要注意了）

转载 -- http://blog.sina.com.cn/s/blog_6b1e4a060102v0br.html

这几天做的项目中需要用到tableView滑动删除这个功能，就很习惯的用tableView的两个数据源方法

- (BOOL)tableView:(UITableView *)tableView canEditRowAtIndexPath:(NSIndexPath *)indexPath{

return YES;

}

- (void)tableView:(UITableView *)tableView commitEditingStyle:(UITableViewCellEditingStyle)editingStyle forRowAtIndexPath:(NSIndexPath *)indexPath;

结果写完后，滑动删除掉一行之后点击导航栏的返回按钮居然出现了崩溃现象，而且崩溃是出现在跳回到之前的界面之后，我想着，不可能啊，之前也不是没有这样用过，之前都不出问题，怎么现在出问题了，并且崩溃之后也没有打印出相关的日志，也没有提示信息，直接到了 main 函数里，我想这样的崩溃大家是最头痛的，毫无头绪，虽然之后在偶然的情况下，我把上面的第一个方法给注释掉了，后来也就不崩溃了，问题得到了解决，今天，任务不算很重，我重新想想，越想越要把这个问题给彻底的搞明白，于是重新再回到这个demo里面，我心里想，一般直接跳到main函数里的并且不打印任何日志的崩溃应该和内存有关系（这只是一种直觉，我也不太确定），于是我就沿着这个不太明确的思路慢慢找问题，通过xcode自带的僵尸方法，这样一来就会有打印错误提示了，具体方法如下：

保存后，重新运行程序，再重复之前的操作，bug 出现了，右下角也有打印出日志了，问题如下：

[HistoryViewController tableView:canEditRowAtIndexPath:]: message sent to deallocated instance 0x10930c140

也就是说，tableView:canEditRowAtIndexPath这个方法有问题，那我就纳闷儿了，这个方法怎么可能会有问题，难怪我之前注释掉了这个方法就没问题了，果然是这里有问题，知道了问题针对它解决掉也就不会是什么难事儿了，我初步怀疑是 return YES 的问题，

于是，我在函数里加了这样几行代码

- (void)viewWillDisappear:(BOOL)animated {

[super viewWillDisappear:animated];

[self.bgTableView setEditing:NO];

}

然后再重新运行，重复之前的操作，问题解决了，perfect，，，，

虽然问题解决了，但是还是觉得，canEditRowAtIndex 这个方法应该不会有问题，于是我再 ios 6 的模拟器下运行程序，重复操作没问题（当然注释掉viewWillDisappear方法），后来到网上找了好多资料，很大神都说可能是苹果自身的问题，ios7 才有这个问题，ios6 以及以下不会出现这种问题，

至此，问题得到解决，以上列出了两种解决方案：1，删掉canEditRowAtIndexPath这个方法不用，不会出问题；

2，加上上面说的 viewWillDisappear 方法也可以解决问题；但是我个人推荐第二种方法，虽然第一种方法也是可以解决问题的，但是个人还是觉得这两个方法配套使用比较好。

最终总结出问题 可能是在 canEditRowAtIndexPath 这个方法里设置了YES然后返回的时候没有把它设置成 NO 所以报错，ios6会自动设置成NO，iOS7 就手动设置成 NO也可以。所以以后无论什么版本，我们都加上viewWillDisappear手动设置 editing 这个属性为NO 这样确保万无一失。