这算是个老生常谈的话题了,从最早的时候使用Frame类来持有模型,然后在这个Frame类中手动计算高度,到后来的自动计算行高。下面就来说说我使用Masonry做高度自适应遇到的坑吧!
之前做高度自适应有几个注意点:
1、内部控件约束要完整,不要缺少约束
2、设置cell的ContentView的约束,主要是底部约束等于最下边的控件的底部。
即:
// _contentLabel是最底部的控件
[_contentLabel mas_makeConstraints:^(MASConstraintMaker *make) {
make.left.equalTo(_icon);
make.top.equalTo(_icon.mas_bottom).offset(10);
make.right.equalTo(self.contentView).offset(-10);
}];
[self.contentView mas_makeConstraints:^(MASConstraintMaker *make) {
make.bottom.equalTo(_contentLabel);
make.top.equalTo(self);
make.left.equalTo(self);
make.right.equalTo(self);
}];
// 然后再设置tableView
// 注意这个预估行高不能为0,且越接近真实行高性能越好
self.estimatedRowHeight = 200;
self.rowHeight = UITableViewAutomaticDimension;
通过上面的设置之后即可实现cell的高度自适应,但是今天我发现这样设置不能自适应了,开始以为是我代码写的有问题,然后把之前的代码翻出来运行了发现之前的可以自适应,那我感觉这个问题应该就出在Masrony这个框架了,看了看版本确实更新了。当前最新版本为1.0.2。
那更新了怎么解决自适应的这个问题呢,后来想了想如果想用contentView来约束Label不行的话那能不能用Label来约束contentView呢。
[_contentLabel mas_makeConstraints:^(MASConstraintMaker *make) {
make.left.equalTo(_icon);
make.top.equalTo(_icon.mas_bottom).offset(10);
make.right.equalTo(self.contentView).offset(-10);
make.bottom.equalTo(self.contentView);//关键代码
}];
// 神奇了,居然可以了
好吧,Masrony默默的更新了内部实现。不过更新后感觉比之前要合理一些。