關於iOS11中estimatedRowHeight屬性

相信你們都已經升級了iOS11,並且也作了相應的適配,其中對於tableView這個控件進行適配的時候,好比:集成MJRefresh的時候,固然還有其餘不少狀況下,不少資料都有說須要把estimatedRowHeight屬性設置爲0,那麼它究竟是什麼,爲何要這麼來作,咱們來探究下。性能

什麼是estimatedRowHeight?spa

圖片描述

簡而言之estimatedRowHeight是一個預估高度,iOS11以前是爲0,在iOS11下,這個值默認爲44。調試

咱們知道tableView是繼承於ScrollView的,一個scrollView能滑動,須要設置contentSize,那麼tableView的contentSize怎麼來呢?iOS11以前,會調用tableView每個cell的heightForRowAtIndexPath來算出整個高度,從而相加得出contentSize來,這一個步驟挺耗性能!code

因此iOS11,默認打開了estimatedRowHeight估算高度功能,當tableView建立完成後,contentSize爲estimatedRowHeight(默認值爲44)*cell的數量,不須要遍歷每個cell的heightForRowAtIndexPath來計算了。可是這樣子真實的contentSize又怎麼得出來呢?繼承

不要急,咱們看官方文檔的描述,裏面的一句話圖片

圖片描述

也就是說在滑動的時候,來計算這個值。具體是怎麼計算的,咱們能夠舉2個例子:文檔

例子一it

咱們建立一個TableView,在iPhone7(iOS11)下,origin = (x = 0, y = 20),size = (width = 375, height = 657),此時方法返回的cell高度爲50io

-(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));  }

圖片描述

結果咱們能夠看到下圖,初始高度爲100 * 44=4400table

table ContentSize {375, 4400}

當我往下拉(往下不是往上),不會出現新的cell,僅僅是爲了觸發scrollViewDidScroll這個方法來打印出下面語句來

table ContentSize {375, 4490}

這個值怎麼出來的呢?按照計算的話,也應該是4400+(50-44)*13=4478 (這裏50-44是每一行的實際高度和預估的高度的差值;13是界面顯示出0~12,總共13行)。
後面通過調試你會發現,實際上會調用15次heightForRow的方法,這15次,是預估高度爲44,在657高度的屏幕上,會顯示出657/44=15個cell出來,因此它的實際計算會根據這個值來進行,那麼此時咱們就能得出正確的結論來了4400+15*(50-44)=4490。

後面當你每次顯示出新的cell出來的時候,再進行調整,增長50-44=6的高度。

例子二

和例子一的區別在於,cell高度返回爲30,也就是小於預估高度44,其他不變

-(CGFloat)tableView:(UITableView )tableView heightForRowAtIndexPath:(NSIndexPath )indexPath{           
   return 30; 
}

圖片描述

結果咱們能夠看到下圖,初始高度爲100 * 44=4400

table ContentSize {375, 4400}

當我往下拉(往下不是往上),不會出現新的cell,僅僅是爲了觸發scrollViewDidScroll這個方法來打印出下面語句來

table ContentSize {375, 4092}

按照例子一的解釋,咱們計算下:4400 -(44-30)15= 4190 !!它又是怎麼來的呢?通過調試,咱們發現它調用了heightForRow這個方法22次,也就是目前顯示在屏幕上的可見cell數量,按照這個,確實符合:4400 -(44-30)22= 4092。一樣的,當你往上滑動,出現新的cell的時候,contentSize的高度會減去(44-30)

總結

那麼咱們能夠得出結論,當你的實際高度大於預估高度的時候,會按照預估高度下的cell的數量來計算contentSize,當實際高度小於預估高度的時候,會按照實際高度下的cell的數量來計算contentSize。

若是咱們要回到iOS11以前的效果,咱們可讓estimatedRowHeight=0,關閉這個預估高度的效果。

延展

爲何使用MJRefresh在iOS11下要讓estimatedRowHeight=0,由於MJRefresh底部的上拉刷新是根據contentSize來計算的,當數據更新的時候,得出來的contentSize只是預估的。

歡迎加羣討論(請備註來源):272306631

相關文章
相關標籤/搜索