如何在UITableViewCell中使用Autolayout來實現Cell的內容和子視圖自動計算行高，並且能夠保持平滑滾動的？
這個問題得到了300+的支持和450+的收藏，答案得到了730+的支持，很詳細的說明了如何在iOS7和iOS8上實現UITableView的動態行高功能，並且這個答案對實現UICollectionView的動態行高也具有參考意義。所以在這里將這個答案翻譯了一下，希望對大家有所幫助。以下是答案的全文翻譯：
答案略長，如果你不喜歡細讀，可以直接看這兩個示例的代碼：
核心概念
不管你是在哪個iOS版本上做開發，以下步驟中的前兩個步驟都是必須的：
1、設置好布局約束條件
在UITableViewCell子類中，添加布局約束，使得cell子視圖的邊緣固定(pin)到cell的contentView的邊緣（最重要的是要有頂部和底部的邊距約束條件）。注意：不要將子視圖的邊距約束固定到cell本身上了，只能固定到cell的contentView上！ 確保每個子視圖垂直方向上的內容壓縮阻力(compression resistance)和吸附性約束(hugging constraints)沒有被你添加的更高優先級的約束條件覆蓋，讓這些子視圖的固有內容尺寸(intrinsic content size)來驅動contentView的高度。（沒看懂？點這里。）
記住，要點是讓cell的子視圖與contentView之間產生垂直的連結，讓它們能夠對contentView“施加壓力”，使contentView擴展以適合它們的尺寸。下面用一個cell和一些子視圖作為示例，展示了你的一些(不是全部！)布局約束應該看起來是什么樣的：
可以設想，隨着更多的文本被添加到上例中“Multi-line body”那個label上，它需要垂直地增高以適合文本，這將有效地迫使cell的高度增加。（當然，你需要正確地設置約束條件，以使其正常的工作！）
如何設置正確的約束條件，絕對是使用Autolayout實現動態行高時最難最重要的部分。如果弄錯了，它就可能無法正常工作——所以，不要着急，慢慢來！我建議你用代碼來設置布局約束，這樣你就完全知道每個布局約束被加到了什么地方，出問題時也更容易調試。特別如果使用一些優秀開源庫，可以讓用代碼設置約束和用Interface Builder設置約束一樣簡單直觀，並且功能還更強大。這里也有一個由我設計和維護的專用庫：https://github.com/smileyborg/PureLayout
- 如果你用代碼來設置布局約束，你應該在UITableViewCell子類的
updateConstraints方法里面一次性完成。注意，updateConstraints可能不止被調用一次，因此要避免重復添加相同的布局約束。在updateConstraints中，可以將添加布局約束的代碼包在一個if條件語句中(比如用一個叫didSetupConstraints的布爾屬性，運行一次添加布局約束的代碼后就將其設置為YES)，以確保不重復添加相同的布局約束。另外，更新已有布局約束的代碼（比如調整布局約束的constant屬性），也應該將它們放置在updateConstraints中，但是要在didSetupConstraints條件語句的外面，這樣才可以確保每次調用的時候都會被執行。
2. Cell使用具有唯一性的重用標示符
在cell里面，為每一組特定的約束條件，使用一個特定的cell重用標示符。換句話說，如果cell有多種不同的布局，每一種布局應當有其對應的重用標示符。（當cell有多種不同數量的子視圖的時候，或者子視圖以一種獨特的方式布局的時候，這些情況下你就需要使用一個新的重用標示符。）
例如，要在一個cell中顯示一條email消息，可能會有4種獨特的布局：第一種，只有主題的消息；第二種，帶主題和正文的消息；第三種，帶主題和圖片附件的消息；第四種，帶主題、正文和圖片附件的消息。每一種布局都需要完全不同的布局約束才能實現。因此，一旦cell被初始化並且布局約束被加到其中任意一種類型的cell上后，cell應當得到一個唯一的重用標示符來指定該cell類型。這就意味着，當你dequeue重用一個cell的時候，該類型cell的布局約束已經添加好了，可以直接使用。
注意，由於固有內容尺寸的不同，具有相同布局約束的cell仍然可能具有不同的高度！不要混淆了布局（不同的約束）和由不同內容尺寸而計算出（通過相同的布局約束來計算）的不同視圖frame這兩個概念，它們根本是完全不同的兩個東西。
- 不要將擁有不同布局約束條件的cell丟到同一個重用池當中（也就是使用相同的重用標示符），然后又在每次dequeue過后將舊的約束移除，又從頭開始重新添加約束。自動布局引擎內部並沒有被設計來可以處理大規模的約束更改，你會看到大量的性能問題。
iOS8 - Self-Sizing Cells
3. 啟用估算行高
在iOS8上，蘋果將許多在iOS8之前比較難實現的東西都內置實現了。為了讓cell實現self-sizing的機制，必須先將tableView的rowHeight屬性設置為常量UITableViewAutomaticDimension。然后，只需將tableView的estimatedRowHeight屬性設置為非零值即可開啟行高估算功能，例如：
1 2 |
|
這樣做就為tableView上還沒有顯示在屏幕上的cell提供了一個臨時的估算的行高。然后，當cell即將滾入屏幕范圍內的時候，會計算出實際的高度。為了確定每一行的實際高度，tableView會自動讓每個cell基於其contentView的已知固定寬度（tableView的寬度，減去其他額外的，像section index或accessoryView這些寬度）和被加到contentView及其子視圖上的自動布局約束規則來計算contentView的高度。一旦真正的行高被計算出來后，舊的估算的行高會被更新為這個真實的行高（並且其他任何需要對tableView的contentSize或contentOffset的更改都自動替你完成了）。
一般來說，行高估算值不需要太精確——它只是被用來修正tableView中滾動條的大小的，當你在屏幕上滑動cell的時候，即便估算值不准確，tableView還是能很好地調節滾動條。將tableView的estimatedRowHeight屬性設置成（在viewDidLoad或類似的方法中）一個接近於“平均”行高的常量值即可。只有行高變化很極端的時候（比如相差一個數量級），才會在滾動時產生滾動條“跳躍”的現象。這個時候，你才應當實現tableView:estimatedHeightForRowAtIndexPath:方法，為每一行返回一個更精確的估算值。
iOS7支持（需要自己實現cell尺寸自適應功能）
3. 完成一個完整的布局過程 & 計算cell的高度
首先，為每一個cell都初始化一個離屏(offscreen)實例，為每個重用標示符實例化一個與之對應的cell實例，這些cell完全用於高度計算。（離屏表示cell的引用被存儲在view controller的一個屬性或實例變量之中，並且這個cell絕對不會被用作tableView:cellForRowAtIndexPath:方法的返回值以實際呈現在屏幕上。）接着，這個cell的內容（例如，文本、圖片等等）還必須和會被顯示在table view中的內容完全一致。
然后，強制cell立即更新子視圖的布局，再用cell的contentView調用systemLayoutSizeFittingSize:方法計算出cell所需的高度是多少。使用UILayoutFittingCompressedSize參數可以得到適合cell中所有內容所需的最小尺寸。然后其高度就可以作為tableView:heightForRowAtIndexPath:方法的返回值。
4. 使用估算的行高
如果你的table view超過了幾十行，你會發現自動布局約束的解決方式在第一次加載table view的時候會迅速地卡住主線程。因為，在第一次加載過程中，每一行都會調用tableView:heightForRowAtIndexPath:方法（為了計算滾動條的尺寸）。
iOS7中，你可以（也絕對應該）使用table view的estimatedRowHeight屬性。這樣會為還不在屏幕范圍內的cell提供一個臨時估算的行高值。然后，當這些cell即將要滾入屏幕范圍內的時候，真實的行高值會被計算出來（通過tableView:heightForRowAtIndexPath:方法），估算的行高就會被替換掉。
一般來說，行高估算值不需要太精確——它只是被用來修正tableView中滾動條的大小的，當你在屏幕上滑動cell的時候，即便估算值不准確，tableView還是能很好地調節滾動條。將tableView的estimatedRowHeight屬性設置成（在viewDidLoad或類似的方法中）一個接近於“平均”行高的常量值即可。只有行高變化很極端的時候（比如相差一個數量級），才會在滾動時產生滾動條“跳躍”的現象。這個時候，你才應當實現tableView:estimatedHeightForRowAtIndexPath:方法，為每一行返回一個更精確的估算值。
5. 緩存行高（如果需要）
如果上面提到的你都做了，但是tableView:heightForRowAtIndexPath:的性能仍然慢的不可接受。非常不幸，你需要給行高做一些緩存（這是蘋果的工程師們給出的改進建議）。大體的思路是，第一次計算時讓自動布局引擎解析約束條件，然后將計算出的行高緩存起來，以后所有對該cell的高度的請求都返回緩存值。當然，關鍵還要確保任何會導致cell高度變化的情況發生時你都清除了緩存的行高——這通常發生在cell的內容變化時或其他重大事件發生時（比如用戶調節了動態類型文本大小(Dynamic Type text size)的滑動條）。
iOS7示例代碼（包含詳細的注釋）
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 |
|