这算是个老生常谈的话题了，从最早的时候使用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;
Simulator Screen Shot 2017年8月2日 19.40.17.png
通过上面的设置之后即可实现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);//关键代码
}];
// 神奇了，居然可以了
Simulator Screen Shot 2017年8月2日 19.41.16.png
好吧，Masrony默默的更新了内部实现。不过更新后感觉比之前要合理一些。
