为 Liquid Glass 设计清晰的 SwiftUI 工具栏层级
Liquid Glass 在 WWDC25 之后很容易被理解成一种可四处添加的新材质,但工具栏设计首先是信息架构问题。Xcode 26 与 iOS 26 测试周期中的具体效果和 API 都要在正式 SDK 发布时复核。更值得先确定的是操作层级:用户在当前页面最常完成什么,哪些操作可以收进菜单,哪些状态必须持续可见。
先让系统组件完成迁移
用 Xcode 26 构建后,标准导航栏、标签栏、工具栏和控件会自动采用大量新设计。第一步应删除旧时代为系统栏叠加的自定义背景、阴影和分隔线,再观察内容与控件是否已经形成清楚层次。如果直接在旧装饰之上继续加 glass,常见结果是双重材质、过度模糊和重复圆角。
struct DocumentScreen: View {
var body: some View {
NavigationStack {
DocumentContent()
.navigationTitle("Draft")
.toolbar {
ToolbarItem(placement: .primaryAction) {
Button("Share", systemImage: "square.and.arrow.up") {
share()
}
}
ToolbarItem(placement: .secondaryAction) {
Button("Duplicate", action: duplicate)
}
}
}
}
}
优先使用语义 placement,而不是用多个 spacer 和固定宽度模拟位置。系统才能根据平台、尺寸、语言和输入方式安排控件。测试版中的实际布局仍可能变化,因此不要依赖某个 seed 的像素坐标编写 UI 测试。
一个区域只保留一个主动作
把保存、分享、添加、完成和更多都做成同样醒目的独立按钮,会让玻璃材料失去指向性。先给任务排序:当前页面的主要完成动作保留为直接入口;低频、破坏性或需要解释的操作进入次级菜单;状态切换需要清楚表达当前值,而不是只靠颜色。
危险操作不应和高频主动作贴得太近。删除放进菜单并不代表可以省略确认或撤销。图标也不能仅凭团队熟悉度决定:含义不明确时使用 Label,让系统在空间允许时显示文字,并为 VoiceOver 提供稳定名称。
让内容穿过,别让内容消失
Glass 的透明和动态取样让控件与滚动内容产生连续感,但背景越复杂,文字和符号越需要验证。至少测试浅色、深色、照片、高对比文本、快速滚动以及键盘出现后的状态。开启 Increase Contrast 与 Reduce Transparency 后,层级仍要成立;开启 Reduce Motion 后,栏位收缩、展开或变形不能成为理解操作位置的唯一线索。
不要用品牌色大面积染整块工具栏。颜色适合表达少量强调或状态,但必须同时提供形状、文字或图标差异。自定义 glass 效果更适合独立的浮动控件,而不是给每个系统按钮再包一层材质。相邻自定义控件若需要共同变形,可以在小范围容器里组织,同时保持稳定身份。
把滚动行为作为状态设计
工具栏可能随着滚动改变尺寸或显著程度。页面顶部、内容中段、搜索激活、编辑模式和模态展示时,都要问同一个问题:主动作是否仍能找到,返回路径是否稳定,标题变化是否会造成跳动?如果按钮随滚动消失,应有可预测的重新出现方式;如果操作仅在选中项目后有效,禁用状态和选择数量都应被辅助技术读出。
布局还要覆盖长语言和大字体。英文短词换成德文或中文无碍,不代表其他本地化也适合固定宽度。把按钮强行压成只有图标通常只是把布局问题转成理解问题。让系统决定标签呈现,并在超大辅助字体下检查工具栏是否转移操作或允许内容滚动。
用结构而非截图做测试
测试版视觉细节会变化,像素快照会产生大量无意义差异。更稳定的检查包括:主动作存在且可点击,菜单项目分组正确,危险操作需要确认,焦点顺序合理,旧系统分支仍可工作。视觉回归测试可以保留,但应覆盖少量关键状态,并在每个 Xcode beta 更新后由人工判断变化来自系统还是应用。
性能也要在真机上观察。滚动内容之上的多个自定义模糊层和持续动画可能带来帧率与能耗成本。先采用标准栏位,再用 Instruments 检查确有问题的页面;不要仅凭模拟器顺滑就宣称没有成本。
结论
清晰的 Liquid Glass 工具栏来自克制:系统组件优先、一个主动作、低频操作分组、状态不只靠颜色、无障碍设置下仍保留层级。测试期把自定义效果封装并保留旧系统路径,正式 SDK 到来时便只需调整少数边界,而不是重新整理所有页面的操作结构。