#SwiftUI #English

探索 SwiftUI ZStack 中的 layoutPriority 奥秘

发表于

在 SwiftUI 的布局体系中，.layoutPriority 这一修饰器看似并不起眼，却在关键时刻能左右视图的尺寸分配。大多数开发者都了解它在 VStack 和 HStack 中为子视图争取更多空间的“魔法”能力——优先级越高，越能从拥挤的布局中脱颖而出。但你是否注意过，.layoutPriority 在 ZStack 中也能大显身手？但它的运作机制与 VStack/HStack 完全不同。本篇文章将带你深入剖析这一鲜为人知的特性，演示如何在 ZStack 中应用布局优先级。

layoutPriority 简介

苹果官方文档中对 .layoutPriority 的描述是这样的：

Sets the priority by which a parent layout should apportion space to this child.

设置父布局向此子视图分配空间时的优先级。

这一定义告诉我们：你可以为视图分配一个优先级（默认值为 0），但并未阐明布局容器是否会采纳这条信息，也没有说明优先级在实际排版过程中如何影响空间分配。

换句话说：不同的布局容器对 layoutPriority 的处理方式可能大相径庭，理解它们各自的“游戏规则”是深入掌握 SwiftUI 布局的关键。

HStack 与 VStack 中的 layoutPriority

在 HStack 和 VStack 中，多数开发者都能很好的应用 .layoutPriority：它能在空间紧张时，为具有更高优先级的视图“争取”更多建议尺寸。

示例 1：HStack

Swift 
struct HStackDemoView: View {
    var body: some View {
        HStack(spacing: 0) {
            Text("Leading String,Leading String")
                .font(.largeTitle)
                .layoutPriority(0) // Default
                .border(Color.red, width: 2)
            Text("Trailing String 123456")
                .font(.largeTitle)
                .layoutPriority(1) // 1 > 0，更高的视图优先级
                .border(Color.orange, width: 2) 
        }
        .frame(height: 50)
    }
}

当容器宽度不足时，第二个 Text（优先级 1）会优先获得更多可用空间。

image-20250616085618068

示例 2：VStack

Swift 
struct VStackDemo: View {
    var body: some View {
        VStack {
            VStack(spacing:0){
                Rectangle() // default priority is zero
                    .foregroundStyle(.green)
                Text("Hello World") // default priority is zero
                Rectangle()
                    .foregroundStyle(.pink)
                    .layoutPriority(1) 
            }
        }
        .frame(height:300)
    }
}

在这个例子里，粉色矩形因具有更高优先级，会占用大部分垂直空间，绿色矩形则被“挤”出了可视区域。

image-20250616090529662

相信细心的读者此时会产生疑惑：为什么同样优先级为 0 的 Text 被保留了？即使我们进一步降低 Text 的优先级，它仍然会被完整显示出来。

Swift 
Text("Hello World")
    .layoutPriority(-100) // 极低优先级

这正是 VStack 对子视图在纵向排列上表现出的“贪婪”行为的特殊处理结果：

  • 贪婪视图（如 Rectangle）在纵向最大建议尺寸模式下会返回 .infinity，表现为“我要占满所有空间”。
  • 非贪婪视图（如 Text 或通过 frame 明确尺寸的视图）仅返回自身所需大小。

在分配空间时，VStack 会先保证所有 非贪婪 视图的需求，再在 贪婪 视图之间比对 layoutPriority。因此，即使粉色矩形优先级高于 Text，但它们属于不同“贪婪”类别，VStack 并不会让 Text 与粉色矩形直接竞争。

下面这个场景更能凸显差异：当整体高度缩减到仅能容纳 Text 时，它依旧保留显示，而更高优先级的粉色矩形被完全裁剪。

Swift 
struct VStackDemo: View {
    var body: some View {
        VStack {
            VStack(spacing:0){
                Rectangle()
                    .foregroundStyle(.green)
                Text("Hello World")
                    .layoutPriority(-100) // 更小的优先级
                Rectangle()
                    .foregroundStyle(.pink)
                    .layoutPriority(1)
            }
        }
        .frame(height:20) // 高度仅够 Text
    }
}

image-20250616091708182

延伸阅读：更多关于 VStack 排版策略与细节，请参见我在 Let Vision 2025 的演讲 探索 SwiftUI 尺寸的秘密。

通过上述示例，你可以看到：在 HStack/VStack 中，layoutPriority 主要左右子视图之间的空间分配比例，而不会改变容器的整体尺寸。下一节，我们将揭开它在 ZStack 中的别样魔法。

ZStack 中的 layoutPriority

一直以来我都没有意识到 ZStack 同样会根据子视图的优先级而产生行为变化，直到今早我看到了 OpenSwiftUI 的作者 Kyle Ye 在凌晨发来的信息，他表示在为 OpenSwiftUI 构建 ZStack 时，发现 layoutPriority 会影响最终视图的布局尺寸。

Swift 
struct ZStackDemo: View {
    var body: some View {
        ZStack(alignment: .topTrailing) {
            Rectangle()
                .foregroundStyle(.red.opacity(0.8))
                .frame(width: 200, height: 200)
                .layoutPriority(1)
            Rectangle()
                .foregroundStyle(.blue.opacity(0.8))
                .frame(width: 100, height: 100)
                .layoutPriority(2)
            Rectangle()
                .foregroundStyle(.orange.opacity(0.8))
                .frame(width: 150, height: 150)
                .layoutPriority(2)
        }
        .border(Color.black, width: 5) // 展现 layout size
    }
}

image-20250616093051134

如图所示，黑色边框仅包裹了 150×150 的区域，而 红色（200×200）并未纳入 ZStack 的最终尺寸。这说明：

  • ZStack 并不简单地取包含所有子视图的最小边界；
  • 它只考虑 具有最高 layoutPriority（即本例中为 2）的子视图集合，计算出能同时容纳它们的最小对齐尺寸，作为自身的建议尺寸。

为了更直观地演示这一机制，我们调整蓝色矩形的 alignmentGuide：

Swift 
Rectangle()
    .foregroundStyle(.blue.opacity(0.8))
    .frame(width: 100, height: 100)
    .layoutPriority(2)
    .alignmentGuide(.trailing){ $0.width/2} // 调整 topTrailing 对应的位置

image-20250616093945187

这会移动蓝色方块在 .topTrailing 对齐时的位置，但 ZStack 的边框仍旧依据那两个 layoutPriority == 2 的视图来计算。

动态调整 ZStack 尺寸

凭借这一特性，你可以在不改变子视图尺寸的前提下，仅通过切换 layoutPriority，动态调整 ZStack 的对外建议尺寸——这是传统的 if/switch 或 ViewThatFits 难以实现的。示例：

Swift 
struct SwitchDemo: View {
    @State var selection: Selection = .a
    var body: some View {
        HStack {
            Text("Hello")
            DynamicSizeZStack(selection: $selection)
            Text("World")
        }
        
        Picker(selection: $selection.animation(), content: {
            ForEach(Selection.allCases) {
                Text($0.rawValue)
                    .tag($0)
            }
        }, label: { Text("Selection") })
            .pickerStyle(.segmented)
            .padding(.horizontal)
    }
}

struct DynamicSizeZStack: View {
    @Binding var selection: Selection
    var body: some View {
        ZStack {
            Rectangle().foregroundStyle(Color.blue).frame(width: 200, height: 200)
                .layoutPriority(selection == .a ? 1 : 0)
                .opacity(selection == .a ? 1 : 0)
            
            Rectangle().foregroundStyle(Color.orange).frame(width: 150, height: 150)
                .layoutPriority(selection == .b ? 1 : 0)
                .opacity(selection == .b ? 1 : 0)
            
            Rectangle().foregroundStyle(Color.blue).frame(width: 100, height: 100)
                .layoutPriority(selection == .c ? 1 : 0)
                .opacity(selection == .c ? 1 : 0)
        }
        .animation(.smooth, value: selection)
    }
}

enum Selection: String, Equatable, CaseIterable, Hashable, Identifiable {
    case a, b, c
    var id: Self { self }
}

通过这一技巧，你可以在保持子视图标识符稳定、尺寸不变的同时，让父容器根据不同场景自动伸缩，提升布局的灵活性与可维护性。增加了一种新的布局调整手段！

黑盒子和文档

SwiftUI 已走过七年征程，表面上每个版本都带来了丰富的新 API，但其底层布局引擎的运作逻辑从未改变。

正是这份始于一开始的深思熟虑，让我们在 HStack、VStack 和 ZStack 中探索 .layoutPriority 的不同表现时，始终能感受到一种“既定规则”下的奇妙弹性——无论是纵向“贪婪”与“非贪婪”视图的微妙博弈，还是 ZStack 按照最大优先级聚焦尺寸的独到做法，都源自同一套设计原则。

可惜的是，SwiftUI 的官方文档往往只“透露一角”，缺少对这些排版细节的充分说明。开发者只能靠反复试验社区经验，才能逐渐拼凑出完整图景。

每当迷失于文档的“吝啬”与黑箱的神秘，我总会自嘲一句：“感谢苹果的克制，让我们这些开发者少了 AI 取代的风险，多了亲手揭秘的乐趣。”

"加入我们的 Discord 社区，与超过 2000 名苹果生态的中文开发者一起交流！"

每周精选 Swift 与 SwiftUI 精华！