UITableView 的加載原理
可變高的列表載體 Cell 是在開發(fā)中經(jīng)常處理到的一個技術(shù)點(diǎn)跷敬。
UITableViewCell 的高度需要在數(shù)據(jù)源代理中設(shè)置：
-(CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath{
return height;
}
heightForRowAtIndexPath方法會重復(fù)執(zhí)行很多次讯私，并且heightForRowAtIndexPath方法的執(zhí)行機(jī)制在不同版本 iOS 系統(tǒng)中還會有很大不同。在 iOS 11 中西傀，默認(rèn)已經(jīng)采取了一些優(yōu)化手段斤寇。
在 iOS 9上，要顯示一行 cell拥褂，至少要執(zhí)行 5 遍heightForRowAtIndexPath方法：
- UITableView 配置部分
- 當(dāng) UITableView 視圖即將被展示在屏幕上時娘锁，會拉取所有行高數(shù)據(jù)
- UITableView 在執(zhí)行
setLayoutMargins方法進(jìn)行自身布局時會拉取所有行高數(shù)據(jù) - UITableView 在執(zhí)行
layoutSubviews方法進(jìn)行子視圖布局時會再次拉取所有行高數(shù)據(jù)
- UITableViewCell 配置部分
- 當(dāng)使用 CellID 獲取與 UITableView 綁定的 cell 時會拉取本行 cell 的高度數(shù)據(jù)
- 當(dāng) cell 調(diào)用
layoutSubviews方法急性布局時會再次拉取本行 cell 的高度數(shù)據(jù)
在上面列舉的 5 種拉取 cell 高度數(shù)據(jù)的場景中，UITableView 配置部分只會在 UITableView 第一次展現(xiàn)在屏幕上時出現(xiàn)饺鹃，但是它拉取的是所有行的行高數(shù)據(jù)莫秆，如果表視圖有 100 行或者更多，那么這就是一個非常耗能的過程悔详。
UITableViewCell 的配置部分镊屎，只有當(dāng) cell 將要出現(xiàn)在屏幕上時才會出現(xiàn)，并且只拉取當(dāng)前 cell 的行高茄螃，這兩種場景會在用戶滑動 UITableView 時不斷被執(zhí)行缝驳，并且根據(jù) UITableView 的 cell 布局原理，系統(tǒng)會默認(rèn)準(zhǔn)備比當(dāng)前一屏高度所能容納cell 的個數(shù)多 1 個 cell。
當(dāng)執(zhí)行reloadData方法進(jìn)行界面刷新時用狱，系統(tǒng)先會把所有行的行高數(shù)據(jù)拉取一遍运怖，之后和 UITableViewCell 配置部分的場景一致，會拉取即將出現(xiàn)在屏幕上的 cell 的行高數(shù)據(jù)夏伊。下面是UITableView 的加載原理示意圖：
通過以上分析摇展，以 10 行數(shù)據(jù)的視圖為例，若一屏幕可以呈現(xiàn) 7 行數(shù)據(jù)（UITableView 需要準(zhǔn)備 8 行）署海，則在第一次展示 UITableView 視圖時吗购，會執(zhí)行 44 次heightForRowAtIndexPath医男，每次刷新 UITableView 需要執(zhí)行 24 次heightForRowAtIndexPath砸狞，如果 UITableView 行數(shù)增加的三位數(shù)，這個方法的執(zhí)行次數(shù)將會非常驚人镀梭。
可變行高的優(yōu)化方式
如果將復(fù)雜的計算代碼寫在heightForRowAtIndexPath中刀森，代價是巨大的”ㄕ耍滑動不流暢研底、屏幕卡頓等很多性能問題都是由于這個原因。對于行高固定的表格視圖透罢，可以直接設(shè)置 UITableView 的固定行高榜晦，如果行高是不固定的，則應(yīng)該想辦法讓heightForRowAtIndexPath方法完成最少的工作羽圃。
其實(shí)最少的工作莫過于拿一個高度直接返回乾胶，因此通常會將對應(yīng)行的行高計算一次后，把值保存起來朽寞，之后在執(zhí)行heightForRowAtIndexPath拉取行高時识窿，直接返回。具體操作比較靈活脑融，可以對應(yīng)一個數(shù)組屬性喻频，將計算后的行高放入數(shù)組，在每次取行高時肘迎，檢查數(shù)組中是否有已經(jīng)計算過的行高數(shù)據(jù)甥温，如果有直接返回。一種更好的方式是將行高數(shù)據(jù)封裝進(jìn) cell 的數(shù)據(jù)模型 Model 中妓布。
然而姻蚓，這只是提高了代碼性能，工作量和復(fù)雜度有增無減秋茫。iOS 7 之后史简，可以使用estimateRowHeight屬性，iOS 11 中，系統(tǒng)已經(jīng)默認(rèn)定義這個值為 44 來進(jìn)行列表視圖的性能優(yōu)化圆兵。這個值設(shè)置 cell 的大約行高跺讯。設(shè)置estimateRowHeight無需再設(shè)置rowHeight，也不需要實(shí)現(xiàn)heightForRowAtIndexPath殉农，系統(tǒng)會根據(jù) cell 中的 contentView 的約束來計算自己的行高刀脏。estimateRowHeight用于 UITableView的初始化，會影響到表格視圖右側(cè)滾動條的寬度超凳。當(dāng) cell 展現(xiàn)出來時愈污，真正的行高并不受這個屬性值的影響。
So轮傍，問題來了：如何讓cell 正確計算自己的高度暂雹？
答案是使用 AutoLayout，給 cell 布局足夠的壓力创夜，讓 contentView 的上下左右必須被內(nèi)部控件的約束撐滿杭跪。
Note：cell 的子視圖必須添加到 contentView 上，否則計算時會出現(xiàn)問題
這是性能最優(yōu)的列表渲染方式驰吓。
上面說預(yù)估行高會影響到 UITableView 右側(cè)滾動條的展示涧尿，如果每個 cell 行高跳躍跨度比較大，則滾動條寬度的配置會失準(zhǔn)檬贰，隨著用戶滑動姑廉，右側(cè)滾動條可能會出現(xiàn)長短跳躍的情況，如果想要精準(zhǔn)這個滾動條的配置翁涤，可以在如下代理方法中返回具體 cell 的估計行高：
- (CGFloat)tableView:(UITableView *)tableView estimatedHeightForRowAtIndexPath:(NSIndexPath *)indexPath {
//這里根據(jù)不同分區(qū)或者不同行設(shè)置估計的行高
return 44;
}
關(guān)于estimatedHeightForRowAtIndexPath這個方法還有一種應(yīng)用場景：
對于沒有使用自動布局桥言、cell 的高度需要手動計算的場景，如果實(shí)現(xiàn)了這個方法迷雪，并且實(shí)現(xiàn)了heightForRowAtIndexPath方法限书，那么heightForRowAtIndexPath方法會以懶加載的方法執(zhí)行，只有在 cell 將要被展現(xiàn)在屏幕上時才會被執(zhí)行章咧，這也可以有效減少由于高度計算帶來的性能負(fù)擔(dān)倦西。
Note: UITableViewCell在被創(chuàng)建出來時，寬度并不一定和 UITableView 的寬度一致赁严，如果需要獲取 cell 的絕對寬度來處理邏輯扰柠，那么需要在 cell的 layoutSubviews 方法里面進(jìn)行，此時 cell 的寬度才正確
高度不固定的列表分區(qū)頭疼约、尾視圖
一般頭尾高度固定卤档，不考慮它們帶來的性能問題。對比 cell 的布局原理程剥，也可以使用自動布局實(shí)現(xiàn)自適應(yīng)高度劝枣。
