Shulou(Shulou.com)06/02 Report--

This article mainly explains "analyzing iOS adaptive cell line height", the content of the article is simple and clear, easy to learn and understand, now please follow the editor's train of thought slowly in depth, together to study and learn "analyze iOS adaptive cell line height" bar!

Demand background

IOS cell line height adaptation is a very common requirement, but also a very simple requirement, I have encountered a lot of friends do not know how to achieve, here step by step analysis, for your reference.

Analysis of problems

Leaving aside the other implementation scenarios, let's now analyze the specific requirements, as shown in the figure:

In fact, the main implementation of these points can solve the so-called adaptive row height problem, let's gradually achieve this requirement.

Calculate the height of the UITableViewCell

When it comes to computing height, everyone is no stranger. The simplest and most common thing is to calculate the height of each child view and return the cell height we need, and then call it in UITableViewDelegate:

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

Or in the case of highly fixed, directly.

Self.tableView.rowHeight = 666,

But this requires that we need to get the data in model in advance to calculate the height of each control manually, which is both troublesome and not universal, so after autolayout comes out, as long as we add constraints to the top and bottom of the contentView of cell, the system can automatically help us achieve a high degree of self-adaptation, that is, we must ensure that the height of the cell can be stretched out by the quilt view, using the API of systemLayoutSizeFittingSize.

It's even easier after iOS8, directly using:

Self.tableView.estimatedRowHeight = 666scapeself.tableView.rowHeight = UITableViewAutomaticDimension

It is fine, where estimatedRowHeight is the estimated height. Note here that the return height method in delegate does not need to be written.

About this article, an article written by the author of UITableView+FDTemplateLayoutCel is very detailed, and it is recommended to learn about it first (those things that optimize UITableViewCell height computing)

But this method is actually very stuttering on cell with multiple sub-views, especially on iOS8, especially on iOS10, which has something to do with the high mechanism of the system, which can be explained here.

If separated from the autolayout, usually calculate the height, at the beginning is based on the height of the sub-control content in the cell to manually add up, but this method has to manually deal with the high logic, and horizontal and vertical screen switch, but also recalculate, in peacetime development will waste a lot of unnecessary energy. So later in the project, I got the actual frame of the child control by calling layoutSubviews, so we 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

CellBottomView is the child view at the bottom of cell. In order to improve computing efficiency, it is best to pass in. If you are not sure which child view is at the bottom, you can pass in an array of views contentViewSubViews. For more information on how to use it, please see demo.

Cache cell height

After the height has been calculated, normally our requirements have been met, but if every time this height is slipped, it will be recalculated due to the reuse mechanism of cell, and if the custom style of this cell is very complex, and there are too many child views, then a large number of calculations will certainly lose performance and lead to obvious stutters, so the caching mechanism is a necessary measure, not to mention that Apple also recommends doing so. Demo provides two API for calculating row height:

/ * * cell automatically calculates line height @ param tableView tableView@param indexPath indexPath@param contentViewWidth cell content width, uncertain transferable 0@return cell height * / + (CGFloat) FSCellHeightForTableView: (UITableView *) tableView indexPath: (NSIndexPath *) indexPath cellContentViewWidth: (CGFloat) contentViewWidth bottomOffset: (CGFloat) bottomOffset / * * cell automatically calculates the line height optimized version @ param tableView tableView@param indexPath indexPath@param cacheKey current cell unique identifier @ param contentViewWidth cell content width. Uncertain 0@return cell height * / + (CGFloat) FSCellHeightForTableView: (UITableView *) tableView indexPath: (NSIndexPath *) indexPath cacheKey: (NSString *) cacheKey cellContentViewWidth: (CGFloat) contentViewWidth bottomOffset: (CGFloat) bottomOffset

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

Both ways can accurately obtain the height of cell, the first implementation is more concise, the disadvantage is that when the data source changes, all the caches will empty the recalculated cache, such as reloadData; the second is to add an identifier based on the former to distinguish between different cell, it is recommended to use the second, will not empty the cache data, lightweight pages are no different. In short, both methods do fault-tolerant processing of cached data, and the following methods are supported:

@ 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

The realization of this requirement is relatively simple, that is, horizontal screen and vertical screen respectively use two sets of cached data, which do not affect each other, and automatically switch data sources when switching horizontal and vertical screens.

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

The final effect is shown in the figure:

In a word, these are the ideas for answering the questions. it is easy to use, and those who are interested can download demo to view: FSAutoAdjust-cellHeightDemo (local download)

Thank you for your reading, the above is the content of "analyzing iOS adaptive cell line height". After the study of this article, I believe you have a deeper understanding of the analysis of iOS adaptive cell line height, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.