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传送门