ios 表格回弹

转载

ctaxnews 2024-09-14 21:29:06

文章标签 ios 表格回弹 xcode ios API 搜索 文章分类 iOS 移动开发

####前言

昨天加班,本来顺顺利利的,后来测试拿了一个6P来测,装的是8.4.1的系统,我心说真牛,这么老的系统还留着,测试说,就怕有些用户不更新,就喜欢这个版本.本来也没有什么大不了,可没想到测出来的BUG让我吓了一跳,特此记录一下.

1.在8.4.1版本上侧滑没有出现删除按钮
2.在8.4.1版本上侧滑之后返回上个界面pop的时候程序闪退(注:进入需要删除的界面之后,如果对表格没有点击操作,没有右滑删除操作,返回上个界面是没有崩溃的,?,其实这里应该看出来的) #####一,首先在最新的版本iOS11上没有出现此类情况,在其他版本应该也没有出现此类情况,不然测试就找我了. 我首先查看了我调用的API是否在iOS8中有没有,

-(BOOL)tableView:(UITableView *)tableView canEditRowAtIndexPath:(NSIndexPath *)indexPath
{
    if (indexPath.section == 1)//new
    {
        return YES;
    }

    return NO;
}
复制代码

-(nullable NSArray<UITableViewRowAction *> *)tableView:(UITableView *)tableView editActionsForRowAtIndexPath:(NSIndexPath *)indexPath{} ######NS_AVAILABLE_IOS(8_0) __TVOS_PROHIBITED 这个API注明iOS8以后可以使用,在watchOS 中禁用.按道理来说应该没错,但是没有道理可讲,在8上侧滑没有反应.然后我就查了一下,大佬们说这是因为什么balabala,加上

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

加上这段代码,什么都不用写,然后就可以了.我试了一下,居然真的可以,真是石乐志.(应该是iOS8中在低版本会先调用这个方法,然后再去走新的方法,不懂) #####二,这个Bug就比较鸡贼了,闪退的时候没有崩溃的提示信息,直接到了 main 函数里,搜索的时候,看到大佬说的话,一般直接跳到main函数里的并且不打印任何日志的崩溃应该和内存有关系.谢谢对了,因为觉得API会影响,所以我把

-(nullable NSArray<UITableViewRowAction *> *)tableView:(UITableView *)tableView editActionsForRowAtIndexPath:(NSIndexPath *)indexPath{} 注释了,实现了

-(void)tableView:(UITableView *)tableView commitEditingStyle:(UITableViewCellEditingStyle)editingStyle forRowAtIndexPath:(NSIndexPath *)indexPath
{
  if (editingStyle ==UITableViewCellEditingStyleDelete) {
        [self removeAction:indexPath.row];//这个方法进行删除数组元素,刷新列表的操作
    }
}
复制代码

接下来要做的事情,通过xcode自带的僵尸方法,检查,怎么打开呢, ######请按着command+shift+< ,看截图

######第二个方法,开着比不开强,我觉得可以追踪内存来源保存后，重新运行程序，再重复之前的操作，bug 出现了，右下角也有打印出日志了，问题如下：

2017-12-25 10:13:05.194 xx宝[1621:124805] *** -[STrustDeviceManagerViewController tableView:canEditRowAtIndexPath:]: message sent to deallocated instance 0x158aedfc0

搜索之后发现,有人早在几年前就遇到了这个问题,一下内容大部分为原文来自

startong的博客

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

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

-(void)viewWillDisappear:(BOOL)animated {
[super viewWillDisappear:animated];
[self.bgTableView setEditing:NO]; }

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

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

至此，问题得到解决，以上列出了两种解决方案： 1，删掉canEditRowAtIndexPath这个方法不用，不会出问题；(PS : 这个不行,我的表格里面第二个区,才能进行删除操作,而且里面还有一行不能删除,这个方法可以用,但是要看你的实际需求了.)

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

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