从UIKit到SwiftUI的迁移感悟：数据驱动的革命

StarkCoder
0 阅读5分钟

前言

作为一名iOS开发者，我最近完成了一个项目从UIKit到SwiftUI的迁移。这个过程不仅仅是代码的重写，更是一种开发思维的转变。今天，我想分享一下这段旅程中的感悟和具体实践，希望能给正在考虑或正在进行类似迁移的开发者一些参考。

设计哲学的根本差异

UIKit：命令式的"导演"

在UIKit的世界里，我们是"导演"，需要明确地告诉每一个UI元素如何表现：

  • 创建视图：let button = UIButton(type: .system)
  • 设置属性：button.setTitle("点击我", for: .normal)
  • 添加到父视图：view.addSubview(button)
  • 布局约束：button.translatesAutoresizingMaskIntoConstraints = false
  • 响应事件：button.addTarget(self, action: #selector(buttonTapped), for: .touchUpInside)

每一步都需要我们显式地发出指令，控制UI的每一个细节。这就像是在指挥一场盛大的演出，每一个演员的动作都需要我们亲自指导。

SwiftUI：声明式的"编剧"

而在SwiftUI的世界里，我们更像是"编剧"，只需要描述UI应该是什么样子：

Button("点击我") {
    // 点击事件处理
}
.padding()
.background(Color.blue)
.foregroundColor(.white)
.cornerRadius(8)

我们不再关心视图是如何创建和布局的，只需要声明它的最终状态。SwiftUI会自动处理所有的底层实现，包括视图的创建、更新和销毁。

从命令驱动到数据驱动

最核心的转变是从"命令驱动"到"数据驱动"。在UIKit中，我们通过调用方法来改变UI状态；而在SwiftUI中，我们只需要修改数据，UI会自动响应数据的变化。

SwiftUI的属性包装器：新手友好指南

在深入具体案例之前，我想先介绍一下SwiftUI的属性包装器，这是理解SwiftUI数据流的关键。以下是项目中实际使用的属性包装器示例：

@State：管理视图内部状态

@State是最基础的属性包装器，用于管理视图内部的状态：

@State private var isToggleOn = false

var body: some View {
    Toggle("开关", isOn: $isToggleOn)
}

当isToggleOn的值改变时，使用它的视图会自动重新渲染。

@Published：发布者属性

@Published用于标记ObservableObject中的属性，当属性值改变时，会通知所有订阅它的视图。在项目中，我们在多个管理器中使用了@Published：

// AppState.swift
final class AppState: ObservableObject {
    static let shared = AppState()
    
    /// 是否需要重置应用
    @Published var resetApp = false
    
    // 其他代码...
}

// GlobalOverlayManager.swift
final class GlobalOverlayManager: ObservableObject {
    static let shared = GlobalOverlayManager()
    
    /// 当前显示的弹框类型
    @Published var current: OverlayType?
    
    // 其他代码...
}

// Router.swift
class Router: ObservableObject {
    
    // 当前选中的Tab
    @Published var selectedTab: MainTab = .home
    
    // 为每个tab单独存储NavigationPath
    @Published var homePath = NavigationPath()
    @Published var hotPath = NavigationPath()
    // 其他代码...
}

@StateObject：持久化的观察对象

@StateObject与@ObservedObject类似，但它会在视图的整个生命周期中保持对象的存在，不会因为视图的重新渲染而创建新的实例。在项目中，我们在App入口和视图中使用了@StateObject：

// EviApp.swift
@main
struct EviApp: App {
    // 应用状态管理器
    @StateObject private var appState = AppState.shared
    // 全局弹框管理器
    @StateObject private var overlay = GlobalOverlayManager.shared
    // 全局导航路由器
    @StateObject private var router = Router()
    
    // 其他代码...
}

// MainContainerView.swift
struct MainContainerView: View {
    @StateObject private var appConfigManager = AppConfigManager.shared
    
    // 其他代码...
}

@EnvironmentObject：全局共享对象

@EnvironmentObject用于在整个应用中共享数据，避免了层层传递数据的麻烦。在项目中，我们通过environmentObject方法注入全局对象，并在视图中使用@EnvironmentObject来访问：

// EviApp.swift
var body: some Scene {
    WindowGroup {
        MainContainerView()
            .environmentObject(router)
            .environmentObject(overlay)
            // 其他代码...
    }
}

// MainContainerView.swift
struct MainContainerView: View {
    @EnvironmentObject private var overlay: GlobalOverlayManager
    @EnvironmentObject private var router: Router
    
    // 其他代码...
}

迁移具体案例

1. 遮罩实现：从控制器弹出到ZStack

UIKit实现方式

在UIKit中，我们通常会创建一个遮罩视图，然后通过控制器的present方法将其显示在顶层：

let overlayViewController = OverlayViewController()
overlayViewController.modalPresentationStyle = .overFullScreen
overlayViewController.modalTransitionStyle = .crossDissolve
present(overlayViewController, animated: true, completion: nil)

SwiftUI实现方式

在SwiftUI中，我们使用ZStack来实现遮罩效果，更加简洁和声明式。以下是项目中实际的实现：

ZStack {
    // 真正负责页面生命周期的容器
    TabView(selection: $router.selectedTab) {
        tabView(.home)
        tabView(.hot)
        tabView(.creation)
        tabView(.style)
        tabView(.profile)
    }
    
    // 你的悬浮TabBar，根据当前选中标签的导航路径长度控制显示
    if isTabBarVisible {
        VStack {
            Spacer()
            FloatingTabBar(selectedTab: $router.selectedTab)
                .padding(.horizontal, 16)
                .padding(.bottom, 20)
        }
    }
    
    // 全局弹框显示
    if let current = overlay.current {
        
        // 遮罩
        Color.black.opacity(0.4)
            .ignoresSafeArea()
            .onTapGesture {
                overlay.dismiss()
            }
        
        switch current {
        case .login:
            LoginOverlayView(onClose: {
                overlay.dismiss()
            })
            .transition(.flipFromBottom)
        }
    }
}
.animation(.easeInOut(duration: 0.25), value: overlay.current)

这种方式的好处是：

  • 代码更加清晰，遮罩和内容在同一个视图层次结构中
  • 可以使用SwiftUI的动画系统，实现更流畅的过渡效果
  • 不需要管理控制器的生命周期

2. 重置App：从UIWindow重置到AppState管理

UIKit实现方式

在UIKit中，重置App通常需要通过重新设置UIWindow的根视图控制器来实现：

let window = UIApplication.shared.windows.first
window?.rootViewController = UINavigationController(rootViewController: LoginViewController())
window?.makeKeyAndVisible()

SwiftUI实现方式

在SwiftUI中，我们使用AppState来管理应用的重置状态，通过数据驱动UI的变化。以下是项目中实际的实现：

// AppState.swift
final class AppState: ObservableObject {
    static let shared = AppState()
    
    /// 是否需要重置应用
    @Published var resetApp = false
    
    private init() {}
    
    /// 触发应用重置
    func triggerReset() {
        resetApp = true
    }
    
    /// 完成重置，重置标志
    func completeReset() {
        resetApp = false
    }
}

// 在App入口处使用
@main
struct EviApp: App {
    // 把 AppDelegate 接进来，系统会照常调用 didFinishLaunchingWithOptions 等
    @UIApplicationDelegateAdaptor(AppDelegate.self) var appDelegate

    // 应用状态管理器
    @StateObject private var appState = AppState.shared
    // 全局弹框管理器
    @StateObject private var overlay = GlobalOverlayManager.shared
    // 全局导航路由器
    @StateObject private var router = Router()

    var body: some Scene {
        WindowGroup {
            MainContainerView()
                .environmentObject(router)
                .environmentObject(overlay)
                .onChange(of: appState.resetApp) {
                    if appState.resetApp {
                        // 当需要重置时，调用 Router 的 reset 方法重置状态
                        router.reset()
                        // 重置完成后，重置标志，避免无限循环
                        appState.completeReset()
                    }
                }
        }
    }
}

这种方式的好处是：

  • 逻辑更加清晰，通过状态来控制UI的显示
  • 不需要直接操作UIWindow，更加符合SwiftUI的设计理念
  • 可以在任何地方通过AppState.shared.triggerReset()来触发重置

3. 路由管理：从控制器弹出到Router类控制

UIKit实现方式

在UIKit中，我们通常直接使用控制器的push或present方法来导航：

let detailViewController = DetailViewController()
navigationController?.pushViewController(detailViewController, animated: true)

SwiftUI实现方式

在SwiftUI中，我们使用Router类来管理所有标签页的导航路径，实现了标签页间的独立导航和状态保持。详细的实现代码和设计思路可以参考我之前的文章：SwiftUI路由管理架构揭秘：从混乱到优雅的蜕变

这种方式的好处是：

  • 集中管理所有的导航逻辑，更加清晰
  • 可以在任何地方通过Router来控制导航，不需要直接操作视图
  • 支持复杂的导航场景，如深链接

迁移过程中的挑战与收获

挑战

  1. 思维方式的转变：从命令式到声明式，需要一段时间适应
  2. API的差异：许多UIKit的API在SwiftUI中没有直接对应
  3. 第三方库的兼容性：一些UIKit的第三方库可能还没有SwiftUI版本

收获

  1. 代码量减少：SwiftUI的声明式语法大大减少了代码量
  2. 开发效率提高：不需要手动管理视图的创建和更新，开发速度更快
  3. 动画效果更简单：SwiftUI的动画系统非常强大，实现复杂动画变得容易
  4. 预览功能：SwiftUI的预览功能可以实时查看UI效果，提高开发效率

总结

从UIKit到SwiftUI的迁移，不仅仅是技术栈的变化，更是一种开发思维的转变。SwiftUI的声明式和数据驱动的设计理念，让我们能够更加专注于UI的外观和用户体验，而不是底层的实现细节。

虽然迁移过程中会遇到一些挑战，但当你习惯了SwiftUI的开发方式后，你会发现它给你带来的便利和效率提升是值得的。

最后，我想说：SwiftUI是iOS开发的未来，拥抱变化，享受数据驱动的革命吧！

avatar
文章
阅读
粉丝