Xcode之Autolayout -- "Content Hugging"和"Content Compression Resistance"
原文取自Z哥http://www.jianshu.com/p/a4b8e0c8e68d
在使用storyboard和Xib进行UI布局的时候,会经常碰到
"Content Hugging"
和"Content Compression Resistance"
这两个属性
下面给大家简单介绍下这两个小家伙:
首先,我们得先来了解下另一个属性intrinsic size(固有尺寸),一个根据自身内容大小而决定的尺寸。我们都知道,UIButton、UILabel等,在布局时并不需要给它们设置所有constraints,只需要设置 leading space 和 top space 等能决定 X 跟 Y 的constraints 就能够进行布局,这就是它们的intrinsic size在起作用,决定它们的宽高。
那么,“Content Compression Resistance Priority”和“Content Hugging Priority”这两个小家伙跟intrinsic size有什么渊源?
在开发中,我们难免会同时对两个UILabel或者UIButton进行布局,比如水平并行布局,或者垂直并行布局:
我只是简单的为它们添加了决定x和y的constraints,并没有给他们其他设置,按照我们刚才讲的intrinsic size(固有尺寸)两个label应该在除了x和y不同外,宽高保持一致。但是,正如你我所见,在storyboard上,两个label宽高并不一样。水平并行的label宽度不同,垂直并行的label高度不同。可见,intrinsic size(固有尺寸)在同时对多个label进行布局时并不显得那么够!
产生这样的效果的原因是:
在水平并行布局中,两个label的intrinsic size(固有尺寸)加起来比它们的父view(图中绿色的view)还要宽,因此父view没办法完全展示它们,只能通过压缩它们来实现;
而在垂直并行布局中,两个label的intrinsic size(固有尺寸)加起来并没有它们的父view那么高,父view为了展示他们,只能将它们拉伸。
通过上图,我们清楚的看到,系统并不是同时对两个label进行压缩或者拉伸,而是只针对其中一个。这就是intrinsic size(固有尺寸)跟“Content Compression Resistance Priority”和“Content Hugging Priority”这两个小家伙的关系了。
总结
“Content Hugging Priority”,也叫内容紧靠优先级(小名:别扯我),该优先级越高,这越晚轮到被拉伸。
“Content Compression Resistance Priority”,也叫内容压缩阻力优先级(小名:别挤我),该优先级越高,则越晚轮到被压缩。
因此,在父view大小不够布局子label时,我们可以通过增加某个label的Content Compression Resistance Priority(内容压缩阻力优先级)来防止被压缩。当然降低自身则可以让自己被压缩。
同理,在父view大小太大时,我们可以通过增加label的Content Hugging Priority(内容紧靠优先级)来防止被拉伸。降低则可以达到被拉伸的目的。
欢迎大家拍砖交流