引言
xib是大多數(shù)iOS開發(fā)者常用且喜歡用的開發(fā)方式, 尤其是將xib用在TableViewCell上. 但是使用xib時(shí)經(jīng)常會遇到一種情況, 下面將通過一則故事來分析這種情況.
一個被產(chǎn)品經(jīng)理虐的故事
-
有一天產(chǎn)品經(jīng)理讓你做個列表視圖(UITableViewController), 其中每個單元格都一模一樣, 只需要兩個Label放在一左一右且垂直居中, 而且它倆文字內(nèi)容都是固定的. 于是你創(chuàng)建了一個cell, 并添加約束如圖1和圖2所示:
圖1
圖2
- 第二天產(chǎn)品經(jīng)理走過來跟你說, 左邊的label的文字要做成動態(tài)的, 也就是長度是不固定的, 你默默點(diǎn)頭, 又添加了新的約束如圖3和圖4所示:
圖3
圖4
- 乍一看好像沒什么問題, 最多就是左邊的文字偶爾太長, 導(dǎo)致顯示不全而已. 然而第三天產(chǎn)品經(jīng)理走過來對你笑了笑, 說右邊的Label也要做成動態(tài)文字, 長度也不固定, 而且一定要全部顯示出來. 于是, 你只能默默地把限制右邊Label寬度的約束刪除了, 接下來再跑一次程序, 卻發(fā)現(xiàn)這樣??
圖5
什么東西!!! 為啥右邊的文字沒了
- 這里就遇到一個兩難的問題, 右邊文字是動態(tài)的, 而且一定要全部顯示出來, 那么就不能限制其寬度, 但不限制它的寬度, 如果左邊文字太長, 又會把右邊Label的空間給"吃掉". 怎么辦? 這時(shí)我們今天的主角就上場了.
圖6
- Content Compression Resistance Priority, 也稱內(nèi)容抗壓縮優(yōu)先級(默認(rèn)優(yōu)先級都為750).
- 按字面意思理解, 就是Label的文字"不被壓縮的優(yōu)先級", 優(yōu)先級越高, 就越不可能被壓縮. 這個參數(shù)分為水平(Horizontal)和垂直(Vertical).
- 在今天的情形中, 我們只需要動用水平參數(shù), 把右邊Label的這個參數(shù)對應(yīng)的水平750改成751, 即比左邊Label的對應(yīng)值(750)大一級, 而不被左邊Label壓榨就OK了, 此時(shí)我們再跑一下程序, 結(jié)果如下??
圖7
順利完成產(chǎn)品經(jīng)理交代的任務(wù)???????????? 心情如下
