[TOC=2] 视图层次结构的布局被定义为一系列线性方程式。 每个约束表示一个单一的等式。 你的目标是声明一系列只有一个答案的方程。 示例公式如下所示。  这个约束表明红色视图的前沿必须在蓝色视图的后沿后有8.0个点。 它的等式有很多部分： * Item 1. 等式中的第一项 ，此处指红色视图。 该项目必须是视图或 layout guide 。 * Attribute 1. 属性将被限制在第一项上 - 此处指红色视图的前边。 * Relationship. 左侧和右侧之间的关系。 关系可以具有三个值之一：等于，大于或等于或小于或等于。 此处，左侧和右侧相等。 * Multiplier.属性2的值乘以该浮点数。 此处，乘数是1.0。 * Item 2. 等式中的第二项，此处指蓝色视图。 与第一项不同，这可以留空。 * Attribute 2.要在第二个项目上约束的属性 ，在本例中为蓝色视图的后边缘。 如果第二项留空，则此项必须为非属性。 * Constant. 一个常量，浮点偏移量 - 在这种情况下，8.0。 该值将被添加到属性2的值中。 大多数约束定义了用户界面中两个项目之间的关系。 这些项目可以是视图或 layout guides 。 约束还可以定义单个项目的两个不同属性之间的关系，例如，设置项目高度和宽度之间的宽高比。 也可以为项目的高度或宽度分配常数值。 当使用常量值时，第二项留空，第二项属性设置为非属性，乘数设置为 0.0。 ## 自动布局属性 在自动布局中，这些属性定义了一个可以被约束的特征。 一般来说，这包括四个边（头部，尾部，顶部和底部）以及高度，宽度以及垂直和水平中心。 文本项目还有一个或多个基准属性。  有关完整的属性列表，请参阅 [NSLayoutAttribute](https://developer.apple.com/documentation/appkit/nslayoutattribute) 枚举。 > 注意 > 尽管 OS X 和 iOS 都使用 NSLayoutAttribute 枚举，但它们定义了稍微不同的一组值。 要查看完整的属性列表，请确保正在查看正确的平台文档。 ## 样本方程 这些公式可用的各种参数和属性可以让您创建许多不同类型的约束条件。 可以定义视图之间的空间，对齐视图的边缘，定义两个视图的相对大小，甚至可以定义视图的宽高比。 但是，并非所有属性都是兼容的。 有两种基本类型的属性。 大小属性（例如，高度和宽度）和位置属性（例如Leading，Left和Top）。 大小属性用于指定项目的大小，而不指示其位置。 位置属性用于指定项目相对于其他项目的位置。 但是，它们没有指示物品的大小。 考虑到这些差异，以下规则适用： * 无法将大小属性限制为位置属性。 * 不能将常量值分配给位置属性。 * 不能使用具有位置属性的非唯一性乘数（1.0以外的值）。 * 对于位置属性，不能将垂直属性约束为水平属性。 * 对于位置属性，无法将 Leading 或 Trailing 属性限制为 Left 或 Right 属性。 例如，将项目的 Top 设置为常量值 20.0 在没有附加上下文的情况下没有意义。 必须始终相对于其他项目定义项目的位置属性，例如，在父视图顶部下方 20.0 个点。 但是，将项目的高度设置为 20.0 是完全有效的。 有关更多信息，请参阅 [Interpreting Values](https://developer.apple.com/library/content/documentation/UserExperience/Conceptual/AutolayoutPG/AnatomyofaConstraint.html#//apple_ref/doc/uid/TP40010853-CH9-SW22 )。 清单 3-1 显示了各种常见约束的示例方程。 > 注意 > 本章中的所有示例方程都是使用伪代码呈现的。 要使用实际代码查看实际约束，请参阅[Programmatically Creating Constraints](https://developer.apple.com/library/content/documentation/UserExperience/Conceptual/AutolayoutPG/ProgrammaticallyCreatingConstraints.html#//apple_ref/doc/uid/TP40010853-CH16-SW1) 或者 [Auto Layout Cookbook](https://developer.apple.com/library/content/documentation/UserExperience/Conceptual/AutolayoutPG/LayoutUsingStackViews.html#//apple_ref/doc/uid/TP40010853-CH3-SW1)。 ###### 清单3-1常见约束的示例方程 ~~~ // Setting a constant height View.height = 0.0 * NotAnAttribute + 40.0 // Setting a fixed distance between two buttons Button_2.leading = 1.0 * Button_1.trailing + 8.0 // Aligning the leading edge of two buttons Button_1.leading = 1.0 * Button_2.leading + 0.0 // Give two buttons the same width Button_1.width = 1.0 * Button_2.width + 0.0 // Center a view in its superview View.centerX = 1.0 * Superview.centerX + 0.0 View.centerY = 1.0 * Superview.centerY + 0.0 // Give a view a constant aspect ratio View.height = 2.0 * View.width + 0.0 ~~~ ## 相等，不赋值 注意到 Note 中显示的公式表示等式而非赋值是很重要的。 当自动布局解决这些方程时，它不会将右侧的值分配给左侧。 相反，它会计算属性1和属性2的值，使关系成为真。 这意味着我们可以经常自由地重新排列方程中的项目。 例如，清单3-2中的公式与Note中的对应项相同。 ###### 清单3-2倒置的方程 ~~~ // Setting a fixed distance between two buttons Button_1.trailing = 1.0 * Button_2.leading - 8.0 // Aligning the leading edge of two buttons Button_2.leading = 1.0 * Button_1.leading + 0.0 // Give two buttons the same width Button_2.width = 1.0 * Button.width + 0.0 // Center a view in its superview Superview.centerX = 1.0 * View.centerX + 0.0 Superview.centerY = 1.0 * View.centerY + 0.0 // Give a view a constant aspect ratio View.width = 0.5 * View.height + 0.0 ~~~ > 注意 > 重新排序项目时，确保你反转乘数和常数。 例如，8.0 的常数变为 -8.0。 2.0 的乘数变为0.5 。 0.0 的常量和 1.0 的乘数保持不变。 你会发现 Auto Layout 经常提供多种方法来解决同样的问题。 理想情况下，您应该选择最清楚描述您的意图的解决方案。 但是，不同的开发人员无疑会不同意哪种解决方案是最好的。 在这里，保持一致胜于正确。 如果您选择一种方法并始终坚持，您将会遇到更少的问题。 例如，本指南使用以下经验法则： 1. 整数乘数比分数数更受欢迎。 2. 正常数比负常数更受欢迎。 3. 只要有可能，视图应按布局顺序显示：从头到尾，从上到下。 ## 创建无歧义，可以满足的布局 使用自动布局时，目标是提供一系列只有一个可能解决方案的方程。 模糊的约束有多种可能的解决方案。 不可满足的约束条件没有有效的解决方案。 一般来说，约束必须定义每个视图的大小和位置。 假设已经设置了父视图的大小（例如，iOS中场景的根视图），则不含歧义，可满足的布局需要每个视图每个维度有两个约束（不包括父视图）。 但是，在选择想要使用的约束时，有多种选择。 例如，以下三种布局都会产生非歧义的，可满足的布局（仅显示水平约束）：  * 第一个布局限制视图的前沿相对于其父视图前沿的前沿。 它也给视图一个固定的宽度。 后缘的位置可以基于父视图的尺寸和其他约束来计算。 * 第二个布局相对于其父视图前沿的前沿约束了视图的前沿。 它还限制视图相对于父视图的后沿的后沿。 视图的宽度可以根据父视图的大小和其他约束来计算。 * 第三种布局相对于其父视图前沿的前沿约束视图的前沿。 它也中心对齐视图和父视图。 宽度和后缘的位置都可以基于父视图的尺寸和其他约束来计算。 注意每个布局有一个视图和两个水平约束。 在每种情况下，约束都完全定义视图的宽度和水平位置。 这意味着所有的布局都会沿水平轴产生一个不含糊的，可以满足的布局。 但是，这些布局并非同等有用。 考虑当超视图宽度改变时会发生什么。 在第一个布局中，视图的宽度不会改变。 大多数时候，这不是你想要的。 实际上，作为一般规则，您应该避免将常量大小分配给视图。 自动布局旨在创建动态适应其环境的布局。 每当你给视图一个固定的大小，降低了能力。 可能并不明显，但第二个和第三个布局产生相同的行为：随着超级视图宽度的变化，它们在视图和其超级视图之间保持固定的边距。 但是，它们并不一定是平等的。 一般来说，第二个例子更容易理解，但第三个例子可能更有用，尤其是当对齐多个项目时。 一如既往，为您的特定布局选择最佳方法。 现在考虑一些更复杂的事情。 想象一下，你想在 iPhone 上并排显示两个视图。 你要确保它们在所有方面都有很好的留白，并且它们总是具有相同的宽度。 它们也应该在设备旋转时正确调整大小。 以下插图以纵向和横向显示视图：   那么这些约束是什么样的？ 下图显示了一个简单的解决方案：  上述解决方案使用以下约束： ~~~ // Vertical Constraints Red.top = 1.0 * Superview.top + 20.0 Superview.bottom = 1.0 * Red.bottom + 20.0 Blue.top = 1.0 * Superview.top + 20.0 Superview.bottom = 1.0 * Blue.bottom + 20.0 // Horizontal Constraints Red.leading = 1.0 * Superview.leading + 20.0 Blue.leading = 1.0 * Red.trailing + 8.0 Superview.trailing = 1.0 * Blue.trailing + 20.0 Red.width = 1.0 * Blue.width + 0.0 ~~~ 遵循较早的经验法则，该布局具有两个视图，四个水平约束和四个垂直约束。 虽然这不是一个可靠的指南，但它表明您正处于正确的轨道上。 更重要的是，约束唯一地指定了两个视图的大小和位置，产生了一个不含糊的可满足的布局。 删除任何这些约束，布局变得模糊。 添加其他约束条件，您可能会引入冲突。 不过，这不是唯一可能的解决方案。 这是一个同样有效的方法：  将蓝框的顶部与红框的顶部对齐，而不是将蓝框的顶部和底部固定到其父视图。 同样，将蓝色框的底部与红色框的底部对齐。 约束如下所示。 ~~~ // Vertical Constraints Red.top = 1.0 * Superview.top + 20.0 Superview.bottom = 1.0 * Red.bottom + 20.0 Red.top = 1.0 * Blue.top + 0.0 Red.bottom = 1.0 * Blue.bottom + 0.0 //Horizontal Constraints Red.leading = 1.0 * Superview.leading + 20.0 Blue.leading = 1.0 * Red.trailing + 8.0 Superview.trailing = 1.0 * Blue.trailing + 20.0 Red.width = 1.0 * Blue.width + 0.0 ~~~ 该示例仍然有两个视图，四个水平约束和四个垂直约束。 它仍然产生一个不含糊的，可以满足的布局。 > 但哪个更好？ > 这些解决方案都生成有效的布局。 那哪个更好？ > 不幸的是，客观证明一种方法严格优于另一种方法实际上是不可能的。 每个人都有自己的长处和短处。 > 当视图被删除时，第一种解决方案更加强大。 从视图层次结构中删除视图也会删除引用该视图的所有约束。 所以，如果你删除了红色视图，蓝色视图留下了三个约束。 您只需添加一个约束，然后再次拥有有效的布局。 在第二种解决方案中，删除红色视图会使蓝色视图只有一个约束。 > 另一方面，在第一种解决方案中，如果要使视图的顶部和底部对齐，则必须确保它们的顶部和底部约束使用相同的常量值。 如果你改变一个常数，你必须记得改变另一个。 ## 约束不等式 到目前为止，所有的样本都显示出平等的限制，但这只是故事的一部分。 约束也可以表示不平等。 具体而言，约束的关系可以等于，大于等于或小于等于。 例如，可以使用约束来定义视图的最小、最大大小（清单3-3）。 ###### 清单3-3指定最小和最大大小 ~~~ // Setting the minimum width View.width >= 0.0 * NotAnAttribute + 40.0 // Setting the maximum width View.width <= 0.0 * NotAnAttribute + 280.0 ~~~ 一旦开始使用不等式，每个维度每个视图的两个约束就会崩溃。你总是可以用两个不等式来代替一个等式。在清单 3-4 中，单相等关系和两个不等式产生相同的行为。 ###### 清单 3-4 用两个不等式替换一个等式 ~~~ // A single equal relationship Blue.leading = 1.0 * Red.trailing + 8.0 // Can be replaced with two inequality relationships Blue.leading >= 1.0 * Red.trailing + 8.0 Blue.leading <= 1.0 * Red.trailing + 8.0 ~~~ 反过来并不总是正确的，因为两个不等式并不总是等价于一个等式。 例如，代码清单 3-3 中的不等式限制了视图宽度的可能值范围 - 但是它们本身并没有定义宽度。 仍然需要额外的水平约束来定义视图在此范围内的位置和大小。 ## 约束优先级 默认情况下，所有约束都是必需的。 自动布局必须计算满足所有约束的解决方案。 如果不能，则会出现错误。 自动布局向控制台输出有关不可满足约束的信息，并选择其中一个约束来中断。 然后重新计算解决方案（除去被破坏的约束）。 有关更多信息，请参阅 [Unsatisfiable Layouts](https://developer.apple.com/library/content/documentation/UserExperience/Conceptual/AutolayoutPG/ConflictingLayouts.html#//apple_ref/doc/uid/TP40010853-CH19-SW1) 。 也可以创建可选约束。 所有约束的优先级都在1到1000之间。优先级为1000的约束条件是必需的。 所有其他限制都是可选的。 计算解决方案时，自动布局尝试按优先顺序从最高到最低满足所有约束。 如果它不能满足可选约束，则跳过该约束并继续到下一个约束。 即使一个可选约束不能满足，它仍然可以影响布局。如果在跳过约束后的布局中有任何歧义，系统将选择最接近约束的解决方案。在这种情况下，不满足的可选约束可以作为一种拉动他们视图的力量。 可选的制约因素和不平等往往是相辅相成的。 例如，在清单 3-4 中，可以为这两个不等式提供不同的优先级。 可能需要大于等于关系（优先级为1000），小于等于关系的优先级较低（优先级为250）。 这意味着蓝色视图离红色点不能小于8.0点。 但是，其他约束可能会将它拉远。 尽管如此，可选约束会将蓝色视图拉向红色视图，以确保它尽可能接近8.0点间距，同时考虑到布局中的其他约束条件。 > 注意 > 不要觉得有义务全部使用1000个优先级值。 实际上，优先级应该围绕系统定义的低（250），中（500），高（750）和必需（1000）优先级。 可能需要制定高于或低于这些值一个或两个点的约束，以帮助防止关系。 如果远远超出这个范围，可能需要重新审视布局逻辑。 > 有关 iOS 上预定义约束常量的列表，请参阅 [UILayoutPriority](https://developer.apple.com/documentation/uikit/uilayoutpriority) 枚举。 对于OS X，请参阅 Layout Priorities 常量。 ## 内在内容大小 到目前为止，所有的例子都使用约束来定义视图的位置和大小。 但是，根据当前内容，某些视图具有自然大小。 这被称为它们的内在内容大小。 例如，按钮的内在内容大小是其标题的大小加上一个小的余量。 并非所有视图都具有内在内容大小。 对于有的视图，内在内容大小可以定义视图的高度，宽度或两者。 表 3-1 列出了一些示例。 ###### 表 3-1 常用控件的内部内容大小。 | 视图 | 内在内容大小 | | --- | --- | | UIView and NSView | 无 | | Sliders | 仅定义宽度（iOS）。定义宽度，高度或两者 - 取决于滑块的类型（OS X）。 | | Labels, buttons, switches, and text fields | 定义高度和宽度。 | | Text views and image views | 内部内容的大小可以变化。 | 内在内容大小基于视图的当前内容。 标签或按钮的内在内容大小基于显示的文本量和使用的字体。 对于其他视图，内在内容的大小更加复杂。 例如，空图像视图不具有内在内容大小。 但是，只要添加图像，其内在内容大小就会设置为图像的大小。 文本视图的内在内容大小因内容，是否启用滚动以及应用于视图的其他约束而异。 例如，启用滚动功能后，该视图不具有固有内容大小。 在禁用滚动的情况下，默认情况下视图的内在内容大小是基于文本的大小计算的，没有任何换行。 例如，如果文本中没有换行，它将计算将内容布置为单行文本所需的高度和宽度。 如果添加约束来指定视图的宽度，则内在内容大小将定义显示指定其宽度的文本所需的高度。 自动布局使用每个维度的一对约束来表示视图的内在内容大小。 内容拥抱将内部视图拉向内部，使其适合周围的内容。 压缩阻力将视图向外推，以便它不剪裁内容。  这些约束是使用清单 3-5 中显示的不等式定义的。 这里，IntrinsicHeight 和 IntrinsicWidth 常量表示视图内在内容大小的高度和宽度值。 ###### 清单3-5压缩阻力和内容拥抱方程 ~~~ // Compression Resistance View.height >= 0.0 * NotAnAttribute + IntrinsicHeight View.width >= 0.0 * NotAnAttribute + IntrinsicWidth // Content Hugging View.height <= 0.0 * NotAnAttribute + IntrinsicHeight View.width <= 0.0 * NotAnAttribute + IntrinsicWidth ~~~ 每个约束都可以有其自己的优先级。默认情况下，视图对其内容拥有使用250优先级，而对于其压缩抵抗则使用750优先级。因此，拉伸视图比缩小视图更容易。 对于大多数控制，这正是想要的行为。例如，可以安全地拉伸大于其内在内容大小的按钮; 但是，如果你缩小它的内容，它的内容可能会被剪辑掉。请注意，Interface Builder 可能会偶尔修改这些优先级以帮助防止关联。有关更多信息，请参阅 [Setting Content-Hugging and Compression-Resistance Priorities](https://developer.apple.com/library/content/documentation/UserExperience/Conceptual/AutolayoutPG/WorkingwithConstraintsinInterfaceBuidler.html#//apple_ref/doc/uid/TP40010853-CH10-SW2)。 只要有可能，请在布局中使用视图的内在内容大小。 它可以让布局动态适应视图内容的变化。 它还减少了创建无歧义，无冲突布局所需的约束数量，但需要管理视图的内容拥抱和抗压缩（CHCR）优先级。 以下是处理内在内容大小的一些准则： * 在拉伸一系列视图以填充空间时，如果所有视图具有相同的内容拥抱优先级，则布局不明确。 自动布局不知道应该拉伸哪个视图。一个常见的例子是标签和文本字段。 通常情况下，希望文本字段进行拉伸以填充额外空间，同时标签保持其固有内容大小。 为确保这一点，请确保文本字段的水平内容拥抱优先级低于标签。实际上，这个例子非常常见，Interface Builder 自动为您处理它，将所有标签的内容拥抱优先级设置为251。如果以编程方式创建布局，则需要自己修改内容拥抱优先级。 * 当具有不可见背景（如按钮或标签）的视图意外伸展超出其内在内容大小时，通常会出现奇怪和意外的布局。 实际问题可能并不明显，因为文本只出现在错误的位置。 为了防止不必要的拉伸，增加内容拥抱优先级。 * 基线约束仅适用于处于内在内容高度的视图。 如果视图被垂直拉伸或压缩，则基线约束不再正确对齐。 * 一些视图，如开关，应始终以其固有内容大小显示。 根据需要增加他们的 CHCR 优先级以防止拉伸或压缩。 * 避免给予视图CHCR的优先级。通常认为错误的大小比不小心造成冲突要好。如果视图应该始终是其固有的内容大小，那么可以考虑使用非常高的优先级(999)。这种方法通常使视图不被拉伸或压缩，但仍然提供了一个紧急压力阀，以防视图显示在比预期的更大或更小的环境中。 ## 内在内容大小与合适大小 内在内容大小作为自动布局的输入。 当视图具有内在内容大小时，系统会生成约束来表示该大小，并使用约束来计算布局。 另一方面，合适尺寸是自动布局引擎的输出。 它是根据视图的约束为视图计算的大小。 如果视图使用“自动布局”布局其子视图，则系统可能会根据视图的内容计算视图的合适尺寸。 堆栈视图就是一个很好的例子。 除了任何其他限制，系统都会根据其内容和属性计算堆栈视图的大小。 在许多方面，堆栈视图的行为就好像它具有内在内容大小：可以使用仅一个垂直和一个水平约束来定义其位置来创建有效的布局。 但其大小是通过自动布局计算的 - 它不是自动布局的输入。 设置堆栈视图的 CHCR 优先级不起作用，因为堆栈视图没有固有内容大小。 如果需要相对于堆栈视图外的项目调整堆栈视图的合适大小，请创建显式约束来捕获这些关系，或者修改堆栈内容相对于堆栈外项目的 CHCR 优先级。 ## 约束属性值 自动布局中的值总是以点为单位。 但是，这些测量的确切含义可能会因涉及的属性和视图的布局方向而异。 | 图标| 自动布局属性 | 值 | 备注 | | --- | --- | --- |--- | |  | Heigh | 视图的大小 |这些属性可以赋予常量值或与其他高度和宽度属性结合使用。 这些值不能为负数。 | |  | Width | 视图的大小 |这些属性可以赋予常量值或与其他高度和宽度属性结合使用。 这些值不能为负数。 | |  | Top | 随着向下移动屏幕，值会增加 |这些属性只能与Center Y，Top，Bottom和Baseline属性组合。 | |  | Bottom | 随着向下移动屏幕，值会增加 |这些属性只能与Center Y，Top，Bottom和Baseline属性组合。 | |  | Baseline | 随着向下移动屏幕，值会增加 |这些属性只能与Center Y，Top，Bottom和Baseline属性组合。 | |  | Leading | 随着朝着后缘移动，这些值会增加。 对于从左到右的布局方向，当您向右移动时，值会增加。 对于从右向左布局方向，向左移动时值会增加。 | 这些属性只能与Leading，Trailing或Center X属性组合。| |  | Trailing | 随着朝着后缘移动，这些值会增加。 对于从左到右的布局方向，当您向右移动时，值会增加。 对于从右向左布局方向，向左移动时值会增加。 | 这些属性只能与Leading，Trailing或Center X属性组合。| |  | Left |随着您向右移动，值会增加。 |这些属性只能与 Left，Right 和 Center X 属性组合。避免使用左右属性。 改用 Leading 和 Trailing 。 这允许布局适应视图的阅读方向。默认情况下，阅读方向是根据用户设置的当前语言确定的。 但是，您可以在必要时重写此操作。 在 iOS 中，在包含约束的视图上设置 [semanticContentAttribute](https://developer.apple.com/documentation/uikit/uiview/1622461-semanticcontentattribute) 属性（受约束影响的所有视图的最近共同祖先），以指定在从左到右和从右到左语言之间切换时是否应翻转内容的布局。 |  | Right | 随着您向右移动，值会增加。 | 这些属性只能与 Left，Right 和 Center X 属性组合。避免使用左右属性。 改用 Leading 和 Trailing 。 这允许布局适应视图的阅读方向。默认情况下，阅读方向是根据用户设置的当前语言确定的。 但是，您可以在必要时重写此操作。 在 iOS 中，在包含约束的视图上设置 [semanticContentAttribute](https://developer.apple.com/documentation/uikit/uiview/1622461-semanticcontentattribute) 属性（受约束影响的所有视图的最近共同祖先），以指定在从左到右和从右到左语言之间切换时是否应翻转内容的布局。| |  | Center X | 解释基于方程中的其他属性。 | Center X可以与Center X，Leading，Trailing，Right和Left属性结合使用。Center Y可以与Center Y，Top，Bottom和Baseline属性结合使用。| |  | Center Y | 解释基于方程中的其他属性。 | Center X可以与Center X，Leading，Trailing，Right和Left属性结合使用。Center Y可以与Center Y，Top，Bottom和Baseline属性结合使用。| >原文地址 >[Anatomy of a Constraint ](https://developer.apple.com/library/content/documentation/UserExperience/Conceptual/AutolayoutPG/AnatomyofaConstraint.html#//apple_ref/doc/uid/TP40010853-CH9-SW1)