近日，出现一个很奇怪的bug，当列表的上下滑动区域比屏幕大一点的时候，下载刷新cell的时候，会导致列表偏移一下
定位问题
遇到问题了，首先要找出来问题是如何出现的，为什么会偏移呢？
- 第一步：找出谁导致的
UITableView偏移
- (void)scrollViewDidScroll:(UIScrollView *)scrollView {
NSLog(@"offset ====%f",scrollView.contentOffset.y);
if (scrollView.contentOffset.y != 0) {
NSLog(@"contentOffset y");
}
}
在以上方法中，添加断点，发现是三方类库里面调用导致的
image_1c4m8cf6flnre6r1bjliiocee9.png-167.4kB
进入三方的
UITableView+FDIndexPathHeightCache中发现，reloadRowsAtIndexPaths方法已经被交换，那我先注释掉，看看是不是此处引发的bug呢。
image_1c4m8e0g8aeb105h1fcd8vt1m6rm.png-188.5kB
注释掉之后，发现还是存在这个问题
image_1c4m8mkpodep1qqh160c1nf481q1j.png-135.2kB
发现是
reloadRowsAtIndexPaths方法导致contentOffset。
- 找到哪个方法触发的偏移之后，那么就去万能的stackoverflow上面搜解决方法了，果然找到了解决方法。
2.1 问题的原因是：因为一些神秘的原因，tableview刷新的时候，会使用到预估的行高，如果你没有设置预估的行高的话，会出现上下滑动的效果，你可以缓存你的行高，在estimatedHeightForRowAtIndexPath中返回缓存的行高。
解决有两种方式：
方式一：
- (CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath {
return 85;
}
- (CGFloat)tableView:(UITableView *)tableView estimatedHeightForRowAtIndexPath:(NSIndexPath *)indexPath {
return 85;
}
方式二：
_downloadTableView.estimatedRowHeight = 85;
_downloadTableView.rowHeight = 85;
系统的API有许多让人意想不到的坑，在开发的过程中给开发者造成不小的困扰，希望以后系统API的稳定性能够更高一些。
