1. 约束的底层原理先搞懂它在做什么再动手很多刚接触iOS开发的同学会把AutoLayout当成“用代码把视图钉在某个位置”的工具这种理解其实害人不浅。你在这种认知下写的约束往往会在屏幕尺寸变化、字体大小变化、多语言文本变长时突然崩给你看。AutoLayout约束不是定位工具而是一套描述视图之间关系的数学方程系统它解决的问题不是“在哪里”而是“怎么相对地存在”。这就像装修房子时你不会说“沙发放在离墙300像素的位置”而会说“沙发贴靠墙和茶几之间留出40公分过道”。一旦房间尺寸变化相对关系依然成立。AutoLayout要的就是这种“电视墙、沙发、茶几之间相互制约”的稳定关系而不是绝对坐标。1.1 约束的本质一条可被求解的线性方程任何一条约束在系统内部都会被转换成一条形如item1.attribute1 multiplier × item2.attribute2 constant的方程。举个例子你经常写label.leadingAnchor.constraint(equalTo: view.leadingAnchor, constant: 16)翻译成人话就是label的左边缘 view的左边缘 × 1.0 16。这个16就是constantmultiplier是1.0。如果设置multiplier为0.5那就是“label的左边缘位于view左边缘到右边缘的一半位置”。理解这个方程模型非常关键因为它解释了约束的几个特点约束是双向的。A B 16等价于B A - 16系统不在乎谁是“参照物”只要求最终所有方程能同时成立。约束可以是不等式。、对应系统里的UILayoutPriority处理常见于“宽度至少100”这类需求。一个视图需要足够多的、不冲突的方程才能确定完整布局。缺失方程的结果就是“模糊布局”系统得靠猜测来决定视图位置方程互相矛盾的结果是“约束冲突”系统会丢弃某个约束来强行求解。1.2 优先级当方程不能同时成立时谁说了算大部分新手不知道每条约束都有优先级默认为.required优先级1000。当两条required约束冲突时系统绝不会告诉你“无解”而是直接打破其中一条然后在控制台输出一堆紫色警告。注意是“打破”不是“协商”。required约束是不能谈判的它必须被满足如果满足不了系统就剁掉其中一条来维持其余条目的运行。所以真正的协商机制是优先级。你把某条约束的priority设置成.defaultHigh750或.defaultLow250系统在求解时才可能先满足高优先级的约束在必要时牺牲低优先级的约束。这个设计在自适应布局里非常有用比如你希望label能完整显示但如果空间不够可以压缩一点就可以把“宽度等于内容宽度”设为高优先级而不是required。这里给你的第一个经验不要一遇到约束冲突就把所有priority改成required而要想清楚“哪个约束是底线、哪个约束可以妥协”。真正的底线用required可妥协的用低优先级这样系统才会按你的意图取舍。2. 代码创建约束的主流姿势以及我为什么推荐这种在代码里加约束有几种常用API很多旧教程还在讲NSLayoutConstraint的初始化方法也有不少项目为了兼容旧代码在用可视化格式语言VFL。我的建议很直接新写代码请一律使用Anchor API除非你是在维护老项目。2.1 NSLayoutConstraint 的显式初始化古典派NSLayoutConstraint( item: label, attribute: .leading, relatedBy: .equal, toItem: view, attribute: .leading, multiplier: 1.0, constant: 16 ).isActive true这个API冗长、参数多而且很容易把attribute搞混。它的唯一优势是可以在一个方法里设置multiplier不是1的约束而Anchor API里除了width/height相关的锚点可以设置multiplier其他锚点的multiplier通常就是1。因此如果你需要给宽高设置比例比如宽度是高度的一半显式初始化反而是更清晰的选择。但除此之外它没有任何优势。不要用它写普通约束。2.2 Anchor API日常项目的最优解从iOS 9开始系统为NSLayoutAnchor设计了一组简洁的API我最常用的几个label.translatesAutoresizingMaskIntoConstraints false NSLayoutConstraint.activate([ label.topAnchor.constraint(equalTo: view.safeAreaLayoutGuide.topAnchor, constant: 12), label.leadingAnchor.constraint(equalTo: view.leadingAnchor, constant: 16), label.trailingAnchor.constraint(lessThanOrEqualTo: view.trailingAnchor, constant: -16), label.bottomAnchor.constraint(equalTo: view.bottomAnchor, constant: -12) ])NSLayoutConstraint.activate批量激活是关键它比一个一个设置isActive true性能更好因为系统可以一次批量求解。这里有一个几乎所有新手都会踩的坑必须设置translatesAutoresizingMaskIntoConstraints false。只要你在代码里为某个视图添加约束就必须关掉autoresizing转换否则系统会自动为这个视图生成一堆和autoresizing mask对应的隐式约束和你自己的约束打架日志里会出现“Unable to simultaneously satisfy constraints”。小技巧你可以在UIView的分类里写一个prepareForAutolayout()方法返回设置了translatesAutoresizingMaskIntoConstraints false的自己然后用.prepareForAutolayout()链式调用减少重复代码。2.3 可视化格式语言VFL退居幕后的老将let views [label: label, button: button] let hFormat H:|-16-[label]-8-[button(40)]-16-| let vFormat V:|-50-[label(30)] NSLayoutConstraint.activate( NSLayoutConstraint.constraints(withVisualFormat: hFormat, options: [], metrics: nil, views: views) NSLayoutConstraint.constraints(withVisualFormat: vFormat, options: [], metrics: nil, views: views) )VFL用一个字符串同时描述多个视图的关系简洁是它最大的优点。但它有两个致命缺陷一是不容易调试字符串出了错定位难二是它只能描述线性关系处理不了一些复杂条件比如某个视图的宽度依赖另一个视图的宽度比例就需要和别的方式混合使用。现在你用VFL的频率应该很低了但读老代码时不能看不懂它。2.4 Storyboard/XIB 拖线约束和代码约束的取舍IBInterface Builder建约束最直观还能实时预览不同屏幕尺寸下的布局效果。但它的缺点藏在后期维护里约束一多界面会变成一张密密麻麻的蜘蛛网两个人同时改Storyboard合并冲突能改到怀疑人生。我们团队在项目中期定过一个规矩公共控件库全部代码建约束页面级布局可以使用IB但所有人必须review约束是否冗余。如果你选择IB建议把必要的约束拖成IBOutlet但不要在代码里频繁修改constant也不要为了适配某些条件删除再重建约束很容易在运行时报“删除使用中的约束”崩溃。我见过太多这样的崩溃日志Terminating app due to uncaught exception NSInvalidArgumentException, reason: NSLayoutConstraint for ... was deleted这是IB约束最经典的问题代码removeConstraint之后这个约束对象已经被释放但某些内部机制还引用着。最安全的做法不删除改priority或用isActive控制开关。3. 约束冲突、优先级更新以及动画里的一半崩溃来源在实际项目里纯静态界面很少出问题麻烦几乎都集中在动态场景键盘弹出、横竖屏切换、列表复用、文本长度变化。这些场景下约束会被反复更新稍有不慎就会触发系统的一整套“容错流程”。3.1 系统遇到约束冲突后到底做了什么当系统发现若干条约束无法同时满足它会先看待违反的约束里哪些优先级低先尝试丢弃低优先级的。如果冲突的全部是required约束它才会强制丢弃其中一条并在控制台打印出紫色警告Unable to simultaneously satisfy constraints。注意这个过程是运行时自动进行的你的App不会立刻崩溃。但被丢弃的约束意味着你的布局实际表现和你的代码意图不一致你看到的是一个歪了的按钮或是一块被压缩到变形的文本。处理冲突的排查链路很有价值我建议你这样走先看控制台紫色警告找到Will attempt to recover by breaking constraint这一行那行里列出的约束就是被系统丢弃的。把警告里涉及的所有视图的地址类似UILabel: 0x7f...抄下来因为多数情况下你要定位的是视图之间的关系。在view.debugDescription或直接使用po view打印视图树看这些视图当前的实际frame。根据frame和你的意图反推是哪条约束在打架。比如一个width约束想要100另一个leading/trailing约束想要把它拉伸到200两者冲突。3.2 用updateConstraints还是layoutIfNeeded关键区别约束动画是另一个事故高发区。最常见的正确做法是在动画block里改constraint.constant然后UIView.animate(withDuration: 0.3) { self.heightConstraint.constant 200 self.view.layoutIfNeeded() }这里必须理解layoutIfNeeded和setNeedsLayout的区别。setNeedsLayout只是告诉系统“布局需要更新”系统在下一个runloop才会真正重排而layoutIfNeeded是“立即重新布局”。动画block里如果你写的是setNeedsLayout很可能动画还没开始布局已经瞬间跳到目标状态动画就没用了。另一个容易踩的坑是你想改变约束关系本身比如把一个视图从“右边距16”改成“左边距16”。很多人会重新创建一个约束替换旧的但更推荐的做法是用两个约束配合开关// 在初始化或viewDidLoad里创建 leadingToSuperview view.leadingAnchor.constraint(equalTo: view.leadingAnchor, constant: 16) trailingToSuperview view.trailingAnchor.constraint(equalTo: view.trailingAnchor, constant: -16) // 切换时 leadingToSuperview.isActive true trailingToSuperview.isActive false通过isActive开关约束比removeConstraint/addConstraint更安全性能也更好因为不必销毁对象。3.3 自绘约束更新逻辑updateConstraints的正确用法系统在布局之前会调用updateConstraints如果你在这个方法里添加约束需要注意不要在里面做耗时操作不要重复添加同一效果的约束。正确做法是先在初始化或viewDidLoad里创建好约束并保存引用在需要更新时只修改constant或切换isActive然后调setNeedsUpdateConstraints。override func updateConstraints() { // 不要在 override 里频繁 addConstraint下面这种写法是错误的示范 // 每次 setNeedsUpdateConstraints 都 add 一次必出问题 super.updateConstraints() } func refresh() { myConstraint.constant newValue setNeedsUpdateConstraints() }真正需要overrideupdateConstraints的场景通常是约束本身依赖外界状态且创建成本较高。但绝大多数业务场景你只需要直接更新constant不需要碰updateConstraints。4. 调试约束的实用工具与经验不看警告等于把bug留给未来约束问题有个特点它不像crash那样直接导致崩溃只是默默让UI变难看。很多业务方测试的时候发现自己界面错位开发第一反应是“为什么我能复现不了”其实八成是约束在某些机型、某种文本长度下产生了模糊布局或冲突而控制台早就给了警告只是被忽略了。4.1 读懂控制台警告两条线索最有用以下是典型的不满足约束警告Unable to simultaneously satisfy constraints. Probably at least one of the constraints in the following list is one you dont want. Try this: (1) look at each constraint and try to figure out which you dont expect; (2) find the code that added the unwanted constraint or constraints and fix it. ( NSLayoutConstraint:0x600003d1a9a0 UILabel:0x7fb5f3503e10.width 100 (active), NSLayoutConstraint:0x600003d1aa20 UILabel:0x7fb5f3503e10.leading UIView:0x7fb5f3503c20.leading 16 (active), NSLayoutConstraint:0x600003d1aa80 UILabel:0x7fb5f3503e10.trailing UIView:0x7fb5f3503c20.trailing - 16 (active) )第一行是完整约束列表。第二行Will attempt to recover by breaking constraint下面那一条就是被丢弃的。比如上面这个例子label有宽度100同时又有leading和trailing约束在某个固定宽度屏幕上这两个要求可能同时成立也可能不成立。如果父视图宽度小于132那这三条约束就无解系统会丢弃“width 100”这条。4.2 Xcode的View Debugger可视化定位的关键断点到有问题的页面运行后点Xcode的Debug View Hierarchy按钮你可以看到每个视图当前的frame、约束关系和被断掉的约束标记通常是红色或黄色线条。第一次用View Debugger的人往往会迷失在一堆虚线里我建议先在上方过滤栏勾选Constraints再点击某个视图右侧检查器会列出所有约束标注每条的active状态和优先级。如果你怀疑模糊布局View Debugger也会用黄色标识“ambiguous”的视图。这个提示非常重要因为模糊布局的视图不会在控制台报错它只是位置不确定换个屏幕可能就好换个屏幕就偏。4.3 用代码主动找出模糊布局在Debug模式下你可以写一段帮助代码来镜像检查#if DEBUG extension UIView { func hasAmbiguousLayoutRecursively() { if hasAmbiguousLayout { print(Ambiguous:, self) } for subview in subviews { subview.hasAmbiguousLayoutRecursively() } } } #endif然后在viewDidAppear里调用view.hasAmbiguousLayoutRecursively()就能在控制台打出所有布局不明确的视图。这个方法在调试复杂页面时特别好用它能直接让你知道哪几个视图缺约束省去一层层猜的功夫。我自己的经验是约束调试必须早介入。如果新页面在开发阶段就有警告一定不要想着“先这样吧后面再看”。后患无穷。特别是跨机型适配你永远不知道测试会在哪台设备上复现问题。5. 约束的进阶用法与性能心法不只是“能用”而是“用得稳”如果你已经在日常开发中熟练掌握了约束的增删改查接下来这几个话题决定了你能否写出高质量、不拖泥带水的布局代码。5.1 约束数量真的会影响性能吗会但通常情况下你感觉不到。系统对约束的求解用的是Cassowary算法几百条约束在iPhone上也就几毫秒的事。真正该担心的是频繁的布局触发。比如在一个cell里你为了实现圆角、阴影、旋转等效果同时依赖bounds和frame每次bounds变化都触发layout而layout又触发约束求解一层层嵌套就容易卡顿。所以性能优化的核心思路是“减少布局次数”而不是“减少约束条数”。具体做法尽量把不随状态变化的约束设为常量不要每次更新数据时都重新设置。用UIStackView减少部分约束数量它内部帮你把排列关系管理起来但对StackView的约束仍然要注意避免多层嵌套栈。如果某个页面的布局在初始化后永不变化可以把这个页面整体做成drawRect自定义绘制完全避开AutoLayout但这只是极端情况下的优化手段。5.2 UITableViewCell 动态高度约束的经典应用自动计算cell高度的本质就是“让cell内部所有子视图的约束能唯一确定cell.contentView的尺寸”系统通过systemLayoutSizeFitting计算合适高度。常见写法let label UILabel() label.numberOfLines 0 label.translatesAutoresizingMaskIntoConstraints false contentView.addSubview(label) NSLayoutConstraint.activate([ label.topAnchor.constraint(equalTo: contentView.topAnchor, constant: 8), label.leadingAnchor.constraint(equalTo: contentView.leadingAnchor, constant: 16), label.trailingAnchor.constraint(equalTo: contentView.trailingAnchor, constant: -16), label.bottomAnchor.constraint(equalTo: contentView.bottomAnchor, constant: -8) ])这段约束的关键是上下左右全部钉死系统才能从label的内容高度推导出contentView的高度。如果你只写了top和leading系统就不知道cell该多高只会崩溃或计算出0高度。使用约束实现动态高度时有两个容易踩的坑label的preferredMaxLayoutWidth。在iOS 14以前如果label没有正确设置preferredMaxLayoutWidth多行文本计算出的高度可能偏大。在AutoLayout动态高度场景下通常不需要手动设置但如果你发现高度计算不对可以检查这一项。在cell的prepareForReuse里重置约束。当cell复用时如果某种状态改变了label的text约束会自动调整但如果你缓存了一些高度相关变量记得清空。5.3 抗压与抗拉伸你知道Content Hugging和Compression Resistance吗这是很多做了两年iOS开发还说不清的概念。每个视图在有内在内容比如label的文本、image的图片时会被两个优先级影响Content Hugging Priority内容抗拉伸优先级视图“不愿意”被拉伸得比内容大的程度。默认250。Compression Resistance Priority内容抗压缩优先级视图“不愿意”被压缩得比内容小的程度。默认750。举个例子。你有一个label和一个button并排左右都贴着屏幕。屏幕宽度不够时系统需要决定压缩label还是压缩button。谁的内容抗压缩优先级低谁就更容易被压缩。如果你希望label完整显示、button可以截断就把label的抗压缩优先级调高button的调低。label.setContentCompressionResistancePriority(.defaultHigh, for: .horizontal) button.setContentCompressionResistancePriority(.defaultLow, for: .horizontal)这个调整在表格、弹窗等拥挤布局里极其常用。你还可以用setContentHuggingPriority来控制谁更愿意被拉伸比如一个空的UIView要填充剩余空间就把它的Hugging调低这样它才会被拉伸来占满空隙。理解了这两个优先级你对AutoLayout的掌握就上升了一个层次。很多看似奇怪的“内容被截断”“空白过大”问题追溯到最后都是因为默认优先级不合理。最后分享一点个人体会。我看过很多人写约束写得又快又准但从来不看控制台警告直到线上反馈界面错乱才回来排查。其实约束系统相当诚实它把所有问题都写在日志里了只是你愿不愿意读它。我现在的习惯是写完一段新布局就跑一遍真机开Debug View Hierarchy盯一眼再清空控制台看有没有紫色警告。花不了两分钟但能省掉后面调一整天的时间。AutoLayout不难难的是养成“先让系统告诉你问题再动手改”的习惯。
