MJRrefresh:關於mj_reloadData死迴圈崩潰分析
問題描述及分析
廢話不多說.直接上傳截圖了.在iOS11.0之前,MJRrefresh直接崩潰在mj_reloadData的死迴圈中.
那麼問題出現在什麼位置呢?其實就是 UITableView的 estimatedRowHeight 屬性和 - (CGFloat)tableView:(UITableView *)tableView estimatedHeightForRowAtIndexPath:(NSIndexPath *)indexPath 方法,我們知道這兩個方法是估算高度的功能.假設你對其進行了設定,而且值過小的時候,MJRefresh的KVO會監聽錯誤的contentoffset，造成不停進行上拉載入操作.最終就造成了崩潰.
解決方案
網上現在提供了兩種方案.分別是註釋原始碼和修改estimatedRowHeight的值.
- 註釋MJRefresh中兩個方法.在 UIScrollView+MJRefresh.m 檔案中的UITableView和UICollectionView的load方法.
但是這種方案會導致automaticllyHidden = YES失效.當然了.在最新的版本中,MJRrefresh的作者已經提到要棄用 automaticllyHidden 這個屬性了.所以仍然還在使用這個屬性的童鞋需要注意.
- 把estimatedRowHeight的值或者
- (CGFloat)tableView:(UITableView *)tableView estimatedHeightForRowAtIndexPath:(NSIndexPath *)indexPath方法的返回值設定為和你的Cell高度相似即可.
estimatedRowHeight 設定分析 (方案優化)
難道,解決mj_reloadData死迴圈崩潰到這裡就結束了嗎?不不不,我們要分析下我們的當初是什麼情況下設定 estimatedRowHeight 屬性或是 - (CGFloat)tableView:(UITableView *)tableView estimatedHeightForRowAtIndexPath:(NSIndexPath *)indexPath 這個代理方法的.設定 estimatedRowHeight 屬性是當我們上拉載入的時候發現當前的tableView出現抖動,原因就在於並沒有設定 estimatedRowHeight 屬性這個屬性造成了.
那麼,是不是我們解決了tableView列表跳動問題.我們就可以不使用 estimatedRowHeight 屬性呢?是的,經過一番查證之後,發現網上有這種解決方案.即可全域性解決抖動問題.
if (@available(iOS 11, *)) {
[UIScrollView appearance].contentInsetAdjustmentBehavior = UIScrollViewContentInsetAdjustmentNever; //iOS11 解決SafeArea的問題，同時能解決pop時上級頁面scrollView抖動的問題
}else{
[UITableView appearance].estimatedRowHeight = 0;
[UITableView appearance].estimatedSectionHeaderHeight = 0;
[UITableView appearance].estimatedSectionFooterHeight = 0;
}
這樣,我們就可以不設定 estimatedRowHeight 屬性了.然後mj_reloadData死迴圈崩潰也就迎刃而解了.刪除 estimatedRowHeight 屬性或者或者 - (CGFloat)tableView:(UITableView *)tableView estimatedHeightForRowAtIndexPath:(NSIndexPath *)indexPath 代理方法即可.
結語
出現問題 → 分析問題 → 解決問題 → 優化解決方案 . 到這裡就結束了.有任何問題歡迎評論區留言,一起探討.謝謝.歡迎關注騷棟.
