剛開始寫UI界面的時(shí)候, 經(jīng)驗(yàn)豐富的iOS程序猿都會(huì)推薦用純代碼手寫UI, 并指出Autolayout諸多不足之處: 1)不好維護(hù) 2)產(chǎn)品腦洞大開時(shí), 以前寫的約束很可能要推翻重來 .
其實(shí), 除了這些缺點(diǎn), 相信大家也越來越多的發(fā)現(xiàn), 其實(shí)Autolayout還是很好用的, 好用到根本不想手寫代碼了...
不過, 對(duì)于iPhone不同設(shè)備的屏幕適配, 依舊是個(gè)棘手的問題...因?yàn)槊看稳ッ嬖嚩紩?huì)被問到這個(gè)問題, "你是如何用autolayout進(jìn)行適配的?"
這里討論一個(gè)比較常見的情況.
Example 1: TableViewCell里的兩個(gè)label并列
(a) 理想中的UI界面: ?
(b) 實(shí)際中的UI界面, 原因: 1) 兩個(gè)label的文字寬度偏長 2) 屏幕偏小?
(c) 增加不等式約束: label1的trailing 與 label2的leading 的水平距離 >= 15;?增加約束后, 默認(rèn)label2 被壓縮, 加省略號(hào)...
(d) 此時(shí)若希望label1優(yōu)先被壓縮, 加省略號(hào)..?
點(diǎn)擊label1, 在size inspector中, 在添加的各種約束下方, 可以找到Content?Hugging Priority & Content Compression Resistance Priority. 其中, Content Compression Resistance Priority 是"抗壓縮的優(yōu)先級(jí)". 默認(rèn)為750. 把優(yōu)先級(jí)調(diào)小, 那么就是抗壓縮的等級(jí)變小, 容易被壓縮. 反之, 優(yōu)先級(jí)高, 不容易被壓縮. 因此, 調(diào)小label1的"抗壓縮的優(yōu)先級(jí)",設(shè)為749; label2的不變, 仍為750. ?
最后, 得到我們想要的UI界面:?
(e) 接著,考慮一種極端情況, 如果label2的文字特別特別長, 可能就把label1擠沒了... 這并不是我們想要的結(jié)果. 雖然label1優(yōu)先壓縮, 但完全被壓縮,或者被壓縮的太小, 都不是我們想要看到的.
可以給label1再增加一個(gè)寬度Width的約束, 設(shè)置最小寬度minWidth
得到我們想要的UI界面:
(f) 這時(shí)處女座不樂意了, minWidth怎么可以是固定值呢? 說好的要屏幕適配, minWidth也要跟著屏幕寬度變化! OK, 這個(gè)時(shí)候要用上Equal Widths來建立label1與superView的關(guān)系.
點(diǎn)擊Equal Widths, 并在size inspector中找到該約束, 雙擊, 出現(xiàn)下面界面:
可以看到, First Item是label.width, Second Item是Cell.width. 將Multiplier改為0.3, Relation改為Greater than or equal. 所以, 此時(shí)label1與superView的倍數(shù)關(guān)系式為 label.width >= 0.3*Cell.width. 成功實(shí)現(xiàn)了最小寬度隨著屏幕寬度變化的要求.
下節(jié)我們會(huì)聊聊不等式約束和妙用優(yōu)先級(jí).
(版權(quán)歸作者所有, 未經(jīng)允許, 禁止轉(zhuǎn)載, 違者必究)
經(jīng)作者授權(quán), 這篇文章也發(fā)表在 swiftcn.io/topics/32 , Swift中國是個(gè)很不錯(cuò)的社區(qū).
