Swift Composable Architecture 中模态视图切换的常见问题与解决方案

问题现象

在使用 Swift Composable Architecture (TCA) 开发 iOS 应用时，开发者可能会遇到一个典型的视图控制器切换问题：当尝试在关闭一个模态视图后立即展示另一个模态视图时，有时会出现意外的行为——整个视图层级都被意外关闭。

具体表现为：

1. 在根视图控制器上展示 A 视图控制器
2. 在 A 视图控制器上展示 B 视图控制器
3. 关闭 B 视图控制器后立即尝试在 A 视图控制器上展示 C 视图控制器

问题本质

这个问题的根源在于 UIKit 的视图控制器展示机制。当快速连续执行 dismiss 和 present 操作时，UIKit 可能无法正确处理这些动画的时序。这不是 TCA 特有的问题，而是 UIKit 本身的限制。

技术分析

在 TCA 中，我们通常使用 present 修饰器来管理视图控制器的展示状态。问题通常出现在以下场景：

// 在 A 视图控制器中同时监听两个可能的展示状态
present(item: $store.scope(state: \.destination?.bFeature, action: \.destination.bFeature)) { store in
    BViewController(store: store)
}

present(item: $store.scope(state: \.destination?.cFeature, action: \.destination.cFeature)) { store in
    CViewController(store: store)
}

当状态从 B 快速切换到 C 时，UIKit 的动画系统可能还没有完成 B 的 dismiss 动画，就收到了展示 C 的指令，导致系统混乱。

解决方案

方案一：引入延迟

最简单的解决方案是在关闭一个视图控制器后，延迟一小段时间再展示下一个：

case .destination(.presented(.bFeature(.delegate(.closeAndShowC)))):
    return .run { send in
        await send(.set(\.$destination, nil))  // 先清空当前展示状态
        try await Task.sleep(for: .milliseconds(500))  // 等待500毫秒
        await send(.showC))  // 再展示新的视图控制器
    }

虽然这种方法有效，但依赖于人为设定的延迟时间，不够优雅。

方案二：统一展示逻辑

更优雅的解决方案是重构展示逻辑，使用单个 present 方法，通过 switch 语句处理不同的展示状态：

present(item: $store.scope(state: \.destination, action: \.destination)) { destination in
    switch destination {
    case .bFeature:
        BViewController(store: store)
    case .cFeature:
        CViewController(store: store)
    }
}

这种方法避免了多个 present 修饰器之间的竞争，确保视图控制器的展示和关闭操作有序进行。

方案三：使用 UIKit 完成回调

对于更复杂的场景，可以考虑利用 UIKit 的 completion handler 机制：

// 在关闭 B 时传入完成回调
dismiss(animated: true) {
    // 在关闭完成后再展示 C
    store.send(.showC)
}

这种方法需要更深入地介入 UIKit 的视图控制器生命周期管理。

最佳实践建议

1. 避免快速连续的视图控制器切换：在状态管理中考虑动画完成时间
2. 统一管理展示逻辑：尽量使用单个 present 修饰器处理所有可能的展示状态
3. 考虑使用 SwiftUI 替代：如果项目允许，使用 SwiftUI 的 sheet 和 fullScreenCover 修饰器可以避免这类问题
4. 充分测试：这类时序问题在不同设备和系统版本上表现可能不同，需要充分测试

总结

在 TCA 中使用 UIKit 视图控制器时，开发者需要注意 UIKit 本身的限制。通过合理的状态管理和展示逻辑设计，可以避免这类视图控制器切换时的问题。理解底层机制并选择适合项目需求的解决方案是关键。