相信大家都已經(jīng)升級(jí)了iOS11，而且也做了相應(yīng)的適配，其中對(duì)于tableView這個(gè)控件進(jìn)行適配的時(shí)候，比如：集成MJRefresh的時(shí)候，當(dāng)然還有其他很多情況下，很多資料都有說(shuō)需要把estimatedRowHeight屬性設(shè)置為0，那么它到底是什么，為什么要這么來(lái)做，我們來(lái)探究下。

什么是estimatedRowHeight？

簡(jiǎn)而言之estimatedRowHeight是一個(gè)預(yù)估高度，iOS11之前是為0，在iOS11下，這個(gè)值默認(rèn)為44。

我們知道tableView是繼承于ScrollView的，一個(gè)scrollView能滑動(dòng)，需要設(shè)置contentSize，那么tableView的contentSize怎么來(lái)呢？iOS11之前，會(huì)調(diào)用tableView每一個(gè)cell的heightForRowAtIndexPath來(lái)算出整個(gè)高度，從而相加得出contentSize來(lái)，這一個(gè)步驟挺耗性能！

所以iOS11，默認(rèn)打開(kāi)了estimatedRowHeight估算高度功能，當(dāng)tableView創(chuàng)建完成后，contentSize為estimatedRowHeight（默認(rèn)值為44）*cell的數(shù)量，不需要遍歷每一個(gè)cell的heightForRowAtIndexPath來(lái)計(jì)算了。但是這樣子真實(shí)的contentSize又怎么得出來(lái)呢？

不要急，我們看官方文檔的描述，里面的一句話

也就是說(shuō)在滑動(dòng)的時(shí)候，來(lái)計(jì)算這個(gè)值。具體是怎么計(jì)算的，我們可以舉2個(gè)例子：

例子一

我們創(chuàng)建一個(gè)TableView，在iPhone7（iOS11）下，origin = (x = 0, y = 20)，size = (width = 375, height = 657)，此時(shí)方法返回的cell高度為50

-(NSInteger)tableView:(UITableView )tableView numberOfRowsInSection:(NSInteger)section{   return 100; }  `
-(CGFloat)tableView:(UITableView )tableView heightForRowAtIndexPath:(NSIndexPath )indexPath{   return 50; } 
-(void)scrollViewDidScroll:(UIScrollView )scrollView {   NSLog(@”table ContentSize %@”, 
NSStringFromCGSize(scrollView.contentSize)); }

結(jié)果我們可以看到下圖，初始高度為100 * 44=4400

table ContentSize {375, 4400}

當(dāng)我往下拉（往下不是往上），不會(huì)出現(xiàn)新的cell，僅僅是為了觸發(fā)scrollViewDidScroll這個(gè)方法來(lái)打印出下面語(yǔ)句來(lái)

table ContentSize {375, 4490}

這個(gè)值怎么出來(lái)的呢？按照計(jì)算的話，也應(yīng)該是4400+(50-44)*13=4478 （這里50-44是每一行的實(shí)際高度和預(yù)估的高度的差值；13是界面顯示出0～12，總共13行）。

后面經(jīng)過(guò)調(diào)試你會(huì)發(fā)現(xiàn)，實(shí)際上會(huì)調(diào)用15次heightForRow的方法，這15次，是預(yù)估高度為44，在657高度的屏幕上，會(huì)顯示出657/44=15個(gè)cell出來(lái)，所以它的實(shí)際計(jì)算會(huì)根據(jù)這個(gè)值來(lái)進(jìn)行，那么此時(shí)我們就能得出正確的結(jié)論來(lái)了4400+15*（50-44）=4490。

后面當(dāng)你每次顯示出新的cell出來(lái)的時(shí)候，再進(jìn)行調(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}

當(dāng)我往下拉（往下不是往上），不會(huì)出現(xiàn)新的cell，僅僅是為了觸發(fā)scrollViewDidScroll這個(gè)方法來(lái)打印出下面語(yǔ)句來(lái)

table ContentSize {375, 4092}

按照例子一的解釋?zhuān)覀冇?jì)算下：4400 -（44-30）15= 4190 ??！它又是怎么來(lái)的呢？經(jīng)過(guò)調(diào)試，我們發(fā)現(xiàn)它調(diào)用了heightForRow這個(gè)方法22次，也就是目前顯示在屏幕上的可見(jiàn)cell數(shù)量，按照這個(gè)，確實(shí)符合：4400 -（44-30）22= 4092。同樣的，當(dāng)你往上滑動(dòng)，出現(xiàn)新的cell的時(shí)候，contentSize的高度會(huì)減去（44-30）

總結(jié)

那么我們可以得出結(jié)論，當(dāng)你的實(shí)際高度大于預(yù)估高度的時(shí)候，會(huì)按照預(yù)估高度下的cell的數(shù)量來(lái)計(jì)算contentSize，當(dāng)實(shí)際高度小于預(yù)估高度的時(shí)候，會(huì)按照實(shí)際高度下的cell的數(shù)量來(lái)計(jì)算contentSize。

如果我們要回到iOS11之前的效果，我們可以讓estimatedRowHeight=0，關(guān)閉這個(gè)預(yù)估高度的效果。

延展

為什么使用MJRefresh在iOS11下要讓estimatedRowHeight=0，因?yàn)镸JRefresh底部的上拉刷新是根據(jù)contentSize來(lái)計(jì)算的，當(dāng)數(shù)據(jù)更新的時(shí)候，得出來(lái)的contentSize只是預(yù)估的。

最新評(píng)論