8自适应高度 ios

2018-07-18 10:17:37 LiuChongFaye 阅读数 5518

在iOS开发当中,如果涉及到UITableViewCell的一些复杂UI的绘制时难免会碰到这么一个难题:UITableViewCell的高度如何设置!

的确,我们就拿一个简单的例子来说:一个Cell上,有头像,有昵称,有评论内容,还有图片等控件,其中评论内容的字数并不能确定,那就决定了其每一个Cell的高度不定。比如下面我所做的一个项目中的评论:

 

图1:简单的评论

从图1中可以看到,Cell的头像,昵称,发表日期的frame是固定的,但是评论的内容是有多有少的,因此frame并不确定,为此Cell的高度也不确定。

在最开始开发的时候,大家都知道UITableView有一个获取cell高度的代理方法,可以从这个方法当中设置Cell的高度,即:

 图2:获取高度方法

那么自然而然的就可以想到这种办法来设置高度:定义一个全局的Cell,在图2的方法上给cell赋值,让评论的Label执行sizeToFit,重新计算Cell的高度,然后返回Cell的高度。

说实话,这种思路能实现效果,但是说实话:太Low了,代码太脏了。我能想到的就有下面几个缺点:

1.给Cell赋了两次值,效率不高

2.如果Cell的布局更改,那么要改的地方可就多了

3.逻辑有点反反复复

当然,别人还写过别的Cell高度计算方法,但是异曲同工,都十分的Low,不优雅。代码我就不po出来了,太脏,懒得po出来。

那么有没有一种简单有效并且十分优雅的方式来实现Cell的自适应高度呢?当然有。我上篇文章过:苹果推荐的方案就是最优雅的

下面小编我就说说苹果推荐的方案:

步骤1:设置tableView.rowHeight = UITableViewAutomaticDimension。

解释:如此设置之后,就不必要写图2的获取高度方法了。(注:默认值就是UITableViewAutomaticDimension,但是为了整个流程还是写出来了,)。

步骤2:设置tableView.estimatedRowHeight = 100。

解释:设置一个预估的行高,为了代码的易读性,还是尽量要设置一个跟cell的高差不多的值。

做了上面的步骤之后,剩下的就是绘制Cell了,这里就涉及到一个思想:根据内容自动撑开。这个解释起来就有点麻烦,先看代码(控件的创建就不po出来了,谁都会)。

步骤3:

图3:设置头像的约束

步骤4与步骤5:

图4:设置评论的约束

根据图3与图4的代码,作如下解释:UITableViewCell上有一个contentView,contentView上面放置了所有的控件。而这里的最顶部的控件avatarButton(头像按钮)头部顶着contentView的头部,contentLabel(评论label)头部顶着avatarButton(头像按钮)的底部,同时contentLabel(评论label)底部有顶着contentView的底部,为此就实现了avatarButton与contentLabel共同将contentView给撑开了,也就把cell给撑开了。

那么会有人问:那contentLabel的高度怎么出来?其实从图4可以看到我根本是没有设置contentLabel的height,原因就是contentLabel的text就决定了contentLabel的高度,内容的多少会自动将contentLabel的高度撑开。

这就是我上面说到的根据内容自动撑开的思想。

以下就是一个简单的demo:Github

 

2016-09-03 12:47:56 qq_16800895 阅读数 330

做了一年的ios开发,一直从社区中获取各种帮助,也是时候回报社会写写博客啦,主要是自己初学时遇到的一些问题的总结,希望能帮到大家,第一篇博客,写的不好请轻喷啦。
这里所说的自适应高度都是根据autolayout的约束来自适应高度,没有学过autolayou的同学请先移步学习哦。
tableview的自适应高度分为ios8.0前和ios8.0后
1、ios8.0后
首先说简单的ios8.0后的,苹果已经帮我们做了优化,如果项目不支持ios8.0以前的版本的话两句代码即可搞定。曾经在用过swift上用过没有问题,但是在oc上用有时候不知道为什么会计算的不是自己想要的高度,所以还是比较习惯自己去计算

self.tableView.estimatedRowHeight=71.0f;
self.tableView.rowHeight=UITableViewAutomaticDimension; 

注意不要去实现heightForRow代理方法即可。
2、ios8.0以前
废话不多说了我就直接上码吧

- (CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath{
    // 创建可重复使用的Cell
    static MainCell *sizingCell = nil;
    static dispatch_once_t onceToken;
    dispatch_once(&onceToken, ^{
        sizingCell = [self.tableView dequeueReusableCellWithIdentifier:reuseID];
        if (!sizingCell) {
            sizingCell = [[[NSBundle mainBundle] loadNibNamed:reuseID owner:self options:nil] lastObject];
        }
    });

    //设置cell自控件内容
    sizingCell.titleStr = self.titleStr;
    sizingCell.contentStr=self.contentStr;
    [sizingCell loadData];

    //先让约束实现
    sizingCell.bounds = CGRectMake(0.0f, 0.0f, CGRectGetWidth(tableView.frame), CGRectGetHeight(sizingCell.bounds));
    [sizingCell setNeedsLayout];
    [sizingCell layoutIfNeeded];
    //获取cell的contentView的真实高度,因为分隔线是被加在cell底边和contentView底边,所以要加上1px的高度
    CGSize size = [sizingCell.contentView systemLayoutSizeFittingSize:UILayoutFittingCompressedSize];
    return size.height + 1.0f;
} 

主要根据cell里面的内容计算cell的高度,用多线程只创建一次cell确保不会占用太多内存,然后设置cell的内容,再实现约束,最后计算高度。
各位可以看着如下demo来看,里面还有一些细节需要注意的
1、RWLabel是用来解决ios6.0版本前的计算不准确的问题(lable的继承类换成RWLabel)
2、注意要把label的行数设置成0行哦
3、要记得勾选label的preferred wi.. 属性更新其大小
我的git上面的demo

2015-11-01 19:52:49 tongwei117 阅读数 4717

对tableView三种计算动态行高方法的分析

tableView是一个神奇的东西,可以这么说,就算是一个初学者如果能把tableView玩的很6,那编一般的iOS的需求都问题不大了。tableView是日常开发中用烂了的控件,但是关于tableView中的自定义cell的动态行高,还是有一些玄机的。笔者本次主要是因为预估行高的方法的问题作为了一个契机顺带写了此文对几种动态行高方法的分析。

旧方法

现在常规的动态行高的计算方法还是用

[str boundingRectWithSize:size options:NSStringDrawingUsesLineFragmentOrigin attributes:attrs context:nil].size

这其中需要先传入一个最大尺寸和一个属性字典,特殊的格式要求都写在属性字典中。

NSDictionary *attrs = @{NSFontAttributeName : font};

整个流程的基本思想大概就是:用一个字符串对象来调用此方法,中间需要传入一个属性字典来告知字体和样式,然后根据字符串长度的多少来算出应该给多大的frame。前面传进的size一般可以设置最大宽度。 此方法一般写成分类便于调用。

#import "NSString+Size.h"
@implementation NSString (Size)
/**
* 类方法计算size大小
*/
+ (CGSize)sizeWithString:(NSString *)str andFount:(UIFont *)font andMaxSize:(CGSize)size
{
NSDictionary *attrs = @{NSFontAttributeName : font};
return [str boundingRectWithSize:size options:NSStringDrawingUsesLineFragmentOrigin attributes:attrs context:nil].size;
}
/**
* 对象方法计算size大小
*/
- (CGSize)sizeWithFount:(UIFont *)font andMaxSize:(CGSize)size;
{
NSDictionary *attrs = @{NSFontAttributeName : font};
return [self boundingRectWithSize:size options:NSStringDrawingUsesLineFragmentOrigin attributes:attrs context:nil].size;
}
@end

这些方法从字面上看也比较容易理解。
调用时的代码基本就是取到一个字符串,传入一个font和一个最大size,如下把宽设置成了270就是最大宽度为270高度往下顺延的话就把高度写成MAXFLOAT

NSString *text = _message.text;
CGSize textSize = [text sizeWithFount:[UIFont systemFontOfSize:14] andMaxSize:CGSizeMake(270, MAXFLOAT)];

然后在frame中取到最下面一个空间的maxY,从而让每一个cell在set方法中就得到自己的行高 ,然后通过cell的类方法返回。

新方法
随着iOS8的自动布局和Interface builder越来越成熟,逐渐衍生出了一种先用storyboard或xib界面再算自定义行高的方法。
这种方法一般需要先搭建一个图形化界面。如下图大概搭一个比较复杂的cell。

这里写图片描述

首先可以清晰的看出,用IB搭建看上去很快就能搭建完毕,并且有的图片或是view的背景设置了之后能看出界面大概的感觉。这里需要注意的就是label设置约束的方法,普通控件一般都要设置四个约束才能固定位置,label和button只设置两个约束(只需要写固定位置的两条约束,不需要写自身宽高的约束)也不会报错,但是需要在editor中设置sizeToFit,这样可以根据字数自动给你分配一个控件的大小。

这里写图片描述

一般评论类的label肯定都是字数比较多的,这时2条约束就不够了需要再设置一个最大宽度的约束,如图1我设置的方法是,把评论label与左右边界的间隙给设定了,这个在IB中叫Leading(前)和Training(后),高的约束我们没有写如果字数超过了一行他就会自己往下顺延。 这么写相较于把宽度约束写死的好处是会自动根据屏幕适配不管屏幕多大都是左右空出若干像素。这样做也有局限性,就是假设给这个label设置一个背景色,如果字数就5个字背景色也会延伸到一整行。如果QQ聊天页面也这样做,不管是几个字都是一整行的聊天气泡那会很丑。于是有了一种少则背景也少,多也不超过最大宽度的做法,就是设置label的width的less than来设置最大宽度。这么做如果字数不足一行的话,约束也会自动缩到与label长度匹配。

这里写图片描述
如果这个页面用纯手码写,可想而知会非常麻烦。
用IB页面做自定义行高的计算方法也更简单。也就是里面模型的set方法正常写,给自己的UI控件赋值。然后在tableView的行高方法heightForRow中,先给cell的模型赋值,然后再使用一次

[cell layoutIfNeeded];

他会自动根据填进去数值来布局,然后我们直接在这个方法中返回最下面一个控件的bottom位置+若干间隙,以此来作为行高即可。
真正的布局其实也就是用了这一行代码,并且可以做到屏幕适配不用if判断各种frame。但这样写也有一些问题,首先就是这么写从结构上来看不合理。这个行高方法中不应该写这些赋值语句。官方还是其他大神说不合理的原因,应该是这个方法应该仅仅是用来算出行高并显示的,会调用多次,如果在这里赋值性能会很差。这么说有道理,把这里面的每行代码都看一遍,能看出性能较差的方法主要就是这两行:1.给cell里模型赋值 2.layoutIfNeed 。如果调用多次这个方法那这两行也会执行多次,所以这应该是不科学的。  我实际的做法是在其中设置一个行高缓存字典,并且找一个肯定不会重复的标识来做key值。每一行cell计算行高前都先拿自己的id去行高缓存字典里取一下看有没有值,如果有则直接返回对应的value,如果没有再计算。这样可以使这性能比较差得两行代码只执行一次。达到优化效果。

MTFBNoReplyCell *feedbackNoreplyCell = [MTFBNoReplyCell cell];
NSString *thisId =[NSString stringWithFormat:@"%d", feedbackModel.feedbackid];
// MTLog(@"%@",[self.cellHeightCache valueForKey:thisId]);
CGFloat cacheHeight = [[self.cellHeightCache valueForKey:thisId] doubleValue];
if (cacheHeight) {
// MTLog(@"返回缓存的行高");
return cacheHeight;
}
// MTLog(@"耗性能的行高");
feedbackNoreplyCell.feedbackDetailModel = feedbackModel;
[feedbackNoreplyCell layoutIfNeeded];
[self.cellHeightCache setValue:@(feedbackNoreplyCell.replyBtn.bottom+16) forKey:thisId];
return feedbackNoreplyCell.replyBtn.bottom+16;

大概的思想如上所示。 如果这个tableView的数据不会随时改变较为固定的话,可以把取到的模型作为value以indexpath.row为key存一个缓存字典这样也能优化一些。行高方法里取过了,cellForRow就可以直接用了。

预估行高方法
这里我想重点说一下这个预估行高的方法estimatedHeightForRowAtIndexPath 。这个方法可能大部分人一说到这个,就说这个方法好啊,预估行高方法可以减少heightForRow的调用次数,使得性能达到优化。 孰不知实际运用中是存在着一定问题的。
就拿整个tableView来说 他是继承自scrowView的,scrowView能够滚动是因为它有contentSize。tableView在初次加载的时候也需要算出自己的contentSize(而且会算不止一次),也就是说需要调一下所有的行高方法然后自己内部给他累加一下算出整个contentSize。如果在行高方法里设置一个打印会看到方法会调用很多次。这时如果有一个预估方法return 100。那它就能很快算出总值了。就会减少行高方法的调用,在实际用到某一行时再调用。
但是可能会出现如下左图的问题。

问题的原因就是,一开始预估方法给每行预估了一个行高,然后后面实际加载的行高与预估的行高不合时,会出现cell上下的“窜动”给人卡卡的感觉。对此我的思想是,如果是动态的且cell的复杂度较高,行与行之间差距大的时候,就直接不要写预估行高方法了吧,让他自己算吧哪怕多调用几次,毕竟上面已经写过缓存行高字典了,性能姑且是可以hold住了,并且不会出现“窜动”情况。如右图所示。
但是如果是固定行高有一种或是三种不同的cell,行高分别是120,150,200。你在预估行高了写个return 150。遇到行高与预估不等时,却也不会出现“窜动”。我推测应该是estimatedHeightForRow不能和HeightForRow里面的layoutIfNeed同时存在,这两者同时存在才会出现“窜动”的bug。所以我的建议是:只要是固定行高就写预估行高来减少行高调用次数提升性能。如果是动态行高就不要写预估方法了,用一个行高的缓存字典来减少代码的调用次数即可。
关于上面行高的新方法和旧方法的对比,我的总结是:首先新方法肯定性能上是比旧方法要差一些的。具体体现在两个方面,1是在IB页面开发的东西,程序一启动就会全部加载进内存由系统托管,以至于有的界面你已经把导航控制器的栈顶控制器给pop了,发现内存还没有下降。2是新方法和旧方法有一个本质的区别,旧方法是直接算,算你需要多大的尺寸就告诉你,新方法则是先强制布局然后看你占了多大的尺寸再告诉你,这两者一对比,新方法就是多了一个强制布局的过程,这肯定是会对性能造成一定影响的,那具体影响多少?关于滑动计算行高我还不知道有什么可以明确一个数据的对比,我只能用肉眼看屏幕的滑动来区分对比,我的感觉就是基本没差别,如果要说有的话新方法可能会非常轻微的卡顿,换而言之就是同一个页面,旧方法编完需要10小时,新方法编完需要3小时,但是新方法的性能略差于旧方法。就看你自己怎么衡量了。当然非常庞大的项目还是建议用旧方法,毕竟一点一点的“略差于”积累在一起就是很差了。

关于iOS8新的行高特性

首先是有了一个新的用法。写在viewdidload里

self.tableView.estimatedRowHeight = 50.0f;
self.tableView.rowHeight = UITableViewAutomaticDimension;

这就没什么好说的了,苹果自己帮你把动态行高计算了,所有乱七八糟的都不用管了。 但是暂时说这些基本没用,因为现在还看不到哪个公司的项目不适配iOS7,就算出了iOS9感觉也不会让你直接适配iOS8的,iOS7还会存在相当长一段时间,毕竟以后新系统版本改变应该都不会有iOS6到7变化那么大了,除非啥时候苹果总设计师乔纳森伊夫下台了。

2019-09-09 22:24:08 chunbo4007 阅读数 1026

1.实现UITableViewDelegate中的方法

先设置cell的contentview中label根据内容自动换行
numberOfLines=0
实现UITableViewDelegate中的方法
- (CGFloat)tableView:(UITableView )tableView estimatedHeightForRowAtIndexPath:(NSIndexPath )indexPath{
return UITableViewAutomaticDimension;
}
2.根据content view设置cell的frame
先设置cell的contentview中label根据内容自动换行
numberOfLines=0
cell根据Label大小 修改cell此时的尺寸
CGRect bounds = cell.contentLb.bounds;
bounds.size.height = bounds.size.height + 10;
cell.bounds = bounds;
或者在viewDidLoad里写下这两句

self.chatTableView.rowHeight = UITableViewAutomaticDimension;
self.chatTableView.estimatedRowHeight = 70;//这句必须写上值可以为自己估算的cell的高

转载于:https://my.oschina.net/zyboy/blog/617428

2019-06-23 09:07:26 AdrianAndroid 阅读数 103

IOS学习-UITableViewCell自适应高度

  1. 将子布局包裹在父布局内,并将父布局撑开即可达到效果。