之前只有比较浅的接触过Masonry。项目中大多数的布局还是用xib中的AutoLayout与手码的frame计算相结合,相信也会有很多项目和我一样是这两种布局的组合。其实xib各方面用的感觉都挺好,以前是性能问题,冲突问题饱受人诟病,但随着苹果的更新换代这些问题也逐渐趋向最小化。 我们团队整改的主要原因是为了更细粒度的组件化。因为将一块代码复用到另一个页面远比从xib中拖几个控件到别的页面来的要快,并且使用Masonry写出来的代码在控件间关系上非常清晰便于理解。
普通的布局就略过不说了,这里搭建一些较为特殊的布局。
如果你不是在董铂然博客园看到本文请点击查看原文。
上面的右图是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); }];
注:对于这种几个模块功能相似位置相近的,建议多包一层父控件,便于整个组件的操作与抽离,并且可以从宏观的角度看项目结构更加清晰。
简单的描述就是,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); }];
这种约束一般适用于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); }];
和原生的约束一样,设置向量系数(比例)之后也可以再设置一个偏移量。
当前的自动布局第三方库有多种,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但是设置方法不同,所以会会新旧都保留导致冲突报错。
如果你不是在董铂然博客园看到本文请点击查看原文。
有的时候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的区别。
未经授权不得转载
新闻热点
疑难解答