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代理商方法就可.

结语

出现问题 → 分析问题 → 处理问题 → 优化处理方案 . 到这里就结束了.有任何疑问欢迎评论区留言,一起讨论.谢谢.欢迎关注骚栋.

崩溃源码Demo传送门