tableView是一個神奇的東西，可以這么說，就算是一個初學(xué)者如果能把tableView玩的很6，那編一般的iOS的需求都問題不大了。tableView是日常開發(fā)中用爛了的控件，但是關(guān)于tableView中的自定義cell的動態(tài)行高，還是有一些玄機(jī)的。筆者本次主要是因?yàn)轭A(yù)估行高的方法的問題作為了一個契機(jī)順帶寫了此文對幾種動態(tài)行高方法的分析。

如果你不是在董鉑然博客園看到本文，請點(diǎn)擊查看原文。

舊方法

現(xiàn)在常規(guī)的動態(tài)行高的計算方法還是用

[str boundingRectWithSize:size options:NSStringDrawingUsesLineFragmentOrigin attributes:attrs context:nil].size 

這其中需要先傳入一個***尺寸和一個屬性字典，特殊的格式要求都寫在屬性字典中。

NSDictionary *attrs = @{NSFontAttributeName : font}; 

整個流程的基本思想大概就是：用一個字符串對象來調(diào)用此方法，中間需要傳入一個屬性字典來告知字體和樣式，然后根據(jù)字符串長度的多少來算出應(yīng)該給多大的frame。前面?zhèn)鬟M(jìn)的size一般可以設(shè)置***寬度。 此方法一般寫成分類便于調(diào)用。

#import "NSString+Size.h" 
 
@implementation NSString (Size) 
 
/** 
* 類方法計算size大小 
*/ 
+ (CGSize)sizeWithString:(NSString *)str andFount:(UIFont *)font andMaxSize:(CGSize)size 
{ 
NSDictionary *attrs = @{NSFontAttributeName : font}; 
return [str boundingRectWithSize:size options:NSStringDrawingUsesLineFragmentOrigin attributes:attrs context:nil].size; 
} 
 
/** 
* 對象方法計算size大小 
*/ 
- (CGSize)sizeWithFount:(UIFont *)font andMaxSize:(CGSize)size; 
{ 
NSDictionary *attrs = @{NSFontAttributeName : font}; 
return [self boundingRectWithSize:size options:NSStringDrawingUsesLineFragmentOrigin attributes:attrs context:nil].size; 
} 
@end 

這些方法從字面上看也比較容易理解。

調(diào)用時的代碼基本就是取到一個字符串，傳入一個font和一個***size，如下把寬設(shè)置成了270就是***寬度為270高度往下順延的話就把高度寫成MAXFLOAT

NSString *text = _message.text; 
CGSize textSize = [text sizeWithFount:[UIFont systemFontOfSize:14] andMaxSize:CGSizeMake(270, MAXFLOAT)]; 

然后在frame中取到最下面一個空間的maxY，從而讓每一個cell在set方法中就得到自己的行高 ，然后通過cell的類方法返回。

新方法

隨著iOS8的自動布局和Interface builder越來越成熟，逐漸衍生出了一種先用storyboard或xib界面再算自定義行高的方法。

這種方法一般需要先搭建一個圖形化界面。如下圖大概搭一個比較復(fù)雜的cell。

首先可以清晰的看出，用IB搭建看上去很快就能搭建完畢，并且有的圖片或是view的背景設(shè)置了之后能看出界面大概的感覺。這里需要注意的就是label設(shè)置約束的方法，普通控件一般都要設(shè)置四個約束才能固定位置，label和button只設(shè)置兩個約束（只需要寫固定位置的兩條約束，不需要寫自身寬高的約束）也不會報錯，但是需要在editor中設(shè)置sizeToFit，這樣可以根據(jù)字?jǐn)?shù)自動給你分配一個控件的大小。

一般評論類的label肯定都是字?jǐn)?shù)比較多的，這時2條約束就不夠了需要再設(shè)置一個***寬度的約束，如圖1我設(shè)置的方法是，把評論label與左右邊界的間隙給設(shè)定了，這個在IB中叫Leading（前）和Training（后），高的約束我們沒有寫如果字?jǐn)?shù)超過了一行他就會自己往下順延。 這么寫相較于把寬度約束寫死的好處是會自動根據(jù)屏幕適配不管屏幕多大都是左右空出若干像素。這樣做也有局限性，就是假設(shè)給這個label設(shè)置一個背景色，如果字?jǐn)?shù)就5個字背景色也會延伸到一整行。如果QQ聊天頁面也這樣做，不管是幾個字都是一整行的聊天氣泡那會很丑。于是有了一種少則背景也少，多也不超過***寬度的做法，就是設(shè)置label的width的less than來設(shè)置***寬度。這么做如果字?jǐn)?shù)不足一行的話，約束也會自動縮到與label長度匹配。

如果這個頁面用純手碼寫，可想而知會非常麻煩。

用IB頁面做自定義行高的計算方法也更簡單。也就是里面模型的set方法正常寫，給自己的UI控件賦值。然后在tableView的行高方法heightForRow中，先給cell的模型賦值，然后再使用一次

[cell layoutIfNeeded]; 

他會自動根據(jù)填進(jìn)去數(shù)值來布局，然后我們直接在這個方法中返回最下面一個控件的bottom位置+若干間隙，以此來作為行高即可。

真正的布局其實(shí)也就是用了這一行代碼，并且可以做到屏幕適配不用if判斷各種frame。但這樣寫也有一些問題，首先就是這么寫從結(jié)構(gòu)上來看不合理。這個行高方法中不應(yīng)該寫這些賦值語句。官方還是其他大神說不合理的原因，應(yīng)該是這個方法應(yīng)該僅僅是用來算出行高并顯示的，會調(diào)用多次，如果在這里賦值性能會很差。這么說有道理，把這里面的每行代碼都看一遍，能看出性能較差的方法主要就是這兩行：1.給cell里模型賦值 2.layoutIfNeed 。如果調(diào)用多次這個方法那這兩行也會執(zhí)行多次，所以這應(yīng)該是不科學(xué)的?！　∥覍?shí)際的做法是在其中設(shè)置一個行高緩存字典，并且找一個肯定不會重復(fù)的標(biāo)識來做key值。每一行cell計算行高前都先拿自己的id去行高緩存字典里取一下看有沒有值，如果有則直接返回對應(yīng)的value，如果沒有再計算。這樣可以使這性能比較差得兩行代碼只執(zhí)行一次。達(dá)到優(yōu)化效果。

MTFBNoReplyCell *feedbackNoreplyCell = [MTFBNoReplyCell cell]; 
 
NSString *thisId =[NSString stringWithFormat:@"%d", feedbackModel.feedbackid]; 
 
// MTLog(@"%@",[self.cellHeightCache valueForKey:thisId]); 
CGFloat cacheHeight = [[self.cellHeightCache valueForKey:thisId] doubleValue]; 
if (cacheHeight) { 
// MTLog(@"返回緩存的行高"); 
return cacheHeight; 
} 
// MTLog(@"耗性能的行高"); 
feedbackNoreplyCell.feedbackDetailModel = feedbackModel; 
[feedbackNoreplyCell layoutIfNeeded]; 
 
[self.cellHeightCache setValue:@(feedbackNoreplyCell.replyBtn.bottom+16) forKey:thisId]; 
 
return feedbackNoreplyCell.replyBtn.bottom+16; 

大概的思想如上所示。 如果這個tableView的數(shù)據(jù)不會隨時改變較為固定的話，可以把取到的模型作為value以indexpath.row為key存一個緩存字典這樣也能優(yōu)化一些。行高方法里取過了，cellForRow就可以直接用了。

預(yù)估行高方法

這里我想重點(diǎn)說一下這個預(yù)估行高的方法estimatedHeightForRowAtIndexPath 。這個方法可能大部分人一說到這個，就說這個方法好啊，預(yù)估行高方法可以減少heightForRow的調(diào)用次數(shù)，使得性能達(dá)到優(yōu)化。 孰不知實(shí)際運(yùn)用中是存在著一定問題的。

就拿整個tableView來說 他是繼承自scrowView的，scrowView能夠滾動是因?yàn)樗衏ontentSize。tableView在初次加載的時候也需要算出自己的contentSize（而且會算不止一次），也就是說需要調(diào)一下所有的行高方法然后自己內(nèi)部給他累加一下算出整個contentSize。如果在行高方法里設(shè)置一個打印會看到方法會調(diào)用很多次。這時如果有一個預(yù)估方法return 100。那它就能很快算出總值了。就會減少行高方法的調(diào)用，在實(shí)際用到某一行時再調(diào)用。

但是可能會出現(xiàn)如下左圖的問題。

問題的原因就是，一開始預(yù)估方法給每行預(yù)估了一個行高，然后后面實(shí)際加載的行高與預(yù)估的行高不合時，會出現(xiàn)cell上下的“竄動”給人卡卡的感覺。對此我的思想是，如果是動態(tài)的且cell的復(fù)雜度較高，行與行之間差距大的時候，就直接不要寫預(yù)估行高方法了吧，讓他自己算吧哪怕多調(diào)用幾次，畢竟上面已經(jīng)寫過緩存行高字典了，性能姑且是可以hold住了，并且不會出現(xiàn)“竄動”情況。如右圖所示。

但是如果是固定行高有一種或是三種不同的cell，行高分別是120，150，200。你在預(yù)估行高了寫個return 150。遇到行高與預(yù)估不等時，卻也不會出現(xiàn)“竄動”。我推測應(yīng)該是estimatedHeightForRow不能和HeightForRow里面的layoutIfNeed同時存在，這兩者同時存在才會出現(xiàn)“竄動”的bug。所以我的建議是：只要是固定行高就寫預(yù)估行高來減少行高調(diào)用次數(shù)提升性能。如果是動態(tài)行高就不要寫預(yù)估方法了，用一個行高的緩存字典來減少代碼的調(diào)用次數(shù)即可。

關(guān)于上面行高的新方法和舊方法的對比，我的總結(jié)是：首先新方法肯定性能上是比舊方法要差一些的。具體體現(xiàn)在兩個方面，1是在IB頁面開發(fā)的東西，程序一啟動就會全部加載進(jìn)內(nèi)存由系統(tǒng)托管，以至于有的界面你已經(jīng)把導(dǎo)航控制器的棧頂控制器給pop了，發(fā)現(xiàn)內(nèi)存還沒有下降。2是新方法和舊方法有一個本質(zhì)的區(qū)別，舊方法是直接算，算你需要多大的尺寸就告訴你，新方法則是先強(qiáng)制布局然后看你占了多大的尺寸再告訴你，這兩者一對比，新方法就是多了一個強(qiáng)制布局的過程，這肯定是會對性能造成一定影響的，那具體影響多少？關(guān)于滑動計算行高我還不知道有什么可以明確一個數(shù)據(jù)的對比，我只能用肉眼看屏幕的滑動來區(qū)分對比，我的感覺就是基本沒差別，如果要說有的話新方法可能會非常輕微的卡頓，換而言之就是同一個頁面，舊方法編完需要10小時，新方法編完需要3小時，但是新方法的性能略差于舊方法。就看你自己怎么衡量了。當(dāng)然非常龐大的項(xiàng)目還是建議用舊方法，畢竟一點(diǎn)一點(diǎn)的“略差于”積累在一起就是很差了。

關(guān)于iOS8新的行高特性

首先是有了一個新的用法。寫在viewdidload里

self.tableView.estimatedRowHeight = 50.0f; 
self.tableView.rowHeight = UITableViewAutomaticDimension; 

這就沒什么好說的了，蘋果自己幫你把動態(tài)行高計算了，所有亂七八糟的都不用管了。 但是暫時說這些基本沒用，因?yàn)楝F(xiàn)在還看不到哪個公司的項(xiàng)目不適配iOS7，就算出了iOS9感覺也不會讓你直接適配iOS8的，iOS7還會存在相當(dāng)長一段時間，畢竟以后新系統(tǒng)版本改變應(yīng)該都不會有iOS6到7變化那么大了，除非啥時候蘋果總設(shè)計師喬納森伊夫下臺了。