核心内容摘要
穿越“404”,解锁“黄台”的无限可能
别再跟绝对像素“死磕”流体布局的思维重构做 iOS 开发这么多年我见过最恐怖的代码不是逻辑复杂的算法而是满屏写死的frame: CGRectMake(0, 0, 375,
。
老兄醒醒iPhone 6 的时代早就过去了。
现在的苹果生态就是个屏幕尺寸的万花筒。
从 iPhone SE 的
7 寸 mini 屏到 iPad Pro
1
9 寸的巨无霸再到分屏模式Split View下那些奇奇怪怪的 1/
2/3 比例任何试图用“绝对坐标”去解决问题的想法最后都会变成你深夜 debug 时流下的眼泪。
自适应布局的核心根本不是“适配不同屏幕”而是“忘掉屏幕”。
你需要建立一种流体思维Fluid Thinking。
这就好比水倒进杯子里是杯子的形状倒进壶里是壶的形状。
你的 UI 元素应该根据容器的约束Constraints或者环境Environment自己决定长什么样而不是你像个保姆一样告诉它“你宽 200高 100”。
在 SwiftUI 时代我们就默认你已经不想写繁琐的 Auto Layout 约束代码了Stacks堆栈和Flexibility弹性是你的两把武器。
看个反面教材// ❌ 典型的“保姆式”写法写死宽高横屏必挂 VStack { Image(cover) .frame(width: 300, height:
// 到了iPad上这就跟邮票一样小 Text(标题) .padding(.top,
}我们要怎么改要告诉它“尽可能占满空间但保持比例”。
// ✅ 这种写法才是“成年人”的代码 VStack { Image(cover) .resizable() .aspectRatio(contentMode: .fit) // 保持图片比例 .frame(maxWidth: .infinity) // 横向有多少吃多少 .padding() // 给点呼吸感别贴边 }注意那个maxWidth: .infinity。
这行代码是精髓。
它不是说无限大而是告诉布局系统“父视图给我多少空间我就撑多大”。
这种思维转换是痛苦的特别是对于习惯了设计稿上标多少像素就写多少像素的开发者。
但你必须迈过这道坎。
一旦你习惯了相对关系比如 A 在 B 上面A 的宽度是 B 的 50%而不是绝对数值屏幕旋转对你来说就只是容器变了个尺寸而已布局会自动流淌到新的位置丝般顺滑。
Size Classes苹果给你的“作弊代码”很多新手在做 iPad 适配时还在傻傻地判断UIDevice.current.userInterfaceIdiom .pad。
千万别这么干。
为什么因为 iPad 在分屏模式下Split View如果不全屏它的宽度可能比 iPhone Max 还要窄如果你单纯判断是 iPad 就给它展示一个宽大的双栏布局用户一分屏你的 UI 就会挤成一坨浆糊。
苹果在几年前就给出了一套极其优雅的解决方案Size Classes尺寸等级。
这玩意儿听着玄乎其实就两个值Compact紧凑空间局促比如 iPhone 竖屏的宽度。
Regular常规空间充裕比如 iPad 全屏或者 iPhone Max 横屏的宽度。
利用这套逻辑我们不用管具体设备是啥只关心“当前可用的空间等级”。
在 SwiftUI 里拿到这个状态简单到令人发指struct AdaptiveView: View { // 这一行代码值千金直接从环境里抓取当前的横向尺寸等级 Environment(\.horizontalSizeClass) var horizontalSizeClass var body: some View { if horizontalSizeClass .compact { // iPhone 竖屏或者 iPad 极窄分屏 // 咱们老老实实上下排列 VStack { MyContent() } } else { // iPad 全屏iPhone 横屏等宽裕环境 // 空间这么大必须左右开弓 HStack { MySideBar() MyMainContent() } } } }看懂了吗这种判断方式极其健壮。
不管你是旋转屏幕还是在 iPad 上拖动分屏条改变 App 大小系统会自动触发这个horizontalSizeClass的变化你的布局会像变形金刚一样咔咔咔自己重组。
这里有个坑要特别提一下全是血泪教训iPad 即使竖屏拿着它的horizontalSizeClass也是Regular。
很多开发者想当然以为 iPad 竖屏就该像大号 iPhone 那样显示结果发现布局还是左右分栏显得很拥挤。
如果你想专门针对 iPad 竖屏做特殊处理光靠 Size Classes 是不够的这时候你可以稍微结合一下GeometryReader来读取具体宽度但这属于高级操作咱们后面细聊。
记住Compact 意味着“堆叠”Regular 意味着“铺开”。
掌握这个原则你就掌握了 90% 的自适应逻辑。
别被 GeometryReader 骗了它是把双刃剑既然前面提到了GeometryReader咱们就得好好唠唠这个让无数人爱恨交织的组件。
很多教程会告诉你“想要获取屏幕尺寸用 GeometryReader 啊”于是你写出了这样的代码// ⚠️ 危险动作请勿模仿 GeometryReader { geometry in VStack { Text(宽度是: \(geometry.size.width)) } }乍一看没毛病。
但你运行一下就会发现原本好好的布局突然变得乱七八糟甚至把其他视图都挤跑了。
原因是GeometryReader 极其贪婪。
它默认会尽可能抢占所有可用空间。
你一旦把它放进布局里它就像个流氓一样撑开整个父视图破坏你原本精心设计的 Auto Layout 逻辑。
那什么时候用只有当你真的需要根据父视图的具体尺寸像素级来决定子视图的大小时才请它出山。
举个实战中非常实用的例子自适应网格Adaptive Grid。
在相册应用里我们要显示一堆照片。
在 iPhone 上一行显示 3 张在 iPad 上一行显示 6 张转个屏可能又要变。
写死列数肯定是不行的。
这时候我们可以结合GridItem的.adaptive属性但这有时候不可控。
如果你想精确控制GeometryReader 配合计算就能派上用场struct ResponsiveGrid: View { let items
..20 var body: some View { GeometryReader { geo in // 动态计算屏幕越宽列数越多 // 假设每张图最小宽度是 100 let columnsCount Int(geo.size.width /
// 至少保证有1列不然 crash 给你看 let columns Array(repeating: GridItem(.flexible()), count: max(1, columnsCount)) ScrollView { LazyVGrid(columns: columns, spacing:
{ ForEach(items, id: \.self) { item in Image(photo-\(item)) .resizable() .aspectRatio(1, contentMode: .fit) .cornerRadius(
} } } } } }这段代码的高明之处在于它完全不依赖设备型号。
你把它扔到 iPhone mini 上它算出来 3 列扔到 iPad Pro 横屏上它可能算出来 12 列。
不管用户怎么折腾屏幕布局始终填满而且元素大小均匀。
这才是真正的自适应。
使用 GeometryReader 的黄金法则尽量只在叶子节点View Hierarchy 的末端使用。
如果不确定先尝试用.frame(maxWidth: .infinity)解决解决不了再找它。
导航栏的革命NavigationSplitView在 iOS 16 之前做 iPad 的主从视图左边列表右边详情简直是噩梦。
NavigationView的.navigationViewStyle(.doubleColumn)时灵时不灵bug 多到你想转行去卖炒粉。
如果你现在的项目 target 是 iOS 16恭喜你NavigationSplitView是你的救世主。
这不仅仅是个 UI 组件它代表了苹果对大屏交互的最新理解。
在 iPhone 上它是经典的 Push 导航A - B在 iPad 上它自动变成左侧常驻列表、右侧详情的各种组合。
看个最简练的实现struct MailLayout: View { State private var selectedCategory: Category? State private var selectedEmail: Email? State private var columnVisibility NavigationSplitViewVisibility.all var body: some View { // 三栏布局侧边栏 | 列表 | 详情 NavigationSplitView(columnVisibility: $columnVisibility) { // 第一栏文件夹列表 List(Category.all, selection: $selectedCategory) { cat in NavigationLink(cat.name, value: cat) } .navigationTitle(邮箱) } content: { // 第二栏邮件列表 if let cat selectedCategory { List(cat.emails, selection: $selectedEmail) { email in NavigationLink(email.subject, value: email) } } else { Text(请选择文件夹) } } detail: { // 第三栏邮件正文 if let email selectedEmail { EmailDetailView(email: email) } else { Text(未选择邮件) .foregroundColor(.secondary) } } .navigationSplitViewStyle(.balanced) } }这里有个细节非常有高级感columnVisibility。
通过绑定这个状态你可以编程控制侧边栏的显示和隐藏。
比如用户点击了某个按钮你可以让侧边栏自动收起给内容区域腾出更多空间。
注意细节处理 在 iPad 竖屏状态下默认侧边栏是收起的Slide over。
很多设计师会这里卡住觉得“我的菜单哪去了”。
你需要向他们解释这是系统行为。
如果你非要强制显示侧边栏比如在某些工具类 App 中可以调整.navigationSplitViewStyle或者在初始化时设置默认可见性。
但小心过度干预系统行为通常会让用户觉得你的 App “手感不对”。
真正优秀的自适应是在用户甚至没有意识到布局发生变化的情况下把信息最自然地呈现出来。
从单栏平滑过渡到双栏甚至三栏中间没有生硬的跳转这才是高手。
和“安全区域”共舞别让灵动岛吃了你的标题接上回咱们聊聊那个让设计师抓狂、让开发者头秃的东西——安全区域Safe Area。
自从 iPhone X 搞出了个“刘海”后来 iPhone 14 Pro 又进化成了“灵动岛”屏幕早就不是一个完美的矩形了。
很多新手的 App 一跑起来好家伙状态栏的时间盖住了标题底部的 Home Indicator那条横线挡住了按钮。
最常见的自杀式写法是给所有视图无脑加.ignoresSafeArea()。
“我想让背景铺满全屏”——这想法没错但你不能把内容也铺出去啊。
正确的姿势是背景无界内容有界。
在 SwiftUI 里实现这个效果有个极其经典的 Pattern建议直接刻进你的代码片段库里ZStack { //
背景层这一层负责“色诱”用户 Color.blue .ignoresSafeArea() // 只有它有资格无视边界 //
内容层这一层负责干活 VStack { Text(我是安全的标题) .font(.largeTitle) Spacer() Button(底部操作) { } } .padding() // 给内容一点喘息空间别贴着安全区边缘 }注意看这里的VStack没有加 ignore。
这意味着系统会自动算出灵动岛的高度、底部圆角的高度把VStack乖乖地限制在一个绝对安全的矩形内。
进阶技巧针对特定边缘的“微操”有时候设计稿会给你出难题。
比如一个底部的浮动面板背景要是白色的还要延伸到屏幕最底端盖住 Home Indicator 区域但面板里的按钮不能被那条黑线挡住。
这时候你需要拆解安全区VStack { Spacer() HStack { Text(总价: ¥
99.
Spacer() Button(去结算) { } } .padding() .background(Color.white) // 背景色给在这个容器上 } .safeAreaInset(edge: .bottom) { // 这个修改器是 iOS 15 的神器 // 它允许你在安全区域之外“挂”点东西同时自动调整主视图的布局 Color.clear.frame(height:
} // 关键点我们只让底部背景延伸而不是让整个视图延伸其实这里有个更简单的思维模型把背景色做成 footer 的一部分延伸出去但 padding 留足。
千万别小看这个。
在横屏模式下左右两侧的安全区为了避开刘海会非常宽。
如果你硬要把按钮贴边放用户想按的时候手指可能会抽筋。
尊重 Safe Area就是尊重用户的手指。
字体也能“流体化”Dynamic Type 不是让你把字号写死做适配如果只盯着屏幕宽高度那你的格局就小了。
你有没有试过把手机设置里的“字体大小”调到最大或者开启“粗体文本”90% 的 App 在这种情况下都会崩坏文字重叠、按钮撑爆、截断显示...苹果非常看重无障碍Accessibility。
作为付费专栏的读者你的 App 必须具备“文字弹性”。
第一诫放弃.system(size:
写死数字是万恶之源。
现在的用户可能是眼神犀利的鹰眼少年也可能是老花眼的大爷。
请使用语义化字体风格// ❌ 到了大字号模式下这行字会像蚂蚁一样小 Text(用户协议) .font(.system(size:
) // ✅ 系统会自动根据设置缩放还能保持层级感 Text(用户协议) .font(.caption) .fontWeight(.medium)第二诫图标也要跟着变大这是很多中级开发者都会忽略的细节。
文字变大了旁边的 icon 如果还是 20x20就会显得极其滑稽像个大头娃娃配了个小短腿。
SwiftUI 提供了一个极其优雅的属性包装器ScaledMetricstruct AdaptiveIconRow: View { // 这行代码是魔法所在 // 它会根据当前的字体设置自动计算出
2
0 应该放大成多少 ScaledMetric(relativeTo: .body) var iconSize: CGFloat 20 var body: some View { HStack { Image(systemName: star.fill) .frame(width: iconSize, height: iconSize) // 用计算后的值 Text(收藏) .font(.body) // 字体和图标关联了同一个层级 } } }当你把系统字体调大那个星星图标也会按比例变大整个 UI 的韵律感Rhythm不会被破坏。
布局防爆指南 在大字号模式下原本一行的HStack极大概率会放不下。
这时候你需要把HStack这种强硬的布局换成更柔和的流式布局或者允许它折行。
但是在 SwiftUI 原生支持 FlowLayout 之前虽然现在有了 Layout 协议最简单的兜底方案是限制行数但允许缩放。
.lineLimit(
.minimumScaleFactor(
0.
这行代码的意思是“尽量显示一行实在不行就把字缩小一半如果还不行...好吧那就截断。
”这是一个非常实用的妥协方案。
ViewThatFits终极“备胎”计划iOS 16 带来了一个我认为被严重低估的组件ViewThatFits。
它的逻辑非常符合人类直觉“我给你几个方案你从第一个开始试哪个能完整塞进去不被截断就用哪个。
”这简直是处理横竖屏差异的神技连if-else判断都不需要写。
场景一个包含长标题和按钮的卡片。
竖屏空间窄按钮应该在标题下面垂直排列。
横屏空间宽按钮应该在标题右边水平排列。
以前我们要用 GeometryReader 算宽度或者用 Size Classes 判断。
现在两行代码搞定struct SmartCard: View { var body: some View { ViewThatFits(in: .horizontal) { // 方案 A优先尝试水平布局 // 系统会偷偷算一下如果把这俩横着放会不会超出屏幕 // 如果不超出就选它 HStack { Text(这是一个超级无敌长的标题文字) .fixedSize(horizontal: true, vertical: false) // 告诉系统别压缩我 Spacer() Button(购买) { } } // 方案 B如果方案 A 宽度炸了就用这个 VStack(alignment: .leading) { Text(这是一个超级无敌长的标题文字) Button(购买) { } } } .padding() .background(Color.gray.opacity(
0.
) .cornerRadius(
} }看懂了吗这种声明式的自适应比你手动写逻辑判断要高明得多。
因为它关心的不是“现在的屏幕是宽还是窄”而是“内容到底能不能放得下”。
这在多语言适配时也极其好用。
英文可能很短用横排德语可能巨长自动切成竖排。
不需要你改一行代码UI 自己会思考。
键盘避让即使到了2026年依然是痛如果说有什么 bug 能让 iOS 开发者在深夜痛哭键盘遮挡绝对排前三。
你在屏幕底部放了个输入框用户一点键盘弹起直接盖住了输入框。
用户就在那盲打体验极差。
SwiftUI 在这方面比 UIKit 进步了很多大部分标准组件如List,Form自带键盘避让。
但如果你搞了个自定义布局比如底部固定的评论栏问题就来了。
黄金法则用safeAreaInset配合.keyboard不要试图去监听键盘高度通知Keyboard Notification那太老土了而且很难处理第三方输入法的高度变化。
struct ChatInputView: View { State private var text var body: some View { ScrollView { // 聊天记录... ForEach(
.
{ _ in Text(消息...) } } .safeAreaInset(edge: .bottom) { // 把输入框放在安全区域插槽里 HStack { TextField(说点什么..., text: $text) .textFieldStyle(.roundedBorder) Button(发送) { } } .padding() .background(.thinMaterial) // 毛玻璃效果 // 重点来了告诉系统这个底部视图要避让键盘 // 注意在 iOS 16 默认行为已经优化 // 但有时候你需要显式加上 .ignoresSafeArea(.keyboard, edges: .bottom) 的反向逻辑 } } }这里有个玄学 有时候你想让背景铺满键盘区域比如聊天背景图但输入框要浮在键盘上。
这时你要给最外层容器加.ignoresSafeArea(.keyboard)然后给输入框容器单独处理避让。
另外iOS 16 引入了scrollDismissesKeyboard(.interactively)。
加上这一行用户按住列表往下一拖键盘就乖乖收起交互手感瞬间提升一个档次跟原生 iMessage 一模一样。
小结一下 做自适应布局本质上是在处理约束。
屏幕尺寸是约束安全区域是约束用户字体设置是约束键盘弹起也是约束。
优秀的 iOS 工程师不会把 UI 画死而是编写一套规则让 UI 在这些约束的夹缝中像水一样流动最终找到最舒适的姿态。
数据流的“量子纠缠”当左边变了右边怎么办UI 只是皮囊数据才是灵魂。
在单屏 iPhone 应用里数据流通常是线性的从上往下传。
但在 iPad 的NavigationSplitView里事情变得复杂了。
左侧是列表Master右侧是详情Detail。
用户在左边点了一下右边必须瞬间刷新。
而且如果用户在右边修改了数据比如把邮件标记为未读左边的列表项状态也得立马变。
这如果不处理好你的 App 就会出现经典的“状态不同步” Bug——左边显示“未读”右边显示“已读”用户看着都精神分裂。
在 iOS 17 之前我们被ObservableObject和Published折磨得死去活来。
现在Observable宏Macro来了。
它简直是数据流管理的工业革命。
只要给你的模型类加上这一行魔法就生效了Observable class AppState { var selectedMailID: UUID? var mails: [Mail] [] // 这是一个计算属性但视图能感知它的变化 var selectedMail: Mail? { get { mails.first { $
id selectedMailID } } set { if let newValue, let index mails.firstIndex(where: { $
id newValue.id }) { mails[index] newValue } } } }注意到了吗没有 Published没有任何 Combine 的痕迹。
Swift 编译器在背后帮你搞定了一切依赖追踪。
在视图里使用它简单到令人发指struct MailSplitView: View { // 注入这个“单一下发源” State private var appState AppState() var body: some View { NavigationSplitView { List(appState.mails, selection: $appState.selectedMailID) { mail in MailRow(mail: mail) } } detail: { // 重点处理“空状态” // 在 iPad 刚启动或者没选任何东西时右边不能是白的 if let mail appState.selectedMail { MailDetailView(mail: mail) } else { ContentUnavailableView(未选择邮件, systemImage: envelope.open) } } .environment(appState) // 注入环境让子视图也能拿到 } }这里有个必须强调的架构原则不要直接传递整个 Model 对象给 Binding除非你极其确定那个对象是引用类型且被正确观测。
更推荐的做法是传递ID。
左侧列表只负责告诉 State“嘿ID 为 123 的这货被翻牌子了”。
然后 State 负责算出具体的 Object 扔给右侧详情页。
这样能最大限度避免“僵尸对象”引用特别是在你的列表数据是从网络动态拉取的时候。
给 View 写个“条件修改器”代码洁癖的自我修养写自适应布局时最恶心的情况就是 “我想在 iPad 上给这个卡片加个阴影但在 iPhone 上不要。
” “我想在横屏时给这个文字加粗竖屏时不要。
”如果你在body里写满了一堆if isPad { ... } else { ... }你的代码可读性会降到负数。
这时候你需要祭出 SwiftUI 的隐藏大招自定义 ViewModifier。
但这还不够我们要更进一步写一个“条件生效”的扩展。
这招在 GitHub 的高星库里很常见但普通开发者很少用。
extension View { // 如果 condition 为真就应用 transform 闭包里的修改器 // 如果为假就原样返回 ViewBuilder func ifConditionContent: View(_ condition: Bool, transform: (Self) - Content) - some View { if condition { transform(self) } else { self } } }有了这个神器你的布局代码就能像散文一样流畅struct AdaptiveCard: View { Environment(\.horizontalSizeClass) var hClass var body: some View { VStack { Text(精选文章) } .padding() .background(Color.white) // 只有在 iPad/宽屏下才给它加圆角和阴影 // iPhone 上就让它铺满保持扁平 .ifCondition(hClass .regular) { view in view .cornerRadius(
.shadow(radius:
} // 只有在紧凑模式下才加底部分割线 .ifCondition(hClass .compact) { view in view.overlay(Divider(), alignment: .bottom) } } }看逻辑是不是瞬间清晰了你把“什么时候改”和“怎么改”解耦了。
这种写法不仅让代码整洁而且当你以后想修改 iPad 的特定样式时不用在几百行代码里像找地雷一样找那个else分支。
别再用模拟器跑了Xcode Previews 的高阶玩法我敢打赌你调整完一个 Padding然后按下Cmd R盯着模拟器启动画面发呆 10 秒钟这波操作你每天要重复几十次。
这是在浪费生命。
Xcode 15 推出的新版#Preview宏配合Traits特征能让你在一个画布上同时看到 iPhone SE、iPad mini、iPad Pro 横屏的效果。
这不仅仅是这是布局的单元测试。
#Preview(多设备同屏) { // 定义一个变体列表 let devices [ iPhone SE (3rd generation), iPhone 15 Pro Max, iPad Pro (
1
9-inch) ] ForEach(devices, id: \.self) { device in AdaptiveView() .previewDevice(PreviewDevice(rawValue: device)) .previewDisplayName(device) } } #Preview(横竖屏对比, traits: .landscapeLeft) { // 专门测试横屏布局 AdaptiveView() }实战技巧如果你的视图依赖了很多环境数据比如前面的AppState在 Preview 里直接 Mock伪造数据是最快的。
创建一个MockAppState填满假数据直接注入。
这样你根本不需要跑后端接口就能测试当“邮件标题特别长”或者“没有选中任何邮件”时你的 Split View 到底会不会崩。
记住如果你的 Preview 跑不起来或者经常 Crash那说明你的视图代码耦合度太高了。
一个好的自适应视图应该像乐高积木一样给它数据就能独立渲染。
修复 Preview 的过程往往就是重构代码结构的过程。
最后的防线Scroll View 的 contentInsetAdjustmentBehavior把这个放在最后是因为它是 99% 的布局 bug 的罪魁祸首而且极其隐蔽。
当你把一个List或ScrollView放在NavigationView或者TabView里时系统会很贴心地帮你调整内边距contentInset为了不让内容被导航栏挡住。
但在复杂的嵌套布局中比如你在 iPad 上搞了个自定义的侧边栏系统的这份“贴心”往往会变成“多管闲事”。
你会发现列表顶部莫名其妙多出了一块空白或者底部被切掉了一截。
在 UIKit 时代我们有automaticallyAdjustsScrollViewInsets false。
在 SwiftUI 里你需要显式地控制这个行为List { // 内容... } // 告诉系统别碰我的内边距我自己算 .contentMargins(.top, 0, for: .scrollContent) // 或者更暴力的 .ignoresSafeArea(.all, edges: .top)但是更优雅的方案是使用Safe Area Consumption的概念。
如果你在 ScrollView 上面盖了一个半透明的 Header请务必使用.safeAreaInset(edge: .top)来放置这个 Header。
这样 ScrollView 会自动知道“哦上面有个大哥占了 50pt 的位置我得把内容的初始位置往下挪 50pt但滑动的时候内容又要能滑到最顶端去。
”这就是系统级组件的魅力。
尽量用safeAreaInset替代ZStack padding的土办法前者能保留系统级的滚动惯性和避让逻辑后者只是视觉上的堆叠。
台前调度Stage Manager当屏幕不再是屏幕以为搞定了 Split View 就万事大吉了iPadOS 16 扔出的台前调度Stage Manager才是真正的终极 Boss。
在这个模式下你的 App 窗口可以被用户拖拽成任意尺寸——长的、扁的、方的甚至是一些完全不符合常规比例的“奇葩”尺寸。
这时候Size Classes 有时候会失效或者说它的粒度不够细了。
比如用户把你的 App 拖成了一个极窄的竖条但高度却很长。
这时候系统可能告诉你横向是 Compact但纵向有大把空间。
如果你只是简单的把内容塞进ScrollView底部会留出巨大的空白丑得不像话。
这时候我们需要监听环境值的微小变化甚至需要根据长宽比Aspect Ratio来动态决策。
struct StageManagerResistantView: View { var body: some View { GeometryReader { geo in let ratio geo.size.width / geo.size.height if ratio
2 { // 明显的横向窗口采用左右分栏 TwoColumnLayout() } else if ratio
8 { // 明显的竖向窗口采用上下堆叠 VerticalStackLayout() } else { // 接近方形的窗口这是台前调度里最常见的坑爹尺寸 // 这时候既不适合完全横排也不适合完全竖排 // 也许你需要一个九宫格 (Grid) 布局 SquareGridLayout() } } } }切记在台前调度模式下用户调整窗口大小的频率非常高。
如果你的布局计算太重比如在body里做了大量的复杂数学运算或者图片处理窗口拖动时就会掉帧。
性能优化在这里就是用户体验的生命线。
终极核武器Layout Protocol (自定义布局协议)如果 VStack、HStack、LazyVGrid 都满足不了你的变态需求比如你想做一个“根据内容重要性自动调整大小的气泡云图”或者一个“像俄罗斯方块一样自动填补空隙的流式容器”。
在 iOS 16 之前你只能去写难啃的 Core Graphics 或者用 GeometryReader 算坐标算到吐。
现在SwiftUI 给了我们核武器Layout Protocol。
这东西允许你介入布局系统的最底层测量Measure和放置Place。
你可以像上帝一样决定每一个子视图放在哪里。
看一个简单的应用场景自适应标签流Flow Layout。
这在电商 App 的搜索历史、标签筛选里太常见了但原生 SwiftUI 居然一直没有提供虽然 WWDC 23 出了 FlowLayout但理解原理依然重要。
struct SimpleFlowLayout: Layout { func sizeThatFits(proposal: ProposedViewSize, subviews: Subviews, cache: inout ()) - CGSize { // 这里负责计算整个容器需要多大 // 你需要遍历所有 subviews模拟摆放一下算出最后的高度 // 代码稍长核心逻辑是一行放不下就换行 // ... (省略具体算法重点是思维) return calculatedSize } func placeSubviews(in bounds: CGRect, proposal: ProposedViewSize, subviews: Subviews, cache: inout ()) { // 这里负责真正的“落子” // 告诉每一个 subview你去 (x, y)尺寸是 (w, h) var x bounds.minX var y bounds.minY for view in subviews { let size view.sizeThatFits(.unspecified) if x size.width bounds.maxX { // 换行逻辑 x bounds.minX y size.height spacing } view.place(at: CGPoint(x: x, y: y), proposal: ProposedViewSize(size)) x size.width spacing } } }使用起来就像原生组件一样丝滑SimpleFlowLayout { ForEach(tags) { tag in Text(tag.name) .padding(
.background(.blue.opacity(
0.
) .cornerRadius(
} }为什么要提这个因为在自适应布局的高端局里标准组件往往意味着妥协。
当你发现HStack总是把你的卡片挤压变形或者Grid的留白怎么调都不对时手写一个遵循Layout协议的容器往往是唯一的出路。
它能让你针对 iPad 的大屏利用率达到像素级的精准控制。
状态恢复State Restoration别让用户骂街设想一个场景用户在 iPad 上打开你的 App正在填一个很长的表单。
突然他想回个微信切到了后台。
或者他调整了一下分屏大小导致你的 App 进程被系统杀掉重开这在内存吃紧的设备上经常发生。
等他切回来发现表单清空了页面回到了首页。
这是灾难级的用户体验。
完美的自适应不仅是 UI 的适应更是状态的连续性。
iOS 提供了SceneStorage来帮你解决这个痛点。
它就像轻量级的UserDefaults但是专门绑定在当前的“场景Window”上的。
struct ContentView: View { // 即使 App 被杀了下次打开这个特定窗口这个值还在 SceneStorage(selectedTab) var selectedTab: Int 0 SceneStorage(userInputDraft) var draft: String var body: some View { TabView(selection: $selectedTab) { TextField(输入内容, text: $draft) .tabItem { Text(编辑) } .tag(
Text(设置) .tabItem { Text(设置) } .tag(
} } }特别是在NavigationSplitView里你必须保存用户的导航路径。
比如用户点到了“邮件 - 收件箱 - 第三封邮件”你得把这个路径记下来。
不然用户转个屏幕App 重绘了一下突然把用户踢回了邮件列表这种迷失感是毁掉 App 质感的元凶。
动画的哲学用 MatchedGeometryEffect 欺骗眼睛当布局从 iPhone 的单列变成 iPad 的双列时如果只是生硬地“啪”一下变过去那就太 Low 了。
苹果的设计哲学是流畅的形变。
比如在 iPhone 上点击一个歌单封面封面放大成为播放器背景在 iPad 上封面可能只是移到了左下角。
这两个封面其实是两个完全不同的 View但在用户眼里它们应该是同一个物体在移动。
matchedGeometryEffect就是为了这种“视觉欺诈”而生的。
struct MusicPlayerTransition: View { Namespace private var ns State private var isExpanded false var body: some View { VStack { if isExpanded { // 展开状态大图 Image(album_cover) .resizable() .matchedGeometryEffect(id: cover, in: ns) // 绑定ID .frame(width: 300, height:
} else { // 收起状态小图 HStack { Image(album_cover) .resizable() .matchedGeometryEffect(id: cover, in: ns) // 绑定同一个ID .frame(width: 50, height:
Text(正在播放...) } } } .onTapGesture { withAnimation(.spring()) { isExpanded.toggle() } } } }在自适应布局中这招特别好用。
比如横竖屏切换时搜索框从导航栏中间飞到了侧边栏顶部。
只要给它们相同的matchedGeometryEffectID系统就会自动计算插值动画让元素飞过去而不是闪过去。