IOS开发之Autolayout——“Content Compression Resistance”和“Content Hugging”

在使用storyboard进行UI布局时，我们经常不经意间会注意到“Content Compression Resistance Priority”和“Content Hugging Priority”这两个属性。

下面给大家简单介绍下这两个小家伙：

首先，我们得先来了解下另一个属性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进行布局时并不显得那么够！

产生这样的效果的原因是：

1. 在水平并行布局中，两个label的intrinsic size（固有尺寸）加起来比它们的父view（图中蓝色的view）还要宽，因此父view没办法完全展示它们，只能通过压缩它们来实现；

2. 而在垂直并行布局中，两个label的intrinsic size（固有尺寸）加起来并没有它们的父view那么高，父view为了展示他们，只能将它们拉伸。

通过上图，我们清楚的看到，系统并不是同时对两个label进行压缩或者拉伸，而是只针对其中一个。这就是intrinsic size（固有尺寸）跟“Content Compression Resistance Priority”和“Content Hugging Priority”这两个小家伙的关系了。

“Content Compression Resistance Priority”，也叫内容压缩阻力优先级（小名：别挤我），该优先级越高，则越晚轮到被压缩。

“Content Hugging Priority”，也叫内容紧靠优先级（小名：别扯我），该优先级越高，这越晚轮到被拉伸。

因此，在父view大小不够布局子label时，我们可以通过增加某个label的Content Compression Resistance Priority（内容压缩阻力优先级）来防止被压缩。当然降低自身则可以让自己被压缩。

同理，在父view大小太大时，我们可以通过增加label的Content Hugging Priority（内容紧靠优先级）来防止被拉伸。降低则可以达到被拉伸的目的。

欢迎大家拍砖交流