#SwiftUI #English

远离 dismiss，拥抱状态驱动

发表于

在 SwiftUI 开发中，环境值 dismiss 因其灵活、自适应的特性备受开发者青睐。它能够根据当前视图的上下文智能执行关闭操作：在模态视图中关闭窗口、在导航堆栈中弹出视图，甚至在多列导航容器中自动关闭边栏。正是这种看似“万能”的便捷性，让许多开发者将它作为首选工具。

然而，便捷的背后往往隐藏着风险。频繁使用 dismiss 可能在应用程序中埋下隐患，引发测试难题乃至难以追踪的稳定性问题。本文将分析我们为何应谨慎对待 dismiss，并介绍更加健壮可靠的状态管理方案。通过重新审视视图呈现与消失的逻辑，我们能够打造出更稳定、易维护且可预测的 SwiftUI 应用。

响应式框架中的命令式操作

作为响应式框架，SwiftUI 的核心理念就是通过状态驱动界面变化。开发者通常采用“先更新状态，再由框架自动刷新视图”的编程范式。然而，在实际开发过程中，我们总会遇到一些交互场景难以简单、明确地用状态表达。

为了解决这些特殊的需求，SwiftUI 引入了一系列命令式操作。这些操作通常以环境值的形式注入到视图中，让开发者能在需要时直接调用。其中常见的包括：dismiss、openWindow、openURL、refresh 等。

这些命令式操作灵活且直观，它们能绕过复杂且繁琐的状态传递，提供一种看似更加简单直接的交互方式。

在我最初接触 SwiftUI 时，也深深迷恋上了这些操作。比如，我曾开发过一个名为 SheetKit 的库，让开发者可以通过命令式的方式轻松呈现模态视图：

Swift 
@Environment(\.sheetKit) var sheetKit

Button("show sheet"){
   sheetKit.present{
     Text("Hello world")
   }
}

然而，随着我对 SwiftUI 框架理解的不断深入，以及实际项目复杂性的增加，我逐渐意识到这些“便捷”方式其实潜藏着一些隐患：

  1. 降低视图的可测试性。
  2. 增加后期项目维护的难度。
  3. 可能引入意料之外的“副作用”，导致应用不稳定。

因此，在近几年的开发实践中，除非别无选择，否则我已明显减少了对命令式操作的依赖。这不仅仅是为了提高代码质量，更是为了确保项目在长期开发过程中的稳健性与可维护性。

dismiss，视图中的隐藏陷阱

几天前，我在苹果开发者论坛中偶然看到一个问题：一位开发者描述了一个应用会在特定操作序列后完全卡死的场景。当我查看他的源代码时，赫然发现了那行熟悉的 @Environment(\.dismiss) var dismiss。

直觉告诉我，罪魁祸首很可能就是它。果然，在屏蔽掉这行代码后，应用立刻恢复了正常。而这种现象绝非个案，而是一类普遍且隐蔽的问题。

我之所以能迅速定位这个问题，得益于这几年的开发经验以及来自开发者社区的广泛反馈。在我的 Discord 频道中，类似由 dismiss 引发的异常案例早已积累了不少。它们主要集中表现为以下两种严重后果：

  • CPU 异常占用，甚至可能达到 100% 的资源消耗。

  • 导航容器中的底层视图出现难以预期的刷新或重载行为。

更令人头疼的是，dismiss 导致的问题往往隐蔽且具有不确定性。在一些情境下，它似乎表现正常，但在特定的代码组合、视图层次或者系统版本下，却可能突然引发严重的性能下降乃至稳定性崩溃。

虽然目前尚未完全明确 dismiss 出现问题的根本原因，但我推测，这种不确定性可能与其过于“聪明”的自适应行为密切相关。dismiss 能够根据不同的视图上下文自动切换操作模式，而这种“智能”正是埋下不稳定性的关键因素。

因此，即使你目前尚未遭遇类似的问题，我依然毫不犹豫地建议：谨慎对待 dismiss，优先采用更加明确、可控且状态驱动的管理方案。

将 dismiss 操作从视图中解耦

在 SwiftUI 开发过程中，由于视图的复用与交互场景的复杂性，直接使用环境值中的 dismiss 操作看似便捷，实际却可能让视图状态的管理变得模糊且难以维护。为了规避这些风险，我们应当尽量将 dismiss 的逻辑从视图中解耦。以下介绍三种常用且高效的解耦方案：

通过 Binding 解耦

下面是一个通过 Binding 管理视图呈现状态的典型示例：

Swift 
struct PresentView: View {
  let item: Item
  @Binding var isPresented: Bool
  var body: some View {
    VStack {
      Text(item.id, format: .number)
      Button("Dismiss") {
        isPresented = false
      }
    }
  }
}

Binding 本质上是一对 getter 和 setter 方法的封装。它并非一定要绑定到具体的状态变量，因此我们不需要刻意确保与 dismiss 对应的状态一定为布尔型。例如，我们可以巧妙地将 Optional 状态映射为一个更便于操作的布尔值：

Swift 
struct ParentView: View {
  @State var item: Item?
  var body: some View {
    Button("Pop Sheet") {
      item = Item(id: 123)
    }
    .sheet(item: $item) { item in
      let binding = Binding<Bool>(
        get: { self.item != nil },
        set: {
          if !$0 {
            self.item = nil
          }
        }
      )
      PresentView(item: item, isPresented: binding)
    }
  }
}

为了进一步简化上述转换过程，我们还可以为 Binding 添加一个扩展方法，使代码更清晰易读：

Swift 
extension Binding {
  /// 从一个 Optional 类型的 Binding 创建一个表示“是否为非 nil”的 Bool Binding
  static func isPresent<T: Sendable>(_ binding: Binding<T?>) -> Binding<Bool> {
    Binding<Bool>(
      get: { binding.wrappedValue != nil },
      set: { isPresented in
        if !isPresented {
          binding.wrappedValue = nil
        }
      }
    )
  }
}

// 使用
.sheet(item: $item) { item in
    PresentView(item: item, isPresent: .isPresent($item))
}

通过这种方式，PresentView 就完全摆脱了对具体状态变量的依赖，实现了对 dismiss 操作的彻底解耦，只需简单地将 isPresented 设置为 false 即可。

通过函数解耦

既然上述的 Binding 中 getter 方法在 dismiss 场景中并无实际作用，我们可以更直接地通过函数传递 dismiss 操作，从而使代码更为明确：

Swift 
struct PresentView: View {
  let item: Item
  var dismiss: () -> Void
  var body: some View {
    VStack {
      Text(item.id, format: .number)
      Button("Dismiss") {
        dismiss()
      }
    }
  }
}

struct ParentView: View {
  @State var item: Item?
  var body: some View {
    Button("Pop Sheet") {
      item = Item(id: 123)
    }
    .sheet(item: $item) { item in
      PresentView(item: item, dismiss: { self.item = nil })
    }
  }
}

通过自定义环境值解耦

当 dismiss 操作需要跨越多个视图或层次时，使用自定义的环境值会是更便捷和更优雅的方案。这种方法特别适用于集中管理模态视图的场景：

Swift 
extension EnvironmentValues {
  @Entry var dismissAction: () -> Void = {}
}

struct PresentView: View {
  let item: Item
  @Environment(\.dismissAction) private var dismiss
  var body: some View {
    VStack {
      Text(item.id, format: .number)
      Button("Dismiss") {
        dismiss()
      }
    }
  }
}

struct ParentView: View {
  @State var item: Item?
  var body: some View {
    Button("Pop Sheet") {
      item = Item(id: 123)
    }
    .sheet(item: $item) { item in
      PresentView(item: item)
        .environment(\.dismissAction, { self.item = nil})
    }
  }
}

以上三种解耦方法各有优势，可根据具体的开发场景自由选择。关键是我们要坚持将 dismiss 操作与视图本身的逻辑清晰分离，以提高代码的可读性、可测试性和长期可维护性。

状态优化

在本文发表后，有开发者指出一个潜在的问题：由于视图的 dismiss 操作通常是在父视图的 body 中声明的，因此当模态视图展示之后，父视图的状态发生变化并触发重新计算时，使用 Binding 或环境值注入的展示视图也会跟随父视图一并重新计算，这在某些场景下可能带来性能问题。

如果你恰好遇到了上述问题，并确实对应用性能产生了负面影响，那么可以采用以下方案进行简单有效的优化。

优化 Binding 场景

在使用 Binding 管理 dismiss 的场景中，可以通过让展示视图（如 PresentView）遵循 Equatable 协议，并自定义比较逻辑来避免不必要的重复计算：

例如，扩展 PresentView 以实现选择性状态比较：

Swift 
// 只针对与视图展示相关的状态进行比较
extension PresentView: Equatable {
  nonisolated static func == (lhs: Self, rhs: Self) -> Bool {
    lhs.item == rhs.item
  }
}

关于利用 Equatable 协议优化 SwiftUI 性能的更多细节，可参考文章：避免 SwiftUI 视图的重复计算。

优化 EnvironmentValues 场景

对于采用环境值传递 dismiss 操作的场景，更简单且有效的方法是利用 SwiftUI Environment：理念与实践 一文中介绍的 transformEnvironment 来进行环境值的选择性修改。

首先，将环境值的定义修改为：

Swift 
extension EnvironmentValues {
  @Entry var dismissAction: (() -> Void)? = nil
}

然后在注入环境值时，使用 transformEnvironment 替代原有的 environment 方法：

Swift 
.sheet(item: $item) { item in
  PresentView(item: item)
    .transformEnvironment(\.dismissAction) { dismissAction in
      guard dismissAction == nil else { return }
      dismissAction = { self.item = nil }
    }
}

// 视图内调用 dismiss 操作的方式：
Button("Dismiss") {
  dismiss?()
}

除了上述方法外，我们还可以在父视图中通过 @State 缓存 dismiss 操作，或者将状态与 dismiss 操作抽取到跨视图的 viewModel 中，以进一步减少不必要的视图刷新。

以上优化技巧不仅限于本文提到的 dismiss 场景，也适用于所有直接传递父视图状态或包含父视图状态闭包的情况，能有效避免不必要的视图刷新，提升应用性能。

扩展 dismiss 的应用场景

通过自定义 dismiss 逻辑，我们可以进一步打破原生 dismiss 操作的局限性，从而实现更灵活、更丰富的视图管理策略。

例如，我们可以定义一个枚举类型，代表不同的 dismiss 操作：

Swift 
enum DismissAction {
  case dismiss       // 关闭当前视图
  case dismissAll    // 关闭所有层级的视图
}

extension EnvironmentValues {
  @Entry var dismissAction: (DismissAction) -> Void = { _ in}
}

// 使用举例
.sheet(item: $item) { item in
    PresentView(item: item)
      .environment(\.dismissAction, { _ in
        self.item = nil
      })
 }

通过这种方式，我们不仅可以轻松处理单层模态视图的关闭，还可以扩展到更复杂的视图层级管理：

  • 单一视图的快速关闭

  • 一次性关闭多个堆叠的模态视图

  • 在复杂导航结构中快速返回根视图

这种自定义的 dismiss 机制为 SwiftUI 应用提供了更为细致和可控的导航与交互体验。

总结

虽然 SwiftUI 提供的 dismiss 操作表面上非常便捷，但实际使用中可能会带来严重的稳定性和维护性问题。通过本文的分析，我们可以清晰认识到：

  1. 应该优先采用明确、可控的状态驱动方式；

  2. 应当尽量将 dismiss 操作与视图逻辑解耦；

  3. 选择更具预测性和长期维护性的方案。

开发者应当始终掌握视图状态的明确控制，而非依赖具有魔法色彩但风险极高的自适应操作。这不仅是一种良好的编码习惯，更是构建稳定、可靠 SwiftUI 应用的必经之路。

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

每周精选 Swift 与 SwiftUI 精华！