The problem with iOS adaptive cell line height

Preface

Actually, I have been preparing to write this article for a long time, but I have never systematically organized the relevant demos. In addition, I recently resigned and was a bit depressed because of various things, so I kept procrastinating. After going home to rest for a while, I remembered the half-written demo. During this period of time before finding a job, I took the time to improve it and write a description document as a reminder.

[[248408]]

Demand background

The adaptive cell row height of iOS is a very common requirement, and also a very simple requirement. I have met many friends who don’t know how to implement it before. Here I will analyze it step by step for your reference.

Problem Analysis

I won’t talk about other implementation scenarios. Let’s analyze the specific requirements now, as shown in the figure:

Cell row height adaptive.png

In fact, the so-called adaptive row height problem can be solved by mainly implementing these points. Let's gradually realize this requirement.

Calculate height of UITableViewCell

When it comes to calculating height, everyone is familiar with it. The simplest and most common way is to calculate the height of each subview and accumulate it to return the cell height we need, and then call it in UITableViewDelegate:

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

Or if the height is fixed, directly

 self.tableView.rowHeight = 666;

However, this requires us to get the data in the model in advance to manually calculate the height of each control, which is troublesome and not universal. So after autolayout comes out, we only need to add constraints to the top, bottom, left, and right of the cell's contentView, and the system can automatically help us achieve height adaptation, that is, we must ensure that the height of the cell can be stretched by the subviews, using the systemLayoutSizeFittingSize API;

It is even simpler after iOS8, just use:

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

That's it, where estimatedRowHeight is the estimated height. Note that the return height method in the delegate does not need to be written again.

Regarding this aspect, the author of UITableView+FDTemplateLayoutCel wrote an article that is very detailed. It is recommended to learn about it first (Things about optimizing UITableViewCell height calculation)

However, this method is actually very laggy when sliding on cells with multiple subviews, especially on iOS8 and especially iOS10. This is related to the system's height calculation mechanism. For details, please refer to the above article and I will not explain it here.

If we take AutoLayout out of the equation, the height is calculated manually based on the height of the sub-controls in the cell. However, this method requires manual processing of the height calculation logic every time, and recalculation is required when the screen is switched between horizontal and vertical orientations, which wastes a lot of unnecessary energy in daily development. So later in my project, I called layoutSubviews to get the actual frame of the sub-control, so that I can get the cell height value we need, as shown in the following code:

 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;

The cellBottomView is the subview at the top of the cell. It is passed in first to improve calculation efficiency. If you are not sure which subview is at the bottom, you can pass in a view array contentViewSubViews. For detailed usage, see the demo.

Cache cell height

After the height is calculated, normally our needs have been met. However, if the height value is recalculated every time the cell is slid due to the reuse mechanism, and if the custom style of the cell is complex and there are too many subviews, then a large amount of calculation will definitely degrade performance and cause obvious lags. Therefore, the cache mechanism is a necessary measure, not to mention that Apple also recommends doing so;

The demo provides two APIs for calculating line height:

 /**
 Cell automatically calculates row height 
 
 @param tableView tableView
 @param indexPath indexPath
 @param contentViewWidth cell content width, if not sure, you can pass 0
 @return cell height
 */
 + (CGFloat)FSCellHeightForTableView:(UITableView *)tableView indexPath:(NSIndexPath *)indexPath cellContentViewWidth:(CGFloat)contentViewWidth bottomOffset:(CGFloat)bottomOffset; 
 
 /**
 Optimized version of cell automatic calculation of row height 
 
 @param tableView tableView
 @param indexPath indexPath
 @param cacheKey The current cell unique identifier
 @param contentViewWidth cell content width, if not sure, you can pass 0
 @return cell height
 */
 + (CGFloat)FSCellHeightForTableView:(UITableView *)tableView indexPath:(NSIndexPath *)indexPath cacheKey:(NSString *)cacheKey cellContentViewWidth:(CGFloat)contentViewWidth bottomOffset:(CGFloat)bottomOffset;

The first one uses an array to cache, passing in the indexPath of the corresponding cell as the array index value; the second one uses a dictionary to cache data, requiring a unique identifier cacheKey to be passed in to distinguish;

Both methods can accurately obtain the cell height. The first method is simpler to implement, but its disadvantage is that when the data source changes, all caches will be cleared and recalculated, such as when reloadData. The second method is to add an identifier to distinguish different cells based on the former. It is recommended to use the second method when using it. The cache data will not be cleared, and there is no difference in lightweight pages. In short, both methods have fault-tolerant processing for cached data and support the following methods:

 @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:)

Compatible with horizontal and vertical screens

This requirement is relatively simple to implement. The horizontal screen and the vertical screen use two sets of cached data respectively, which do not affect each other. The data source is automatically switched when the horizontal and vertical screens are switched.

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

***The effect achieved is shown in the figure:

FSAutoAdjust-cellHeightDemo.jpg