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

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

?

舊方法

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

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

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

NSDictionary *attrs = @{NSFontAttributeName : font};

整個流程的基本思想大概就是：用一個字符串對象來調(diào)用此方法，中間需要傳入一個屬性字典來告知字體和樣式，然后根據(jù)字符串長度的多少來算出應該給多大的frame。前面?zhèn)鬟M的size一般可以設置最大寬度。 此方法一般寫成分類便于調(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，如下把寬設置成了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界面再算自定義行高的方法。

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

圖1

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

圖2

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

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

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

[cell layoutIfNeeded];

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

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

?

預估行高方法

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

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

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

? ? ?

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

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

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

?

關于iOS8新的行高特性

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

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

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

以上也都是我個人對行高方法的理解，如有哪里理解的不對或是太片面歡迎指出。?

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

轉(zhuǎn)載于:https://www.cnblogs.com/dsxniubility/p/4590474.html

總結

以上是生活随笔為你收集整理的对tableView三种计算动态行高方法的分析的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。