關于iOS自適應cell行高的那些事兒

2019-10-21 18:39:22

字體：大中小

來源：轉載

供稿：網友

前言

其實早就準備寫這篇文章了，但是一直沒有系統去整理一下相關的demo，加上最近離職了，各種事情忙的有點郁悶，所以一直拖沓了下來。回家休息了一段時間想起來寫了一半的demo，在還沒找工作的這段空擋時間抽空完善了一下再寫篇說明文檔備忘一下。

需求背景

iOS的cell 行高自適應是個非常常見的需求，也是一個非常簡單的需求，之前我遇到過很多小伙伴不知道怎么來實現，在這里就一步步的來分析一下，供大家參考。

問題分析

其他的實現場景就不說了，我們現在來分析一下具體的需求，如圖所示：

iOS,自適應,cell,行高

其實主要實現這幾點就可以解決所謂的自適應行高的問題，下面我們就來逐步實現這個需求。

計算UITableViewCell的高度

說到計算高度，大家都不陌生，最簡單常見的就是計算出每個子視圖的高度累積起來返回我們所需要的cell高度，然后在UITableViewDelegate中調用：

- (CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath{return 666;}

或者高度固定的情況下直接

self.tableView.rowHeight = 666;

但是這就要求我們需要提前拿到model中的數據來手動計算每個控件的高度，這樣既麻煩又不能通用，所以在autolayout出來之后我們只要給cell的contentView的上下左右都添加了約束，系統就可以自動的幫我們實現高度的自適應，就是一定要保證cell的高度可以被子視圖撐開就可以了，利用的是systemLayoutSizeFittingSize這個API；

iOS8之后就更簡單了，直接使用：

self.tableView.estimatedRowHeight = 666;self.tableView.rowHeight = UITableViewAutomaticDimension;

就可以了，其中estimatedRowHeight是預估高度，這里要注意delegate中的返回高度方法就不用在寫了。

關于這方面的文章，UITableView+FDTemplateLayoutCel的作者寫的一篇文章十分詳細，建議先去了解一下

但是這個方法實際上在有多個子視圖的cell上滑動是很卡頓的，特別是在iOS8尤其是iOS10上卡頓尤為明顯，這跟系統的算高機制有一定關系，具體可以看上面的文章，這里不再解釋了。

如果脫離開autolayout來說，平時計算高度的話，最開始都是根據cell內子控件內容的高度來手動累加起來，但是這個方法每次都要去手動處理其中的算高邏輯，而且橫豎屏切換的時候還要重新計算，在平時開發中就會浪費大量不必要的精力。所以后來我在項目中是通過調用layoutSubviews來獲取到子控件的實際frame，這樣就可以得到我們所需的cell高度值，如下代碼所示：

cell.frame = CGRectSetWidth(cell.frame, contentViewWidth);cell.contentView.frame = CGRectSetWidth(cell.contentView.frame, CGRectGetWidth(tableView.frame));[cell layoutIfNeeded];UIView *cellBottomView = nil;if (cell.FS_cellBottomView) {cellBottomView = cell.FS_cellBottomView;}else if (cell.FS_cellBottomViews && cell.FS_cellBottomViews.count > 0) {cellBottomView = cell.FS_cellBottomViews[0];for (UIView *view in cell.FS_cellBottomViews) {if (CGRectGetMaxY(view.frame) > CGRectGetMaxY(cellBottomView.frame)) {cellBottomView = view;}}}else {NSArray *contentViewSubViews = cell.contentView.subviews;if (contentViewSubViews.count == 0) {cellBottomView = cell.contentView;}else{cellBottomView = contentViewSubViews[0];for (UIView *view in contentViewSubViews) {if (CGRectGetMaxY(view.frame) > CGRectGetMaxY(cellBottomView.frame)) {cellBottomView = view;}}}}CGFloat cellHeight = CGRectGetMaxY(cellBottomView.frame) + bottomOffset;

其中的cellBottomView是位于cell最底部的子視圖，為了提高計算效率最好傳入，如果不確定哪個子視圖在最下面，可以傳入一個視圖數組contentViewSubViews，詳細使用方式可以查看demo。

緩存cell高度

高度計算出來后，正常來說我們的需求已經達到了，但是如果這個高度值每次滑動的時候由于cell的復用機制都會重新計算，若果這個cell的自定義樣式很復雜，子視圖太多，那么大量的計算一定會損耗性能而導致明顯的卡頓，所以緩存機制就是個必要的措施，更何況蘋果也建議這樣做；
demo提供了兩個計算行高的API：

/**cell自動計算行高@param tableView tableView@param indexPath indexPath@param contentViewWidth cell內容寬度，不確定可傳0@return cell高度*/+ (CGFloat)FSCellHeightForTableView:(UITableView *)tableView indexPath:(NSIndexPath *)indexPath cellContentViewWidth:(CGFloat)contentViewWidth bottomOffset:(CGFloat)bottomOffset;/**cell自動計算行高優化版@param tableView tableView@param indexPath indexPath@param cacheKey 當前cell唯一標識符@param contentViewWidth cell內容寬度，不確定可傳0@return cell高度*/+ (CGFloat)FSCellHeightForTableView:(UITableView *)tableView indexPath:(NSIndexPath *)indexPath cacheKey:(NSString *)cacheKey cellContentViewWidth:(CGFloat)contentViewWidth bottomOffset:(CGFloat)bottomOffset;

第一種使用數組來做緩存，傳入對應cell的indexPath作為數組索引值；第二種則采用字典來緩存數據，要求傳入一個唯一標識符cacheKey來區分；

兩種方式都可以準確獲得cell高度，第一種實現更簡潔，缺點就是數據源發生變化時，所有的緩存就會清空重新計算后緩存，比如reloadData的時候；第二種就是在前者的基礎上添加一個區分不同cell的標識符，使用時還是建議使用第二種，不會清空緩存數據，輕量級頁面沒什么區別。總之兩種方法都做了緩存數據的容錯處理，支持以下方法：

@selector(reloadData),@selector(insertSections:withRowAnimation:),@selector(deleteSections:withRowAnimation:),@selector(reloadSections:withRowAnimation:),@selector(moveSection:toSection:),@selector(insertRowsAtIndexPaths:withRowAnimation:),@selector(deleteRowsAtIndexPaths:withRowAnimation:),@selector(reloadRowsAtIndexPaths:withRowAnimation:),@selector(moveRowAtIndexPath:toIndexPath:)

兼容橫豎屏

這個需求實現較為簡單，就是橫屏和豎屏分別采用兩套緩存數據，互不影響，切換橫豎屏的時候自動切換數據源。

- (NSMutableArray *)indexCacheArrForCurrentOrientation{return UIDeviceOrientationIsPortrait([UIDevice currentDevice].orientation) ? self.indexCacheArr_Portrait: self.indexCacheArr_Landscape;}

最后實現的效果如圖所示：

iOS,自適應,cell,行高