相信大家都已經(jīng)升級了iOS11，而且也做了相應(yīng)的適配，其中對于tableView這個控件進行適配的時候，比如：集成MJRefresh的時候，當然還有其他很多情況下，很多資料都有說需要把estimatedRowHeight屬性設(shè)置為0，那么它到底是什么，為什么要這么來做，我們來探究下。
什么是estimatedRowHeight？
總而言之“estimatedRowHeight”就是一個預(yù)估高度，在iOS 11 之前時這個高度為 “零” 但是在iOS11下 它的默認值為 44
我們知道tableView是繼承于ScrollView的，一個scrollView能滑動，需要設(shè)置contentSize，那么tableView的contentSize怎么來呢？iOS11之前，會調(diào)用tableView每一個cell的heightForRowAtIndexPath來算出整個高度，從而相加得出contentSize來，這一個步驟挺耗性能！
所以iOS11，默認打開了estimatedRowHeight估算高度功能，當tableView創(chuàng)建完成后，contentSize為estimatedRowHeight（默認值為44）*cell的數(shù)量，不需要遍歷每一個cell的heightForRowAtIndexPath來計算了。但是這樣子真實的contentSize又怎么得出來呢？
不要急，我們看官方文檔的描述，里面的一句話
也就是說在滑動的時候，來計算這個值。具體是怎么計算的，我們可以舉2個例子：
例子一
我們創(chuàng)建一個TableView，在iPhone7（iOS11）下，origin = (x = 0, y = 20)，size = (width = 375, height = 657)，此時方法返回的cell高度為50
-(NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section{
return100;
}
-(CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath{
return50;
}
-(void)scrollViewDidScroll:(UIScrollView *)scrollView {
NSLog(@"table ContentSize %@", NSStringFromCGSize(scrollView.contentSize)
);
結(jié)果我們可以看到下圖，初始高度為100 * 44=4400
table ContentSize {375, 4400}
當我往下拉（往下不是往上），不會出現(xiàn)新的cell，僅僅是為了觸發(fā)scrollViewDidScroll這個方法來打印出下面語句來
table ContentSize {375, 4490}
這個值怎么出來的呢？按照計算的話，也應(yīng)該是4400+(50-44)*13=4478 （這里50-44是每一行的實際高度和預(yù)估的高度的差值；13是界面顯示出0～12，總共13行）。
后面經(jīng)過調(diào)試你會發(fā)現(xiàn)，實際上會調(diào)用15次heightForRow的方法，這15次，是預(yù)估高度為44，在657高度的屏幕上，會顯示出657/44=15個cell出來，所以它的實際計算會根據(jù)這個值來進行，那么此時我們就能得出正確的結(jié)論來了4400+15*（50-44）=4490。
后面當你每次顯示出新的cell出來的時候，再進行調(diào)整，增加50-44=6的高度。
例子二
和例子一的區(qū)別在于，cell高度返回為30，也就是小于預(yù)估高度44，其余不變
-(CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath{
return 30;
}
結(jié)果我們可以看到下圖，初始高度為100 * 44=4400
table ContentSize {375, 4400}
當我往下拉（往下不是往上），不會出現(xiàn)新的cell，僅僅是為了觸發(fā)scrollViewDidScroll這個方法來打印出下面語句來
table ContentSize {375, 4092}
按照例子一的解釋，我們計算下：4400 -（44-30）15= 4190 ??！它又是怎么來的呢？經(jīng)過調(diào)試，我們發(fā)現(xiàn)它調(diào)用了heightForRow這個方法22次，也就是目前顯示在屏幕上的可見cell數(shù)量，按照這個，確實符合：4400 -（44-30）22= 4092。同樣的，當你往上滑動，出現(xiàn)新的cell的時候，contentSize的高度會減去（44-30）
總結(jié)
那么我們可以得出結(jié)論，當你的實際高度大于預(yù)估高度的時候，會按照預(yù)估高度下的cell的數(shù)量來計算contentSize，當實際高度小于預(yù)估高度的時候，會按照實際高度下的cell的數(shù)量來計算contentSize。
如果我們要回到iOS11之前的效果，我們可以讓estimatedRowHeight=0，關(guān)閉這個預(yù)估高度的效果。
延展
為什么使用MJRefresh在iOS11下要讓estimatedRowHeight=0，因為MJRefresh底部的上拉刷新是根據(jù)contentSize來計算的，當數(shù)據(jù)更新的時候，得出來的contentSize只是預(yù)估的。
