在使用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（內容緊靠優先順序）來防止被拉伸。降低則可以達到被拉伸的目的。