MVVM架构设计

视图模型与视图的解耦

在MVVM架构中，核心原则是关注点分离。视图（View）的唯一职责是渲染UI并响应用户输入，而所有的业务逻辑、状态管理和数据转换都应封装在视图模型（ViewModel）中。这种解耦使得视图变得“轻量”且高度可复用，因为它不包含任何复杂的逻辑。视图通过绑定到视图模型的@Published属性来被动地接收状态更新，并通过调用视图模型的方法来触发业务逻辑，从而实现了清晰的职责划分。

视图应该只关心“如何展示”，而视图模型则关心“展示什么”以及“如何响应”。

通过这种方式，我们可以独立地修改UI（视图）或业务逻辑（视图模型），而不会相互影响。更重要的是，由于视图模型不依赖于任何具体的UI框架（如SwiftUI或UIKit），我们可以轻松地对其进行单元测试。

// ViewModel: 包含业务逻辑和状态
class UserProfileViewModel: ObservableObject {
    @Published var username: String = ""
    @Published var isLoading: Bool = false

    private let dataService: DataServiceProtocol

    init(dataService: DataServiceProtocol) {
        self.dataService = dataService
    }

    func fetchUser() {
        isLoading = true
        dataService.fetchUserData { [weak self] result in
            DispatchQueue.main.async {
                self?.isLoading = false
                switch result {
                case .success(let user):
                    self?.username = user.name
                case .failure(let error):
                    // 处理错误
                    print(error)
                }
            }
        }
    }
}

// View: 仅负责UI展示和用户交互
struct UserProfileView: View {
    @StateObject private var viewModel: UserProfileViewModel

    init(viewModel: UserProfileViewModel) {
        _viewModel = StateObject(wrappedValue: viewModel)
    }

    var body: some View {
        VStack {
            if viewModel.isLoading {
                ProgressView()
            } else {
                Text("Username: \(viewModel.username)")
            }
            Button("Refresh") {
                viewModel.fetchUser()
            }
        }
        .onAppear {
            viewModel.fetchUser()
        }
    }
}

单向数据流管理

为了确保应用状态的可预测性和一致性，MVVM架构强制实行单向数据流。数据从模型（Model）层流向视图模型（ViewModel），再由视图模型传递给视图（View）进行渲染。用户在视图上的操作会触发视图模型中的方法，这些方法可能会更新模型，从而启动新一轮的数据流动。这个循环是封闭且可预测的。

这种模式避免了状态在应用中随意传播和修改所导致的混乱。当出现问题时，我们可以更容易地追踪数据的来源和变化路径，从而快速定位和修复bug。

依赖注入

为了实现真正的解耦和可测试性，依赖注入（Dependency Injection, DI）是必不可少的。视图模型不应该自己创建它所依赖的服务（例如网络请求、数据库访问等），而应该通过外部注入这些依赖。最常见的方式是通过构造函数注入。

通过为服务定义协议（Protocol），我们可以注入真实的实现用于生产环境，同时注入模拟的（Mock）实现用于单元测试。这使得测试视图模型的逻辑变得非常简单，因为它不再依赖于真实的网络或数据库，测试过程也因此变得快速和可靠。

// 1. 定义服务协议
protocol DataServiceProtocol {
    func fetchUserData(completion: @escaping (Result<User, Error>) -> Void)
}

// 2. 生产环境的服务实现
class NetworkService: DataServiceProtocol {
    func fetchUserData(completion: @escaping (Result<User, Error>) -> Void) {
        // ... 真实的URLSession网络请求
    }
}

// 3. 在ViewModel的构造函数中注入依赖
class UserProfileViewModel: ObservableObject {
    private let dataService: DataServiceProtocol

    init(dataService: DataServiceProtocol) {
        self.dataService = dataService
    }
    
    // ...
}

// 4. 在测试中注入Mock服务
class MockDataService: DataServiceProtocol {
    func fetchUserData(completion: @escaping (Result<User, Error>) -> Void) {
        // 返回预设的成功或失败结果
        let mockUser = User(name: "Mock User")
        completion(.success(mockUser))
    }
}

// 测试代码
func testFetchUserSucceeds() {
    let mockService = MockDataService()
    let viewModel = UserProfileViewModel(dataService: mockService)

    viewModel.fetchUser()

    // 断言viewModel的状态是否按预期更新
    XCTAssertEqual(viewModel.username, "Mock User")
}

性能优化与测试

在复杂的UI场景中，性能优化至关重要。SwiftUI的视图渲染机制是基于状态变化的，不必要的@Published属性更新会导致整个视图树的重绘，从而影响性能。一个关键的优化策略是确保只有在真正需要时才发布状态变更。例如，将仅用于内部计算的属性与驱动UI更新的属性分开。

此外，合理使用@StateObject和@ObservedObject也至关重要。@StateObject确保视图模型的生命周期与持有它的视图绑定，防止在视图重绘时被意外重新创建，这对于根视图或需要持久状态的场景是正确的选择。

优化渲染的关键在于最小化状态变更的范围和频率。一个庞大的、频繁更新的视图模型是性能瓶颈的主要来源。

对于测试，MVVM的优势显而易见。由于视图模型是普通的Swift类，不含UI代码，我们可以使用XCTest框架对其进行全面的单元测试。测试应覆盖所有业务逻辑分支、数据转换的正确性以及状态是否按预期更新。

对于视图本身的测试，虽然较为复杂，但我们可以采用快照测试（Snapshot Testing）来验证UI在不同状态下的视觉表现是否正确。不过，核心逻辑的稳定性和可靠性主要通过对视图模型的单元测试来保证。

Quiz Questions 1/5

在MVVM架构中，视图（View）的主要职责是什么？

Quiz Questions 2/5

MVVM架构强制实行单向数据流，以确保应用状态的可预测性和一致性。

通过解耦、管理数据流、注入依赖以及优化，MVVM为构建健壮、可维护的SwiftUI应用提供了坚实的架构基础。

SwiftUI高级分层架构实战