利用Kotlin或Android技术来开发可扩展的iOS应用程序，并使用SwiftUI进行界面设计

sealed interface UiState〈out T〉 {
　   data object Loading : UiState〈Nothing〉()
　   data class Success〈T〉(val data: T) : UiState〈T〉()
　   data class Error(val message: String) : UiState〈Nothing〉()
}

val workouts: StateFlow〈UiState〈List〈Workout〉〉>> = ...

状态是由一个唯一的、权威的定义来源来确定的。其类型确保了所有可能的状态都是互斥的，编译器也会强制遵守这一规则。因此，同时处于Loading和Success这两种状态是不可能的。

在Swift中，实现方式也非常直接：

enum Loadable〈T, U〉 {
　   case loading
　   case finished(T)
　   case error(U)
}

class DashboardViewModel: ObservableObject {
　   @Published var workouts: Loadable〈[Workout〕〉 = .loading
}

解决数据变更问题：单一的入口点

明确的状态定义可以避免出现矛盾的状态，但那么对于那些需要被多次修改的数据来说，该如何处理呢？Kotlin的解决方案是让所有的数据变更操作都通过一个统一的入口点来进行：

fun onAction(action: DashboardAction) {
    when (action) {
        is DashboardActionRefresh -> loadWorkouts()
        is DashboardAction.SelectWorkout -> selectWorkout(action.id)
        is DashboardAction.Delete -> deleteWorkout(action.id)
    }
}

所有的数据变更操作都必须通过onAction()这个方法来进行，没有任何例外。

让我们单独看一下DashboardAction这个类：

sealed class DashboardAction {
    object Refresh : DashboardAction()
    data class SelectWorkout(val id: String) : DashboardAction()
    data class Delete(val id: String) : DashboardAction()
    data class FilterBy(val type: WorkoutType) : DashboardAction()
}

这个类列出了ViewModel中所有的操作类型。新来的工程师只需要打开这个文件，阅读相关代码，就能立即了解这个ViewModel的功能。根本不需要花费时间去浏览那些六百行的代码，也不需要去猜测哪些方法是公共的、哪些是仅在内部使用的。

密封类实际上就相当于一份契约。如果某个操作没有在密封类中明确声明，ViewModel就无法执行该操作。这种设计机制也会迫使你认真思考ViewModel应该承担哪些职责。每当添加新的操作时，都必须首先将其加入密封类中——这是一个经过深思熟虑的决定，而不是随便在文件中的某个地方添加一个方法而已。

但是，DashboardAction这个类里到底应该包含哪些内容呢？如果某个操作可以被视图触发，那么就应该将其声明为一种操作。比如，用户是点击来删除某项内容，还是选择某项内容？而一些内部辅助方法，比如loadWorkouts()，则只能在perform()方法内部被调用——它属于私有方法，并不属于操作类。真正的操作应该是.refresh这种方法，其内部实现细节其实并不重要。

enum Action {
    case refresh  
    case selectWorkout(String)
    case delete(String)
}
// 这些不是操作方法，而是内部实现函数
private func loadWorkouts() async { ... }
private func updateCache(_ workouts: [Workout]) { ... }

如果你已经从事iOS应用开发多年，可能会觉得这种设计模式有些多余。既然可以直接调用某个方法，为什么非要通过一个中间层来处理所有操作呢？其实，当团队规模较小时，只有三到五个屏幕需要管理时，这种设计确实没有太大问题。但当团队规模扩大、代码量增加时，这种模式就会暴露出其局限性。传统的iOS开发模式都是针对简单情况进行优化的，比如使用@StateObject、@Published等关键字，以及直接调用方法。这种做法易于理解，编写速度也很快。苹果提供的示例代码也是按照这种方式编写的，因为这些示例代码的规模本来就很小。

但当应用规模扩大后，这些直接的 method 调用就会带来很多问题。每个方法都可能成为状态变化的入口点，而入口点越多，就越难以理解ViewModel的工作原理。因此，在代码量增加的情况下，将操作功能集中起来处理，反而能够更有效地管理各种复杂逻辑，包括日志记录、调试、测试以及数据分析等功能。

日志记录

在基类中添加一行代码，就可以监控所有 ViewModel中的所有操作。这样就无需在多个方法中分别添加打印语句了。

func perform(_ action: Action) {
    print("[\(Self.self)] Operation: \(action)")
    // 处理相应操作……
}

调试

如果状态出现了错误，只需在perform()方法中设置一个断点，就能清楚地看到导致当前状态的一系列操作顺序。相比之下，如果在十个不同的方法中分别设置断点，会显得繁琐得多。

测试

使用这种设计模式后，测试代码会变得更加易于理解。因为所有操作都会经过相同的处理路径，所以你测试的其实就是真实应用中使用的那条代码路径。

viewModel.perform(.refresh)
viewModel.perform(.selectWorkout("123"))
viewModel.perform(.delete("123"))
XCTAssertEqual(viewModel.state.workouts, .finished([]))

分析功能

每个用户操作都会被自动记录下来。

func perform(_ action: Action) {
   analytics.track(action)
   // 处理该操作…
}

这个功能并不是什么新鲜事物。在Android开发中，这是一种标准的做法，谷歌的官方架构指南也推荐使用这种机制。Android开发者将这种方式称为单向数据流：事件向下流动（View → ViewModel → Repository），而状态则向上流动（Repository → ViewModel → View）。onAction()方法就是这种向下数据流的入口点。

谷歌的“Now in Android”示例应用就采用了这种模式，大多数Kotlin开发者也都在使用这种方式。当Android开发者加入一个新项目时，他们通常会看到一个Action枚举类型以及一个onAction()方法。

Swift语言中的实现

下面来看看如何将这种模式应用到iOS系统中：

class ViewModel〈State, Action〉: ObservableObject {
   @Published private(set) var state: State

   init(state: State) {
       self.state = state
   }

   func perform(_ action: Action) {
       // 子类可以重写此方法
   }

   func updateState(changing keyPath: WritableKeyPath〈State, some Any〉, to value: some Any) {
       state[keyPath: keyPath] = value
   }
}

状态可以从任何地方被读取，但只有在ViewModel内部才能被修改。这种设计确保了单向数据流的存在：View可以读取状态，但不能直接修改它；所有的更改都必须通过perform()方法来完成。

你也可以将这种机制定义为一个扩展函数，但使用基类可以让开发者将一些通用的逻辑（如日志记录、分析功能以及状态更新规则）集中放在一个地方。所有ViewModel都会继承这些默认行为。

子类可以通过重写这个基类方法来处理自己特定的操作。

下面是一个使用这种模式的完整 ViewModel示例：

class DashboardViewModel: ViewModel〈DashboardViewModel.State, DashboardViewModel.Action〉 {
   struct State {
       var workouts: Loadable〈[Workout]> = .loading
       var selectedTab: Tab = .dashboard
   }

   enum Action {
       case refresh
       case selectTab(Tab)
       case deleteWorkout(String)
   }

   override func perform(_ action: Action) {
       switch action {
           case .refresh:
               Task { await loadWorkouts() }
           case .selectTab(let tab):
               updateState(\.selectedTab, to: tab)
           case .deleteWorkout(let id):
               Task { await deleteWorkout(id) }
       }
   }

   private func loadWorkouts() async {
       updateState(\.workouts, to: .loading)
       do {
           let workouts = try await repository.fetchWorkouts()
           updateState(\.workouts, to: .finished(workouts))
       } catch {
           updateState(\.workouts, to: .error(error))
       }
   }

   private func deleteWorkout(_ id: String) async {
       // 实现细节
   }
}

请注意其结构：

• `State`是一个结构体，包含了`ViewModel`中的所有数据。
• `Action`是一个枚举类型，列出了用户可能的所有操作意图。
• `perform()`是唯一的入口点，它会将请求路由到相应的私有方法中。
• 私有方法们负责实际执行工作。

`Action`这个枚举类型代表了公共的接口规范；而私有方法则属于实现细节。看到这样的代码结构，你就能立刻明白它的功能是什么。

屏幕与视图：缺失的那层机制

我们已经解决了状态管理和操作路由的问题，但还有一个问题存在：代码耦合度过高。各个视图都各自拥有自己的`ViewModel`，这种设计不仅影响了预览功能的正常使用，也限制了代码的可复用性。

来看这个标准的视图示例：

struct DashboardView: View {
    @StateObject private var viewModel = DashboardViewModel()

    var body: some View {
        ScrollView {
            switch viewModel.workouts {
            case .loading: ProgressView()
            case .finished(let data): WorkoutList(data)
            case .error(let error): ErrorView(error)
            }
        }
    }
}

这个视图同时承担了两项任务：它既负责创建并管理自己的`ViewModel`，也负责渲染用户界面（包括布局各个视图以及处理不同的逻辑判断）。

预览功能存在的问题

试着在Xcode中预览这个视图：

#Preview {
    DashboardView()
}

这个视图会实际创建一个`ViewModel`对象。该`ViewModel`可能会发起网络请求，或者需要一些在预览环境中并不存在的依赖资源，从而导致程序崩溃。

因此人们不得不采取一些变通措施：

#Preview {
    DashboardView(viewModel: MockDashboardViewModel())
}

但这样一来，要么你需要使用模拟的`ViewModel`，要么就需要修改原始代码中的初始化逻辑；而模拟`ViewModel`的维护成本通常很高。因此很多iOS开发者最终放弃了预览功能。

结果就是，预览功能变成了那种“试过一次但无法可靠地使用，最终被弃用”的存在。

代码复用性方面的问题

假设你想在两个地方显示相同的锻炼列表：仪表盘界面和搜索结果页面。按照目前的代码结构，你无法重复使用`DashboardView`，因为它会自行创建一个`DashboardViewModel`对象。

你可以尝试只提取出列表部分的功能：

struct WorkoutList: View {
    let workouts: [Workout]
    var body: some View { ... }
}

但这样一来，加载状态和错误处理逻辑就被丢失了。于是你又尝试提取更多的内容：

struct WorkoutListContainer: View {
    let state: Loadable<[Workout]>
    var body: some View {
        switch state {
        case .loading: ProgressView()
        case .finished(let data): WorkoutList(data)
        case .error(let error): ErrorView(error)
        }
    }
}

现在我们有了`DashboardView`、`WorkoutList`和`WorkoutListContainer`这三个组件。但这种拆分方式并没有遵循任何明确的规则；其他开发者看到这样的代码结构，也会不知道应该遵循哪种设计模式。

Kotlin是如何解决这个问题的

@Composable
fun DashboardScreen(
    viewModel: DashboardViewModel = hiltViewModel()
) {
    val state = viewModel.state.collectAsState()
   DashboardContent(
      state = state,
      onAction = viewModel::onAction
   )
}
@Composable
fun DashboardContent(
   state: DashboardState,
   onAction: (DashboardAction) -> Unit
) {
   // 纯粹的用户界面渲染代码
   Column {
       when (state.workouts) {
           is Loading -> CircularProgressIndicator()
           is Success -> WorkoutList(state.workouts.data)
           is Error ->ErrorMessage(state.workouts.message)
       }
   }
}

@Preview
@Composable
fun DashboardContentPreview() {
   DashboardContent(
      state = DashboardState(workouts = Success(sampleWorkouts)),
      onAction = {}
   )
}

struct DashboardContent: View {
   let state: DashboardViewModel.State
   let onAction: (DashboardViewModel.Action) -> Void
   var body: some View {
       ScrollView {
           switch state.workouts {
               case .loading:
                   ProgressView()
               case .finished(let workouts):
                   WorkoutList(workouts, onAction: onAction)
               case .error(let error):
                   ErrorView(error, onRetry: { onAction(.refresh) })
           }
       }
   }
}

struct DashboardScreen: View {
   @StateObject private var viewModel: DashboardViewModel
   init(viewModel: DashboardViewModel) {
       stateObject(wrappedValue: viewModel)
   }
   var body: some View {
       DashboardContent(
           state: viewModel.state,
           onAction: viewModel.perform
       )
       onAppear {
           viewModel.perform(.refresh)
       }
   }
}

protocol ViewModeling: ObservableObject {
    associatedtype State
    var state: State { get }
}
struct Screen〈VM:ViewModeling, Content: View〉: View {
    @ObservedObject var viewModel: VM
    let content: (VM.State) -> Content
    var body: some View {
      content(viewModel.state)
   }
}

struct DashboardScreen: View {
   @ObservedObject var viewModel: DashboardViewModel
   var body: some View {
      ScreenviewModel: viewModel) { state, onAction in
         WorkoutList(state.workouts) {
           viewModel.perform(.action)
         }
      }
   }
}

// 视图
Button(onClick = { viewModel.onAction(ActionRefresh) })

// 视模型
fun onAction(action: Action) {
   when (action) {
       is Action Refresh -> viewModelScope.launch {
           _state.value = State(workouts = Resource.Loading)
           _state.value = State(workouts = repository.getWorkouts())
       }
   }
}

// 数据库层
suspend fun getWorkouts() = remoteSource.fetchWorkouts()

// 远程数据源层
suspend fun fetchWorkouts() = api.getWorkouts().map { it.toDomain() }

// 视图
Button("刷新") { onAction(.refresh) }

// 视模型
class DashboardViewModel: ViewModel〈State, Route, Action〉 {
   private let meRepo: MeRepository

   init(dependencies: Resolver) {
       self.meRepo = dependencies.resolve(MeRepository.self)!
       super.initdependsencies: dependencies, state: State())
   }

   override func perform(_ action: Action) {
       switch action {
       case .refresh:
           updateState(changing: \.workouts, to: .loading)
           Task {
               let data = try await meRepo.fetchTrainingLoad()
               updateState(changing: \.workouts, to: .finished(data))
           }
       }
   }
}

// 数据库层协议
protocol MeRepository {
   func fetchTrainingLoad() async throws -> [TrainingLoad]
}

class MeRepositoryImpl: MeRepository {
   private let remoteSource: MeRemoteSource

   init(dependencies: Resolver) {
       self.remoteSource = dependencies.resolve(MeRemoteSource.self)!
   }

   func fetchTrainingLoad() async throws -> [TrainingLoad] {
       try await remoteSource.fetchTrainingLoad()
   }
}

// 远程数据源层协议
protocol MeRemoteSource {
   func fetchTrainingLoad() async throws -> [TrainingLoad]
}

class MeRemoteSourceImpl: MeRemoteSource {
   private let api: API

   init(api: API) {
       self.api = api
   }

   func fetchTrainingLoad() async throws -> [TrainingLoad] {
       let response = try await api.query(TrainingLoadQuery())
       return response.me?.trainingLoad.map { TrainingLoad(from: $0) } ?? []
   }
}

class WorkoutRepository {
protocol WorkoutRepository {
    var workoutsPublisher: AnyPublisher〈[Workout], Never〉 { get }
    func updateWorkoutName(id: String, newName: String) async throws
}
final class WorkoutRepositoryImpl: WorkoutRepository {
    private let remoteSource: WorkoutRemoteSource
    @Published private var workouts: [Workout] = []
    var workoutsPublisher: AnyPublisher〈[Workout], Never〉 {
      $workouts.eraseToAnyPublisher()
   }
   init(remoteSource: WorkoutRemoteSource) {
      self.remoteSource = remoteSource
   }
   func updateWorkoutName(id: String, newName: String) async throws {
      // 1. 更新后端数据
      try await remoteSource.updateWorkout(id: id, name: newName)
      // 2. 更新本地数据
      if let index = workouts.firstIndex(where: { $0.id == id }) {
         workouts[index].name = newName
      }
      // 所有依赖该数据的界面都会自动收到更新通知
   }
}

class WorkoutListViewModel: ViewModel〈State, Action〉 {
   private let repository: WorkoutRepository
   private var cancellables = Set〈AnyCancellable〉()
   init(repository: WorkoutRepository) {
      self.repository = repository
      super.init(state: State())
      repository.workoutsPublisher
         .sink { [weak self] workouts in
            self?.updateState(\.workouts, to: .finished(workouts))
         }
      store(in: &cancellables)
   }
}