前言
昨天加班,本來(lái)順順利利的,后來(lái)測(cè)試拿了一個(gè)6P來(lái)測(cè),裝的是8.4.1的系統(tǒng),我心說(shuō)真牛,這么老的系統(tǒng)還留著,測(cè)試說(shuō),就怕有些用戶(hù)不更新,就喜歡這個(gè)版本.本來(lái)也沒(méi)有什么大不了,可沒(méi)想到測(cè)出來(lái)的BUG讓我嚇了一跳,特此記錄一下.
- 1.在8.4.1版本上側(cè)滑沒(méi)有出現(xiàn)刪除按鈕
- 2.在8.4.1版本上側(cè)滑之后返回上個(gè)界面pop的時(shí)候程序閃退(注:進(jìn)入需要?jiǎng)h除的界面之后,如果對(duì)表格沒(méi)有點(diǎn)擊操作,沒(méi)有右滑刪除操作,返回上個(gè)界面是沒(méi)有崩潰的,??,其實(shí)這里應(yīng)該看出來(lái)的)
一,首先在最新的版本iOS11上沒(méi)有出現(xiàn)此類(lèi)情況,在其他版本應(yīng)該也沒(méi)有出現(xiàn)此類(lèi)情況,不然測(cè)試就找我了.
我首先查看了我調(diào)用的API是否在iOS8中有沒(méi)有,
-(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
這個(gè)API注明iOS8以后可以使用,在watchOS 中禁用.按道理來(lái)說(shuō)應(yīng)該沒(méi)錯(cuò),但是沒(méi)有道理可講,在8上側(cè)滑沒(méi)有反應(yīng).然后我就查了一下,大佬們說(shuō)這是因?yàn)槭裁碽alabala,加上
-(void)tableView:(UITableView *)tableView commitEditingStyle:(UITableViewCellEditingStyle)editingStyle forRowAtIndexPath:(NSIndexPath *)indexPath{}
加上這段代碼,什么都不用寫(xiě),然后就可以了.我試了一下,居然真的可以,真是石樂(lè)志.(應(yīng)該是iOS8中在低版本會(huì)先調(diào)用這個(gè)方法,然后再去走新的方法,不懂)
二,這個(gè)Bug就比較雞賊了,閃退的時(shí)候沒(méi)有崩潰的提示信息,直接到了 main 函數(shù)里,搜索的時(shí)候,看到大佬說(shuō)的話,一般直接跳到main函數(shù)里的并且不打印任何日志的崩潰應(yīng)該和內(nèi)存有關(guān)系.謝謝
對(duì)了,因?yàn)橛X(jué)得API會(huì)影響,所以我把
-(nullable NSArray<UITableViewRowAction *> *)tableView:(UITableView *)tableView editActionsForRowAtIndexPath:(NSIndexPath *)indexPath{}
注釋了,實(shí)現(xiàn)了
-(void)tableView:(UITableView *)tableView commitEditingStyle:(UITableViewCellEditingStyle)editingStyle forRowAtIndexPath:(NSIndexPath *)indexPath
{
if (editingStyle ==UITableViewCellEditingStyleDelete) {
[self removeAction:indexPath.row];//這個(gè)方法進(jìn)行刪除數(shù)組元素,刷新列表的操作
}
}
接下來(lái)要做的事情,通過(guò)xcode自帶的僵尸方法,檢查,怎么打開(kāi)呢,
請(qǐng)按著command+shift+< ,看截圖
第二個(gè)方法,開(kāi)著比不開(kāi)強(qiáng),我覺(jué)得 可以追蹤內(nèi)存來(lái)源
保存后，重新運(yùn)行程序，再重復(fù)之前的操作，bug 出現(xiàn)了，右下角也有打印出日志了，問(wèn)題如下：
2017-12-25 10:13:05.194 xx寶[1621:124805] *** -[STrustDeviceManagerViewController tableView:canEditRowAtIndexPath:]: message sent to deallocated instance 0x158aedfc0
搜索之后發(fā)現(xiàn),有人早在幾年前就遇到了這個(gè)問(wèn)題,一下內(nèi)容大部分為原文來(lái)自
startong的博客
也就是說(shuō)，tableView:canEditRowAtIndexPath 這個(gè)方法有問(wèn)題，那我就納悶兒了，這個(gè)方法怎么可能會(huì)有問(wèn)題，難怪我之前注釋掉了這個(gè)方法就沒(méi)問(wèn)題了，果然是這里有問(wèn)題，知道了問(wèn)題針對(duì)它解決掉也就不會(huì)是什么難事兒了，我初步懷疑是 return YES 的問(wèn)題，
于是，我在函數(shù)里加了這樣幾行代碼
-
-(void)viewWillDisappear:(BOOL)animated {
[super viewWillDisappear:animated];
[self.bgTableView setEditing:NO];
}
然后再重新運(yùn)行，重復(fù)之前的操作，問(wèn)題解決了，perfect，，，，
雖然問(wèn)題解決了，但是還是覺(jué)得，canEditRowAtIndex 這個(gè)方法應(yīng)該不會(huì)有問(wèn)題，于是我再 ios 6 的模擬器下運(yùn)行程序，重復(fù)操作沒(méi)問(wèn)題（當(dāng)然注釋掉viewWillDisappear 方法），后來(lái)到網(wǎng)上找了好多資料，很大神都說(shuō)可能是蘋(píng)果自身的問(wèn)題，ios7 才有這個(gè)問(wèn)題，ios6 以及以下不會(huì)出現(xiàn)這種問(wèn)題，
至此，問(wèn)題得到解決，以上列出了兩種解決方案：
1，刪掉canEditRowAtIndexPath這個(gè)方法不用，不會(huì)出問(wèn)題；(PS : 這個(gè)不行,我的表格里面第二個(gè)區(qū),才能進(jìn)行刪除操作,而且里面還有一行不能刪除,這個(gè)方法可以用,但是要看你的實(shí)際需求了.)
2，加上上面說(shuō)的 viewWillDisappear 方法也可以解決問(wèn)題；但是我個(gè)人推薦第二種方法，雖然第一種方法也是可以解決問(wèn)題的，但是個(gè)人還是覺(jué)得這兩個(gè)方法配套使用比較好。
最終總結(jié)
最終總結(jié)出問(wèn)題 可能是在 canEditRowAtIndexPath 這個(gè)方法里設(shè)置了YES然后返回的時(shí)候沒(méi)有把它設(shè)置成 NO 所以報(bào)錯(cuò)，ios6會(huì)自動(dòng)設(shè)置成NO，iOS7 就手動(dòng)設(shè)置成 NO也可以。所以以后無(wú)論什么版本，我們都加上viewWillDisappear手動(dòng)設(shè)置 editing 這個(gè)屬性為NO 這樣確保萬(wàn)無(wú)一失。
插一句,在iOS9以上沒(méi)有這個(gè)問(wèn)題,估計(jì)是蘋(píng)果也處理了這個(gè)問(wèn)題,在界面釋放的時(shí)候,自動(dòng)設(shè)置為NO,所以能升級(jí)就趕緊升級(jí),不要讓程序猿痛苦了.
如果對(duì)你有用,請(qǐng)為我點(diǎn)個(gè)贊,留個(gè)念.謝謝了
