在iOS開發(fā)當(dāng)中，如果涉及到UITableViewCell的一些復(fù)雜UI的繪制時(shí)難免會(huì)碰到這么一個(gè)難題：UITableViewCell的高度如何設(shè)置！
的確，我們就拿一個(gè)簡(jiǎn)單的例子來(lái)說(shuō)：一個(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的高度，即：
那么自然而然的就可以想到這種辦法來(lái)設(shè)置高度：定義一個(gè)全局的Cell，在圖2的方法上給cell賦值，讓評(píng)論的Label執(zhí)行sizeToFit，重新計(jì)算Cell的高度，然后返回Cell的高度。
說(shuō)實(shí)話，這種思路能實(shí)現(xiàn)效果，但是說(shuō)實(shí)話：太Low了，代碼太臟了。我能想到的就有下面幾個(gè)缺點(diǎn)：
1.給Cell賦了兩次值，效率不高
2.如果Cell的布局更改，那么要改的地方可就多了
3.邏輯有點(diǎn)反反復(fù)復(fù)
當(dāng)然，別人還寫過(guò)別的Cell高度計(jì)算方法，但是異曲同工，都十分的Low，不優(yōu)雅。代碼我就不po出來(lái)了，太臟，懶得po出來(lái)。
那么有沒(méi)有一種簡(jiǎn)單有效并且十分優(yōu)雅的方式來(lái)實(shí)現(xiàn)Cell的自適應(yīng)高度呢？當(dāng)然有。我上篇文章過(guò)：蘋果推薦的方案就是最優(yōu)雅的。
下面小編我就說(shuō)說(shuō)蘋果推薦的方案：
步驟1：設(shè)置tableView.rowHeight =?UITableViewAutomaticDimension。
解釋：如此設(shè)置之后，就不必要寫圖2的獲取高度方法了。（注：默認(rèn)值就是UITableViewAutomaticDimension，但是為了整個(gè)流程還是寫出來(lái)了，）。
步驟2：設(shè)置tableView.estimatedRowHeight = 100。
解釋：設(shè)置一個(gè)預(yù)估的行高，為了代碼的易讀性，還是盡量要設(shè)置一個(gè)跟cell的高差不多的值。
做了上面的步驟之后，剩下的就是繪制Cell了，這里就涉及到一個(gè)思想：根據(jù)內(nèi)容自動(dòng)撐開。這個(gè)解釋起來(lái)就有點(diǎn)麻煩，先看代碼(控件的創(chuàng)建就不po出來(lái)了，誰(shuí)都會(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ì)有人問(wèn)：那contentLabel的高度怎么出來(lái)？其實(shí)從圖4可以看到我根本是沒(méi)有設(shè)置contentLabel的height，原因就是contentLabel的text就決定了contentLabel的高度，內(nèi)容的多少會(huì)自動(dòng)將contentLabel的高度撐開。
這就是我上面說(shuō)到的根據(jù)內(nèi)容自動(dòng)撐開的思想。
以下就是一個(gè)簡(jiǎn)單的demo：代碼。
效果：
