随着SwiftUI的采用，创建全局范围内状态的新趋势正在形成。这是非常合理的，因为它是为数不多的正确处理深度链接、HUDs等的方法之一。
在本文中，让我们看看这种方法，以及如何避免其使用弊端。
App
我们将构建一个只有两个tabs的小应用:home和settings 两个tab。
我们将以
TabView为例，但同样的方法也可以用于导航、表、所有其他SwiftUI视图演示等等。
simple.gif
struct ContentView: View {
var body: some View {
TabView {
HomeView()
.tabItem { Label("Home", systemImage: "house.fill") }
SettingsView()
.tabItem { Label("Settings", systemImage: "gear") }
}
}
}
struct HomeView: View {
var body: some View {
Text("Home")
}
}
struct SettingsView: View {
var body: some View {
Text("Settings")
}
}
这里我们已经声明了一个TabView和两个视图，HomeView和SettingsView，每个视图都有一个相关的Text文本。
控制tab的选择
我们的应用要求以编程方式选择活动标签:例如，我们希望有一个快捷方式让用户从Home页跳转到Settings标签，或者我们希望切换标签作为深度链接的响应，等等。
我们需要自己管理TabView状态，这可以通过TabView初始化器来Binding参数实现。
goto.gif
enum Tab: Hashable {
case home
case settings
}
struct ContentView: View {
@State private var selectedTab: Tab = .home
var body: some View {
TabView(selection: $selectedTab) {
HomeView(selectedTab: $selectedTab)
.tabItem { Label("Home", systemImage: "house.fill") }
.tag(Tab.home)
SettingsView()
.tabItem { Label("Settings", systemImage: "gear") }
.tag(Tab.settings)
}
}
}
struct HomeView: View {
@Binding var selectedTab: Tab
var body: some View {
VStack {
Button("go to settings") {
selectedTab = .settings
}
Text("Home")
.onAppear(perform: { print("home on appear")})
}
}
}
struct SettingsView: View {
... // same as before
}
这次我们更新了如下内容：
- 声明了一个带有所有可能
TabView状态的Tab枚举 - 为
ContentView添加了selectedTab属性，用于控制TabView的状态 - 在
Home页添加了一个按钮可以让我们跳转到Setting选项
虽然这已经实现了需求，它让我们可以通过编程方式改变标签状态，但我们仍然需要直接访问ContentView的selectedTab属性，然后才能改变标签栏状态。
更重要的是，随着应用的发展，将tab状态从一个视图传递到另一个视图是不现实的,因此我们需要将状态移出TabView，并通过应用范围内的状态将它放到环境中。
App全局状态
目前的限制是TabView的状态可访问性，我们可以通过创建一个全局状态并在环境中设置它来克服这个挑战:
class AppWideState: ObservableObject {
@Published var selectedTab: Tab = .home
}
AppWideState只保存选项卡状态，并在selectedTab即将更改时发送一个新的发布事件。
我们希望这个状态在任何地方都可以访问，我们将把它附加到我们的主App，然后把它注入到环境中:
@main
struct FiveStarsApp: App {
@StateObject var appWideState = AppWideState()
var body: some Scene {
WindowGroup {
ContentView()
.environmentObject(appWideState) // injected in the environment
}
}
}
一切就绪，让我们更新我们的视图来使用用这个新状态:
struct ContentView: View {
@EnvironmentObject var state: AppWideState // environment object
var body: some View {
TabView(selection: $state.selectedTab) { // state from the environment object
HomeView()
.tabItem { Label("Home", systemImage: "house.fill") }
.tag(Tab.home)
SettingsView()
.tabItem { Label("Settings", systemImage: "gear") }
.tag(Tab.settings)
}
}
}
struct HomeView: View {
@EnvironmentObject var state: AppWideState // environment object
var body: some View {
VStack {
Button("go to settings") {
state.selectedTab = .settings // sets the state from the environment object
}
Text("Home")
}
}
}
struct SettingsView: View {
... // same as before
}
HomeView仍然可以使用@Binding
这个新结构的工作方式和之前完全一样，但是我们现在可以从主应用和环境到达的任何地方更改所选的标签。
几周后
几周过去了，我们的AppWideState获得了一些新的@Published属性，更多的视图观察到这个对象，我们的应用程序开始变慢:每次我们改变全局状态，我们会注意到在更改选项卡或新导航被推送之前有轻微的延迟，等等。
我们可以通过我们的例子来研究这个谜团。让我们在我们的HomeView中添加一个小的副作用，一个打印语句告诉我们HomeView主体什么时候执行:
struct HomeView: View {
@EnvironmentObject var state: AppWideState
var body: some View {
let _ = print("HomeView body") // side effect
VStack {
Button("go to settings") {
state.selectedTab = .settings
}
Text("Home")
}
}
}
我们可以再次运行应用程序,我们会注意到,每次我们改变标签(点击标签栏或go to settings按钮)HomeView的body重新计算:这是真的,尽管HomeView没有真正的读取这个状态而只是设置了它。
print.gif
如果我们删除了按钮操作，那么@EnvironmentObject状态根本就不需要做任何事情，这种情况仍然会发生
struct HomeView: View {
@EnvironmentObject var state: AppWideState
var body: some View {
let _ = print("HomeView body") // side effect
VStack {
Button("go to settings") {
// does nothing
}
Text("Home")
}
}
}
print.gif
现在让我们想象一下:
- 我们有一个导航堆栈(或多个导航堆栈)
- 堆栈中的一些界面使用我们的AppWideState环境对象
- 用户在堆栈的多个层次深处
我们对AppWideState所做的每一个改变都将为观察AppWideState的所有视图触发一个新的body渲染评估，而不仅仅是用户当前正在查看的最后一个视图。
现在很容易解释为什么应用程序变得越来越慢:我们使用和扩展AppWideState越多，更多的视图会在每次更改时重新渲染它们的body。
这个陷阱其实是意料之中的，因为EnvironmentObject只是我们的视图订阅的另一个ObservableObject实例，SwiftUI正在做它一直承诺要做的事情:自动订阅和对状态变化做出反应。
解决方案
虽然大多数视图可能需要通过AppWideState来设置它，但实际上很少需要观察它的状态:以tabbar状态为例，只有TabView需要观察它，所有其他视图只需要改变它。
要做到这一点，一种方法是创建一个包含全应用范围状态的容器，容器本身不发布任何东西:
class AppStateContainer: ObservableObject {
...
}
不同于将每个状态声明为该容器的@Published属性，每个状态都将嵌套到自己的ObservableObject中，然后ObservableObject将成为容器的一部分:
class TabViewState: ObservableObject {
@Published var selectedTab: Tab = .home
}
class AppStateContainer: ObservableObject {
var tabViewState = TabViewState()
}
容器符合ObservableObject，因为它是环境对象的需求，但是它不发布任何东西，同时我们把selectedTab状态移动到它自己的TabViewState。
这种方法还将每个应用程序状态隔离到它自己的“迷你容器”中(上面的TabViewState)，因此我们可以将每个特定状态的所有逻辑(如果有的话)集中到它自己的类中，而不是将其共享在一个大类中。
有了这些，我们现在可以把AppStateContainer和TabViewState设置到环境中了:
@main
struct FiveStarsApp: App {
@StateObject var appStateContainer = AppStateContainer()
var body: some Scene {
WindowGroup {
ContentView()
.environmentObject(appStateContainer)
.environmentObject(appStateContainer.tabViewState)
}
}
}
需要观察状态变化的视图将直接观察TabViewState，而只需要改变状态的视图将直接作用于容器:
struct ContentView: View {
@EnvironmentObject var state: TabViewState
var body: some View {
TabView(selection: $state.selectedTab) {
HomeView()
.tabItem {
Label("Home", systemImage: "house.fill")
}
.tag(Tab.home)
SettingsView()
.tabItem {
Label("Settings", systemImage: "gear")
}
.tag(Tab.settings)
}
}
}
struct HomeView: View {
@EnvironmentObject var container: AppStateContainer
var body: some View {
let _ = print("Home body")
VStack {
Button("go to settings") {
container.tabViewState.selectedTab = .settings
}
Text("Home")
.onAppear(perform: { print("home on appear")})
}
}
}
有了这个改变，我们的应用性能又回来了，没有多余的视图body计算。
在这个例子中，我们让HomeView直接访问AppStateContainer并改变TabView状态本身，然而，我们也可以在容器上添加一些方便的API来让这变得更简单.
网友评论