刚开始写UI界面的时候, 经验丰富的iOS程序猿都会推荐用纯代码手写UI, 并指出Autolayout诸多不足之处: 1)不好维护 2)产品脑洞大开时, 以前写的约束很可能要推翻重来 .
其实, 除了这些缺点, 相信大家也越来越多的发现, 其实Autolayout还是很好用的, 好用到根本不想手写代码了...
不过, 对于iPhone不同设备的屏幕适配, 依旧是个棘手的问题...因为每次去面试都会被问到这个问题, "你是如何用autolayout进行适配的?"
这里讨论一个比较常见的情况.
Example 1: TableViewCell里的两个label并列
(a) 理想中的UI界面:
(b) 实际中的UI界面, 原因: 1) 两个label的文字宽度偏长 2) 屏幕偏小
(c) 增加不等式约束: label1的trailing 与 label2的leading 的水平距离 >= 15; 增加约束后, 默认label2 被压缩, 加省略号...
(d) 此时若希望label1优先被压缩, 加省略号..
点击label1, 在size inspector中, 在添加的各种约束下方, 可以找到Content Hugging Priority & Content Compression Resistance Priority. 其中, Content Compression Resistance Priority 是"抗压缩的优先级". 默认为750. 把优先级调小, 那么就是抗压缩的等级变小, 容易被压缩. 反之, 优先级高, 不容易被压缩. 因此, 调小label1的"抗压缩的优先级",设为749; label2的不变, 仍为750.
最后, 得到我们想要的UI界面:
(e) 接着,考虑一种极端情况, 如果label2的文字特别特别长, 可能就把label1挤没了... 这并不是我们想要的结果. 虽然label1优先压缩, 但完全被压缩,或者被压缩的太小, 都不是我们想要看到的.
可以给label1再增加一个宽度Width的约束, 设置最小宽度minWidth
得到我们想要的UI界面:
(f) 这时处女座不乐意了, minWidth怎么可以是固定值呢? 说好的要屏幕适配, minWidth也要跟着屏幕宽度变化! OK, 这个时候要用上Equal Widths来建立label1与superView的关系.
点击Equal Widths, 并在size inspector中找到该约束, 双击, 出现下面界面:
可以看到, First Item是label.width, Second Item是Cell.width. 将Multiplier改为0.3, Relation改为Greater than or equal. 所以, 此时label1与superView的倍数关系式为 label.width >= 0.3*Cell.width. 成功实现了最小宽度随着屏幕宽度变化的要求.
下节我们会聊聊不等式约束和妙用优先级.
(版权归作者所有, 未经允许, 禁止转载, 违者必究)
经作者授权, 这篇文章也发表在 swiftcn.io/topics/32 , Swift中国是个很不错的社区.
