使用Masonry搭建特殊布局时与xib的对比

之前只有比较浅的接触过Masonry。项目中大多数的布局还是用xib中的AutoLayout与手码的frame计算相结合，相信也会有很多项目和我一样是这两种布局的组合。其实xib各方面用的感觉都挺好，以前是性能问题，冲突问题饱受人诟病，但随着苹果的更新换代这些问题也逐渐趋向最小化。 我们团队整改的主要原因是为了更细粒度的组件化。因为将一块代码复用到另一个页面远比从xib中拖几个控件到别的页面来的要快，并且使用Masonry写出来的代码在控件间关系上非常清晰便于理解。

普通的布局就略过不说了，这里搭建一些较为特殊的布局。

如果你不是在董铂然博客园看到本文请点击查看原文。

1.下方有三个UIView或UIButton，要随时随着屏幕宽度的变化（横屏竖屏）始终保持等宽等高。

 

上面的右图是xib下搭建，使用常规的Masonry语法完成布局的代码是这样的

    [redView mas_makeConstraints:^(MASConstraintMaker *make) {
        make.left.equalTo(self.view.mas_left).with.offset(0);
        make.bottom.equalTo(self.view.mas_bottom).with.offset(0);
        make.height.equalTo(@100);
    }];
    
    [blueView mas_makeConstraints:^(MASConstraintMaker *make) {
        make.left.equalTo(redView.mas_right).with.offset(0);
        make.bottom.equalTo(self.view.mas_bottom).with.offset(0);
        make.width.equalTo(redView.mas_width).with.offset(0);
        make.height.equalTo(redView.mas_height).with.offset(0);
    }];
    
    [greenView mas_makeConstraints:^(MASConstraintMaker *make) {
        make.left.equalTo(blueView.mas_right).with.offset(0);
        make.bottom.equalTo(self.view.mas_bottom).with.offset(0);
        make.right.equalTo(self.view.mas_right).with.offset(0);
        make.width.equalTo(blueView.mas_width).with.offset(0);
        make.height.equalTo(blueView.mas_height).with.offset(0);
    }];

代码中可以看到具体的逻辑还是特别清晰的。可以清楚地了解各个控件间的关系，基本上每一行代表着xib中的一根约束。

并且Masonry支持了一些省略和简写：

如果是两个控件的同一个位置（约束）之间的联系，括号中可以只写以来的控件约束可以省略；

如果约束依赖的是同一个控件，那可以用and将两个约束连在一行写；

如果偏移量offset是0，后面的with.offset(0)可以省略；

将上面的代码最简可以写成如下

    [redView mas_makeConstraints:^(MASConstraintMaker *make) {
        make.left.and.bottom.equalTo(self.view);
        make.height.equalTo(@100);
    }];
    
    [blueView mas_makeConstraints:^(MASConstraintMaker *make) {
        make.bottom.and.width.and.height.equalTo(redView);
        make.left.equalTo(redView.mas_right);
    }];
    
    [greenView mas_makeConstraints:^(MASConstraintMaker *make) {
        make.bottom.and.width.and.height.equalTo(blueView);
        make.right.equalTo(self.view);
        make.left.equalTo(blueView.mas_right);
    }];

注：对于这种几个模块功能相似位置相近的，建议多包一层父控件，便于整个组件的操作与抽离，并且可以从宏观的角度看项目结构更加清晰。 

2.实现相互依赖的自动布局，背景View的高度由自己子控件的Label能拉多长决定。

简单的描述就是，label的左边和顶部是依赖父控件grayView的。但是父控件grayView的底部是依赖子控件Label的。

上面右图是IB页面搭建的AutoLayout，但是按照xib的搭建的思路写出的代码是有问题的。

    [grayView mas_makeConstraints:^(MASConstraintMaker *make) {
        make.left.and.top.equalTo(self.view).with.offset(50);
        make.width.equalTo(@200);
        make.bottom.equalTo(contentLbl).with.offset(10);
    }];
    
    [contentLbl mas_makeConstraints:^(MASConstraintMaker *make) {
        make.left.and.top.equalTo(grayView).with.offset(10);
        make.right.equalTo(grayView).with.offset(-10);
    }];

 上面的代码会导致崩溃，原因就是上面的第4行依赖的contentLbl的约束还没有搭建所以导致崩溃。在xib中会出现红色箭头的情况，就是约束错误，在将约束调整正确后红色箭头会变成黄色箭头，就是约束正确。 但是使用Masonry与xib不同，xib出现错误可以容忍你改正，Masonry只要出现错误就会马上崩溃。 因此对于这种相互依赖的约束，下面的还没建立就要约束他看似无法完成，实际的解决方案就是用子控件反过来依赖他也是可以的。 也就是说，你想让父控件依赖子控件比他多10像素，和设置子控件依赖父控件比他少10像素是一个等价的概念，可以相互转化。如果你是细心的网友，你会发现在xib中你虽然设置的是父控件依赖子控件，但实际的约束还是放在子控件里的。

修改后的代码如下：

    [grayView mas_makeConstraints:^(MASConstraintMaker *make) {
        make.left.and.top.equalTo(self.view).with.offset(50);
        make.width.equalTo(@200);
    }];
    
    [contentLbl mas_makeConstraints:^(MASConstraintMaker *make) {
        make.left.and.top.equalTo(grayView).with.offset(10);
        make.right.equalTo(grayView).with.offset(-10);
        make.bottom.equalTo(grayView).with.offset(-10);
    }];

3.设置百分比的约束，即一个约束是另一个约束百分之多少。

这种约束一般适用于width和height。 对于屏幕的适配很有用，等于把以前算frame的思想加到了autoLayout里。

    [grayView mas_makeConstraints:^(MASConstraintMaker *make) {
        make.left.and.top.equalTo(self.view).with.offset(50);
//        make.width.equalTo(@200);
        make.width.equalTo(self.view).multipliedBy(0.5).offset(0);
    }];
    
    [contentLbl mas_makeConstraints:^(MASConstraintMaker *make) {
        make.left.and.top.equalTo(grayView).with.offset(10);
        make.right.equalTo(grayView).with.offset(-10);
        make.bottom.equalTo(grayView).with.offset(-10);
    }];

和原生的约束一样，设置向量系数（比例）之后也可以再设置一个偏移量。

4.设置约束的更新

当前的自动布局第三方库有多种，Masonry相比来说也算是重量级的了。Masonry相比其他自动布局的库最大的优点是在于约束的更新做的很好。

假设现在的约束是上面第2条时的约束，现在设置按钮点击更新约束代码如下

- (IBAction)btnclick:(id)sender {
    [self.grayView mas_updateConstraints:^(MASConstraintMaker *make) {
        make.width.equalTo(@300);
    }];

    [UIView animateWithDuration:3.0 animations:^{
        [self.grayView layoutIfNeeded];
    }];
}

如果给约束的变化设置约束，需要用UIView动画的block将 layoutIfNeed包裹住。而不是直接将约束更新包裹住。

更新约束要注意mas_updateConstraints 和 mas_remakeConstraints 有本质区别。 前者update是保留之前的约束再添加你本次新增的约束。如果出现了相同的设置约束的方法，仅仅是值不同，则会直接替换掉原来的约束。  后者remake是直接把原来的全部干掉，然后添加本次设置的约束。

所以update要注意的是不要用新的方法添加了约束会与之前的约束相冲突。而remake需要注意的是你在remake里面写的约束必须是一个完整的约束，因为之前的约束全清空了。

如果没有完全弄清两个方法的区别则可能会写出以下代码，这是错误的

- (IBAction)btnclick:(id)sender {
    [self.grayView mas_updateConstraints:^(MASConstraintMaker *make) {
        make.left.and.top.equalTo(self.view).with.offset(10);
        make.width.equalTo(self.view).multipliedBy(0.5);
    }];
    
    [UIView animateWithDuration:3.0 animations:^{
        [self.grayView layoutIfNeeded];
    }];
}

因为原来的make.width.equalTo(@200); 和本次的 make.width.equalTo(self.view).multipliedBy(0.5); 虽然都是设置width但是设置方法不同，所以会会新旧都保留导致冲突报错。

如果你不是在董铂然博客园看到本文请点击查看原文。

5.设置优先级和Label抗压缩

有的时候Label的宽度或是内部字体发生变化的时候，可能会出现XX... 这种情况，这是因为Label被压缩了。Masonry有抗压缩的设置，并且这个设置和Masonry的优先级priority息息相关。iOS9字体的变化导致很多Label出现... ，如果当初使用Masonry来设置布局并且设置了抗压缩，那应该就可以完全避免此问题。

设置一个View，里面有一个子控件Label。

    [blackView mas_makeConstraints:^(MASConstraintMaker *make) {
        make.left.equalTo(self.view).with.offset(50);
        make.top.equalTo(self.view).with.offset(300);
        make.size.mas_equalTo(CGSizeMake(200, 50));
    }];
    
    [contentLbl2 mas_makeConstraints:^(MASConstraintMaker *make) {
        make.left.and.top.equalTo(blackView).with.offset(10);
        make.right.equalTo(blackView).with.offset(-50);
        make.height.equalTo(@30);
    }];

上面的第一块代码就是搭建一个普通的父控件，可以无视。下面一块是Label的约束

如果这么设置，右边要比父控件少50，所以Label的文字显示不下，会被积压。

但是如果加入一个约束：“width最少也大于200”，并且给这个约束设置优先级比 “右边要比父控件少50” 的优先级高，代码如下

    [contentLbl2 mas_makeConstraints:^(MASConstraintMaker *make) {
        make.left.and.top.equalTo(blackView).with.offset(10);
        make.width.greaterThanOrEqualTo(@200).priority(900);
        make.right.equalTo(blackView).with.offset(-50).priority(800);
        make.height.equalTo(@30);
    }];

第3行的优先级大于第4行的优先级 所以执行第3行，Label并没有被挤压。

抗压缩还有另一种设置方法 

    [contentLbl2 mas_makeConstraints:^(MASConstraintMaker *make) {
        make.left.and.top.equalTo(blackView).with.offset(10);
        make.right.equalTo(blackView).with.offset(-50).priority(990);
        make.height.equalTo(@30);
    }];
    
    [contentLbl2 setContentCompressionResistancePriority:UILayoutPriorityRequired forAxis:UILayoutConstraintAxisHorizontal];

设置“右边要比父控件少50” 的优先级为1000以下， 然后在下面再写上一行水平方向抗压缩的代码。 这里要注意上面的“右边比父控件少50”优先级不能不写，因为Masonry这种类型的代码默认优先级都是1000，而下面UILayoutPriorityRequired的优先级也是1000，那么下面的代码就不起效果了。

其实还有更简单的设置方法，不用写水平方向抗压缩，只需要将上面约束后面的优先级改到750以下

    [contentLbl2 mas_makeConstraints:^(MASConstraintMaker *make) {
        make.left.and.top.equalTo(blackView).with.offset(10);
        make.right.equalTo(blackView).with.offset(-50).priority(749);
        make.height.equalTo(@30);
    }];

因为优先级750对应的优先级枚举是UILayoutPriorityDefaultHigh，可以理解成Masonry本身就有一种抗压缩的保护，优先级是750。

    [contentLbl2 setContentCompressionResistancePriority:UILayoutPriorityDefaultHigh forAxis:UILayoutConstraintAxisHorizontal];

这行代码应该是所有label默认存在的。

所以以后如果想让Label抗压缩，直接把优先级设置到750以下就OK了。

　

总结：

1.Masonry的方法并不多，链式方法，每一个点语法都是返回一个约束对象，一个个特定的约束是这个对象的属性。

2.Masonry不同于xib搭建约束出现红色还能调整，前者一出现问题直接崩溃，将问题卡在开发阶段。

3.Masonry建立约束前必须将父子关系搭建好，并且不能对还没有设置约束的控件添加依赖。

4.更新约束要弄清remake和update的区别。

未经授权不得转载