Swift-Navigation项目中present函数与自定义转场代理的注意事项

在Swift-Navigation项目中使用UIKit的present()方法时，开发者可能会遇到一个有趣的现象：当结合自定义转场代理使用时，系统可能会意外地同时关闭多个视图控制器，而非仅关闭目标视图控制器。本文将深入分析这一现象的原因，并提供最佳实践建议。

问题现象分析

当开发者采用以下代码结构时，可能会遇到多视图控制器被同时关闭的问题：

let presentedVC = AnotherViewController()
presentedVC.modalPresentationStyle = .custom
presentedVC.transitioningDelegate = customViewControllerTransitioningDelegate

present(isPresented: $viewModel.isSheetDisplayed) {
  presentedVC
}

有趣的是，这个问题最初被认为与自定义转场代理有关，但进一步测试表明，即使不使用自定义转场代理，同样的问题也会出现。

根本原因探究

问题的核心在于视图控制器的生命周期管理。当视图控制器在present闭包外部创建时，可能会导致以下问题：

1. 内存管理问题：外部创建的视图控制器可能被意外保留，导致系统无法正确管理其生命周期
2. 状态不一致：SwiftUI的声明式范式与UIKit的命令式操作之间可能存在协调问题
3. 闭包捕获语义：外部变量被闭包捕获可能导致意外的副作用

解决方案与最佳实践

Swift-Navigation项目的维护者推荐采用以下模式：

present(isPresented: $viewModel.isSheetDisplayed) { [weak self] in
  guard let self else { return UIViewController() }
  let presentedVC = ViewControllerB()
  presentedVC.modalPresentationStyle = .custom
  presentedVC.transitioningDelegate = viewControllerTransitioningDelegate
  return presentedVC
}

这种模式具有以下优势：

1. 内存安全：使用[weak self]避免循环引用
2. 生命周期控制：视图控制器在闭包内部创建，生命周期由系统正确管理
3. 与SwiftUI风格一致：类似于SwiftUI中视图构建的模式

技术原理深入

这种推荐做法背后的技术原理包括：

1. 闭包执行时机：present闭包在需要显示视图控制器时才会执行，确保每次都是新的实例
2. 自动内存管理：系统可以正确地在视图控制器不再需要时释放资源
3. 状态一致性：避免了因提前创建视图控制器可能导致的状态不一致问题

总结

在使用Swift-Navigation项目进行视图控制器呈现时，开发者应当遵循以下原则：

1. 始终在present闭包内部创建要呈现的视图控制器
2. 使用弱引用捕获可能需要的上下文
3. 保持与SwiftUI类似的声明式风格

这种做法不仅能解决多视图控制器意外关闭的问题，还能提高代码的可维护性和内存安全性。理解这一现象背后的原理，有助于开发者在混合使用UIKit和SwiftUI时做出更明智的架构决策。