在開發中有的時候回遇到一些比較操蛋的資料長度不定，但是需要用多個lable在同一行顯示的問題，有的內容必須要顯示全，有些則在到達一定長度之後剩餘內容允許以...的形式省略顯示。針對這樣的問題需要藉助Autolayout來完成。為了便利操作可以採用Masonry來進行約束操作。

Content Hugging 和 Content Compression Resistance

這兩個屬性對有intrinsic content size的控制元件（例如button，label）非常重要。通俗的講，具有intrinsic content size的控制元件自己知道（可以計算）自己的大小，例如一個label，當你設定text，font之後，其大小是可以計算到的。關於intrinsic content size官方的解釋：

Custom views typically have content that they display of which the layout system is unaware. Overriding this method allows a custom view to communicate to the layout system what size it would like to be based on its content. This intrinsic size must be independent of the content frame, because there’s no way to dynamically communicate a changed width to the layout system based on a changed height, for example.

好了，瞭解了intrinsic content size的概念之後，下面就重點討論Content Hugging 和 Content Compression Resistance了。

UIView中關於Content Hugging 和 Content Compression Resistance的方法有：

- (void)setContentCompressionResistancePriority:(UILayoutPriority)priority forAxis:(UILayoutConstraintAxis)axis

- (void)setContentHuggingPriority:(

大概的意思就是設定優先順序的。

Hugging priority 確定view有多大的優先順序阻止自己變大。

Compression Resistance priority確定有多大的優先順序阻止自己變小。

 並排兩個label，寬度由內容決定。父級View寬度不夠時，優先顯示左邊label的內容

遇到這種跟內容壓縮、優先順序有關的佈局，就不得不提Autolayout中的兩個重要的屬性“Content Compression Resistance”和“Content Hugging”。

Content Compression Resistance = 不許擠我！

對，這個屬性說白了就是“不許擠我”=。=

這個屬性的優先順序（Priority）越高，越不“容易”被壓縮。也就是說，當整體的空間裝不小所有的View的時候，Content Compression Resistance優先順序越高的，現實的內容越完整。

Content Hugging = 抱緊！

這個屬性的優先順序越高，整個View就要越“抱緊”View裡面的內容。也就是View的大小不會隨著父級View的擴大而擴大。

分析

根據要求，可以將約束分為兩個部分：

1. 整體空間足夠時，兩個label的寬度由內容決定，也就是說，label的“Content Hugging”優先順序很高，而且沒有固定的Width屬性。

2. 整體空間不夠時，左邊的label更不容易被壓縮，也就是“Content Compression Resistance”優先順序更高。

重點：

1. label不設定具體的寬度（width）屬性，寬度由內容決定。

2. 顯示的優先順序由“Content Compression Resistance”屬性的高低決定。

約束示例圖

關鍵程式碼

關鍵的程式碼如下：（label1是左邊的label，label2是右邊的）

設定位置

設定內容約束