在iOS開發(fā)當(dāng)中，如果涉及到UITableViewCell的一些復(fù)雜UI的繪制時(shí)難免會(huì)碰到這么一個(gè)難題：UITableViewCell的高度如何設(shè)置！
的確廊鸥，我們就拿一個(gè)簡(jiǎn)單的例子來說：一個(gè)Cell上共耍，有頭像，有昵稱晰房，有評(píng)論內(nèi)容，還有圖片等控件，其中評(píng)論內(nèi)容的字?jǐn)?shù)并不能確定冈涧，那就決定了其每一個(gè)Cell的高度不定。比如下面我所做的一個(gè)項(xiàng)目中的評(píng)論：
從圖1中可以看到正蛙，Cell的頭像督弓，昵稱，發(fā)表日期的frame是固定的乒验，但是評(píng)論的內(nèi)容是有多有少的愚隧，因此frame并不確定，為此Cell的高度也不確定锻全。
在最開始開發(fā)的時(shí)候狂塘，大家都知道UITableView有一個(gè)獲取cell高度的代理方法，可以從這個(gè)方法當(dāng)中設(shè)置Cell的高度鳄厌，即：
那么自然而然的就可以想到這種辦法來設(shè)置高度：定義一個(gè)全局的Cell荞胡，在圖2的方法上給cell賦值，讓評(píng)論的Label執(zhí)行sizeToFit部翘，重新計(jì)算Cell的高度硝训，然后返回Cell的高度。
說實(shí)話，這種思路能實(shí)現(xiàn)效果窖梁，但是說實(shí)話：太Low了赘风，代碼太臟了。我能想到的就有下面幾個(gè)缺點(diǎn)：
1.給Cell賦了兩次值纵刘，效率不高
2.如果Cell的布局更改邀窃，那么要改的地方可就多了
3.邏輯有點(diǎn)反反復(fù)復(fù)
當(dāng)然，別人還寫過別的Cell高度計(jì)算方法假哎，但是異曲同工瞬捕，都十分的Low，不優(yōu)雅舵抹。代碼我就不po出來了肪虎，太臟，懶得po出來惧蛹。
那么有沒有一種簡(jiǎn)單有效并且十分優(yōu)雅的方式來實(shí)現(xiàn)Cell的自適應(yīng)高度呢扇救？當(dāng)然有。我上篇文章過：蘋果推薦的方案就是最優(yōu)雅的香嗓。
下面小編我就說說蘋果推薦的方案：
步驟1：設(shè)置tableView.rowHeight =?UITableViewAutomaticDimension迅腔。
解釋：如此設(shè)置之后，就不必要寫圖2的獲取高度方法了靠娱。（注：默認(rèn)值就是UITableViewAutomaticDimension沧烈，但是為了整個(gè)流程還是寫出來了，）像云。
步驟2：設(shè)置tableView.estimatedRowHeight = 100锌雀。
解釋：設(shè)置一個(gè)預(yù)估的行高，為了代碼的易讀性苫费，還是盡量要設(shè)置一個(gè)跟cell的高差不多的值汤锨。
做了上面的步驟之后，剩下的就是繪制Cell了百框，這里就涉及到一個(gè)思想：根據(jù)內(nèi)容自動(dòng)撐開闲礼。這個(gè)解釋起來就有點(diǎn)麻煩，先看代碼(控件的創(chuàng)建就不po出來了铐维，誰都會(huì))柬泽。
步驟3：
步驟4與步驟5：
根據(jù)圖3與圖4的代碼，作如下解釋：UITableViewCell上有一個(gè)contentView嫁蛇，contentView上面放置了所有的控件锨并。而這里的最頂部的控件avatarButton(頭像按鈕）頭部頂著contentView的頭部，contentLabel（評(píng)論label）頭部頂著avatarButton（頭像按鈕）的底部睬棚，同時(shí)contentLabel（評(píng)論label）底部有頂著contentView的底部第煮，為此就實(shí)現(xiàn)了avatarButton與contentLabel共同將contentView給撐開了解幼，也就把cell給撐開了。
那么會(huì)有人問：那contentLabel的高度怎么出來包警？其實(shí)從圖4可以看到我根本是沒有設(shè)置contentLabel的height撵摆，原因就是contentLabel的text就決定了contentLabel的高度，內(nèi)容的多少會(huì)自動(dòng)將contentLabel的高度撐開害晦。
這就是我上面說到的根據(jù)內(nèi)容自動(dòng)撐開的思想特铝。
以下就是一個(gè)簡(jiǎn)單的demo：代碼。
效果：
