剛開始寫UI界面的時候, 經(jīng)驗豐富的iOS程序猿都會推薦用純代碼手寫UI, 并指出Autolayout諸多不足之處: 1)不好維護(hù) 2)產(chǎn)品腦洞大開時, 以前寫的約束很可能要推翻重來 .

其實, 除了這些缺點, 相信大家也越來越多的發(fā)現(xiàn), 其實Autolayout還是很好用的, 好用到根本不想手寫代碼了...

不過, 對于iPhone不同設(shè)備的屏幕適配, 依舊是個棘手的問題...因為每次去面試都會被問到這個問題, "你是如何用autolayout進(jìn)行適配的?"

這里討論一個比較常見的情況.

Example 1: TableViewCell里的兩個label并列

(a) 理想中的UI界面: ?

圖1 ?理想中的UI界面

(b) 實際中的UI界面, 原因: 1) 兩個label的文字寬度偏長 2) 屏幕偏小?

圖2 實際中的UI界面

(c) 增加不等式約束: label1的trailing 與 label2的leading 的水平距離 >= 15;?增加約束后, 默認(rèn)label2 被壓縮, 加省略號...

圖3 增加label間距的不等式約束

(d) 此時若希望label1優(yōu)先被壓縮, 加省略號..?

點擊label1, 在size inspector中, 在添加的各種約束下方, 可以找到Content?Hugging Priority & Content Compression Resistance Priority. 其中, Content Compression Resistance Priority 是"抗壓縮的優(yōu)先級". 默認(rèn)為750. 把優(yōu)先級調(diào)小, 那么就是抗壓縮的等級變小, 容易被壓縮. 反之, 優(yōu)先級高, 不容易被壓縮. 因此, 調(diào)小label1的"抗壓縮的優(yōu)先級",設(shè)為749; label2的不變, 仍為750. ?

圖4 調(diào)小label1的抗壓縮優(yōu)先級

最后, 得到我們想要的UI界面:?

圖5 label1優(yōu)先被壓縮

(e) 接著,考慮一種極端情況, 如果label2的文字特別特別長, 可能就把label1擠沒了... 這并不是我們想要的結(jié)果. 雖然label1優(yōu)先壓縮, 但完全被壓縮,或者被壓縮的太小, 都不是我們想要看到的.

圖6 label2的文字特別長, label1會被擠掉

可以給label1再增加一個寬度Width的約束, 設(shè)置最小寬度minWidth

圖7 設(shè)置label1的最小寬度

得到我們想要的UI界面:

圖8 label1 優(yōu)先壓縮且有最小寬度

(f) 這時處女座不樂意了, minWidth怎么可以是固定值呢? 說好的要屏幕適配, minWidth也要跟著屏幕寬度變化! OK, 這個時候要用上Equal Widths來建立label1與superView的關(guān)系.

圖9 label1與superView的關(guān)系, 選擇Equal Widths

點擊Equal Widths, 并在size inspector中找到該約束, 雙擊, 出現(xiàn)下面界面:

圖10 label1的EqualWidths約束

可以看到, First Item是label.width, Second Item是Cell.width. 將Multiplier改為0.3, Relation改為Greater than or equal. 所以, 此時label1與superView的倍數(shù)關(guān)系式為 label.width >= 0.3*Cell.width. 成功實現(xiàn)了最小寬度隨著屏幕寬度變化的要求.

下節(jié)我們會聊聊不等式約束和妙用優(yōu)先級.

(版權(quán)歸作者所有, 未經(jīng)允許, 禁止轉(zhuǎn)載, 違者必究)

經(jīng)作者授權(quán), 這篇文章也發(fā)表在 swiftcn.io/topics/32 , Swift中國是個很不錯的社區(qū).