在这篇文章中，我们将对 Kotlin 多平台移动端的最佳架构进行深入探讨。在2023年，作为 Android 开发者，我们会倾向于采用 MVVM 架构，因为它简单、灵活且易于测试。而作为 iOS 开发者，我们可能会选择 MVC、Viper 等架构。在 Flutter 世界中，BLoC（Business logic components）是非常流行的架构。
Kotlin 多平台提供了跨平台开发，支持在 iOS、Android 或桌面应用中共享业务逻辑和表示逻辑。在这里，我们将进一步讨论应该遵循哪种架构，并寻找适合 KMM 的架构。
我们想要实现什么？
在架构方面，没有明确的矩阵来决定应该采用哪种架构。在 KMM 的世界里，架构应该足够灵活，能够适应对现有代码的新变更，并在可测试性和可维护性方面支持多个平台。
简单性是成功架构的关键。我们将避免使用繁琐的代码，追求简单性。
以下是一些关键要点：
- 最大程度地共享代码，无论是业务逻辑还是表示逻辑。
- 最小化平台特定的代码。
- 便于本地和共享逻辑之间的交流。
- 灵活适应未来的修改。
- 遵循 SOLID 原则。
BLoC 架构
BLoC 表示基于业务逻辑组件的架构，在 Flutter 世界中非常流行。让我们将其分解成较小的部分，并尝试理解其矩阵。
业务逻辑组件
在 BLoC 中，业务逻辑组件是一个简单的组件，负责处理业务逻辑。它涉及对事件的响应，通过对事件的响应来修改状态的更改。为了理解这一点，让我们创建一个简单的组件并尝试实现业务逻辑。
//GalleryComponent.kt
interface GalleryComponent {val model: Modelfun onGalleryClick()fun onDeleteClick()data class Model(val isLoading: Boolean)
}
//GalleryFeature.kt
class GalleryFeature(): GalleryComponent {override val model: Model get() = Model()override fun onGalleryClick() {//handle click here}override fun onDeleteClick() {//handle click here}
}
这不是一个典型的 BLoC 架构，如果您仔细查看GalleryComponent.kt或这些类，会发现 BLoC 还涉及状态、事件和消费者组件等。
我们希望保持简单，不涉及在 Kotlin 多平台中可以轻松避免的其他组件。如果您熟悉 MVVM 架构，将 BLoC 架构中的 ViewModel 替换为组件，那么它与 MVVM 架构非常相似。
通过观察其可测试性、灵活性和简单性，BLoC 架构也适用于 KMM 的世界。
事实上，BLoC 在 KMM 中带来了使用挑战，因为大多数开发人员来自 Android 和 iOS 的世界。他们更喜欢在 MVVM 上工作，而不是采用新的 BLoC 模式，尽管其行为与 MVVM 类似。如果您想尝试 BLoC 模式，我建议您不要使用任何复杂的架构库，因为这样会很难维护整体架构。
MVI 架构
MVI（Model-View-Intent）架构使用意图将业务逻辑和表示逻辑分离。在 MVI 中，意图用于与业务逻辑进行通信。
在此，意图从视图接收，模型通过对意图的响应进行更新。从底层来看，MVI 的代价在于可能出现竞争条件，因为解决由竞争条件引起的一些错误会非常复杂。
在大型代码库中，维护大量的意图非常复杂。但我喜欢 MVI 的简洁性。在此，我已经假设您熟悉 MVI，因此我们将跳过示例，继续进行下一步。
MVC 或 MVP 架构
MVC（Model-View-Controller）或 MVP（Model View Presenter）架构在底层具有相同的行为。在 MVC 或 MVP 中，控制器或 Presenter 充当中介，通过对来自视图的事件进行响应来对模型进行修改。毫无疑问，MVC 或 MVP 通过使用某种交互器很好地将业务逻辑和表示逻辑分开。
但是它会使代码更加灵活以进行测试。但是，与此同时，它带来了接口的复杂性和视图与模型之间的紧密耦合。尤其是在大型代码库中，维护大量的接口会非常复杂。同上，我已经假设您熟悉这些内容，因此我们将跳过示例，继续进行下一步。
MVVM 架构
MVVM（Model-View-ViewModel）架构将业务逻辑和表示逻辑分开，消除了各组件之间的紧密耦合。在 MVVM 中，ViewModel 充当模型和视图之间的桥梁。它对视图没有任何了解，也没有对视图的直接引用。
ViewModel 通过对来自视图的事件进行响应来修改模型。如果您是 Android 开发人员，您将对 MVVM 非常熟悉。MVVM 提供了任何应用程序所需的成功架构矩阵。它带来了灵活性、可扩展性和可维护性的好处。但是，同样，在大型代码库中，维护 ViewModel 内部的大量状态会非常困难。
哪种架构应该被采用？
众所周知，每种架构都有其优缺点。但最终，我们需要得出结论，选择应该遵循哪种架构。
为了解决这个冲突，您应该考虑以下关键点，这些点有助于根据您的需求选择架构。如果您问我我的意见，我建议考虑 MVVM 架构，因为它简单易懂。
- 架构是否足够灵活以适应未来的修改？
- 架构是否支持应用程序要求？
- 架构是否支持测试性和简洁性？
- 架构组件是否对读取开放，但对外部修改封闭？
- 团队采用架构是否容易？
- 它是否是干净而纯粹的架构，不依赖于第三方库？
总结
在 Kotlin Multiplatform Mobile 中，市场上有多种架构库，用于解决 KMM 中存在的多种问题。在 2023 年，Circuit 架构、BLoC 架构、Decompose 架构等都将推出，当前存在着大量的架构库。但我们是否应该使用这些架构？
一个架构不应该依赖于任何带来维护问题的架构库。
我宁愿考虑使用简单而干净的 MVVM 架构，它可以轻松扩展，并对未来的修改开放，而不依赖于任何其他的 API 或库。
