Android 项目架构设计：从 MVC 到 MVI 的演进与实践

引言

在 Android 应用开发中，一个清晰、可维护、可测试的架构设计是项目成功的关键。随着应用复杂度的提升和团队规模的扩大，选择合适的架构模式变得至关重要。本文将带你深入浅出地了解 Android 项目架构设计的演进历程、主流模式对比以及如何在实际项目中落地实践。

1. 架构设计的重要性

为什么我们需要关注架构？

• 代码可维护性：清晰的架构让代码结构一目了然，新成员能快速上手，老成员能高效定位问题。
• 可测试性：良好的架构天然支持单元测试、集成测试，确保代码质量。
• 团队协作：模块化的设计允许不同开发者或团队并行开发，减少冲突。
• 可扩展性：当业务需求变化或增加新功能时，良好的架构能最小化改动成本，实现平滑扩展。
• 单一职责：每个组件、类甚至方法都有明确的职责，避免出现“上帝类”或“面条式代码”。

一个没有良好架构的应用，随着时间推移，往往会变成难以维护的“遗留代码”，任何改动都可能引发意想不到的 Bug。

2. 经典架构模式演进

Android 架构并非一成不变，它随着开发理念和工具链的进步而不断演进。

2.1 MVC (Model-View-Controller)

• 模型 (Model)：负责数据和业务逻辑。
• 视图 (View)：负责 UI 展示，在 Android 中通常是Activity/Fragment和 XML 布局。
• 控制器 (Controller)：负责处理用户输入，更新模型和视图。在 Android 早期，Activity/Fragment常常身兼 View 和 Controller 两职。

问题：Activity/Fragment过于臃肿，承担了太多职责（生命周期、UI 更新、业务逻辑、数据获取），导致难以测试和维护，也就是常说的“上帝对象”。

2.2 MVP (Model-View-Presenter)

为了解决 MVC 中 View 和 Controller 耦合过紧的问题，MVP 模式被引入。

• 模型 (Model)：不变，负责数据和业务逻辑。
• 视图 (View)：变为被动接口，只定义 UI 更新的方法。Activity/Fragment实现此接口。
• 表示层 (Presenter)：作为 View 和 Model 的中间人，持有 View 的引用，从 Model 获取数据，处理业务逻辑，并调用 View 接口的方法来更新 UI。

优点：将 UI 逻辑从Activity/Fragment中抽离，使其变得更薄，便于单元测试 Presenter。
缺点：Presenter 持有 View 的强引用，需要小心处理生命周期，避免内存泄漏。同时，随着业务复杂，Presenter 也可能变得庞大。

2.3 MVVM (Model-View-ViewModel)

借助 Jetpack 组件（特别是LiveData和DataBinding/ViewBinding），MVVM 成为 Android 官方推荐架构。

• 模型 (Model)：负责数据和业务逻辑。
• 视图 (View)：Activity/Fragment，负责设置 UI 和观察 ViewModel 的数据变化。
• 视图模型 (ViewModel)：持有 UI 相关的数据，并通过LiveData/StateFlow暴露给 View。它不持有 View 的引用，因此与生命周期无关。

优点：

1. 数据驱动 UI：View 订阅 ViewModel 的数据流，数据变化自动驱动 UI 更新。
2. 生命周期感知：ViewModel和LiveData自动管理生命周期，避免内存泄漏。
3. 更好的关注点分离：View 只负责展示和用户交互，ViewModel 负责准备展示数据。

// 一个简单的 ViewModel 示例classUserViewModel(privatevaluserRepository:UserRepository):ViewModel(){privateval_userName=MutableLiveData<String>()valuserName:LiveData<String>=_userNamefunloadUser(userId:String){viewModelScope.launch{valuser=userRepository.getUser(userId)_userName.value=user.name}}}

2.4 MVI (Model-View-Intent)

MVI 是一种响应式架构，强调单向数据流和状态不可变性。

• 模型 (Model)：代表状态 (State)。UI 是所有状态的函数。
• 视图 (View)：渲染状态，并将用户输入转换为意图 (Intent)发送。
• 意图 (Intent)：代表用户或系统发起的动作（如按钮点击、初始化）。
• 处理器（通常由 ViewModel 担任）：接收 Intent，处理业务逻辑，并生成新的 State。

优点：

1. 单向数据流：数据流向清晰可预测，便于调试和追溯状态变化。
2. 状态不可变：任何时候 State 都是确定的，避免了因状态共享和异步修改带来的竞态问题。
3. 易于测试：业务逻辑集中在处理 Intent 和生成新 State 的过程中，易于进行单元测试。

// MVI 状态与意图示例dataclassLoginState(valisLoading:Boolean=false,valisSuccess:Boolean=false,valerrorMessage:String?=null)sealedclassLoginIntent{objectInit:LoginIntent()dataclassLogin(valusername:String,valpassword:String):LoginIntent()objectDismissError:LoginIntent()}

3. 现代分层架构设计

单一的 MV* 模式不足以支撑大型复杂应用。现代 Android 项目通常采用清晰的分层架构，结合 MVVM 或 MVI 作为表现层模式。

3.1 典型分层

一个健壮的分层架构通常包含以下层次：

1. 表现层 (Presentation Layer)：

   • 组件：Activity,Fragment,ViewModel,ComposeUI。
   • 职责：处理 UI 展示和用户交互。使用 MVVM 或 MVI 模式。
   • 依赖：领域层（Use Cases）。

2. 领域层 (Domain Layer)：

   • 组件：Use Cases (Interactors), Repository Interfaces。
   • 职责：封装核心、独立的业务规则。它是应用中最稳定的一层，不应依赖 Android SDK 或任何框架。
   • 依赖：无（纯 Kotlin/Java 模块）。

3. 数据层 (Data Layer)：

   • 组件：Repository Implementations, Data Sources (Local/Remote), Data Models。
   • 职责：管理应用数据，提供统一的数据访问入口。实现领域层定义的 Repository 接口。
   • 依赖：领域层（接口），以及各种 SDK（如 Room, Retrofit）。

3.2 依赖规则

关键原则：依赖方向永远指向抽象（接口），并且向内指向核心（领域层）。

• 表现层依赖领域层的 Use Cases。
• 数据层实现领域层定义的 Repository 接口。
• 领域层不依赖任何其他层（保持纯净）。

4. 组件化与模块化

对于大型团队和项目，单一的 App 模块会带来编译慢、职责模糊、团队协作冲突等问题。组件化/模块化是解决方案。

4.1 概念

• 模块化 (Modularization)：将代码拆分为多个 Gradle 模块（:core:network,:feature:login）。每个模块可以独立编译，明确依赖关系。
• 组件化 (Componentization)：在模块化的基础上，强调业务功能的独立性和可复用性。每个业务组件（如:feature:home）可以独立开发、测试，甚至理论上能独立运行。

4.2 常见模块划分

app/ (主App模块，负责组装) ├── feature/ (功能模块) │ ├── login/ │ ├── home/ │ └── profile/ ├── core/ (核心基础模块) │ ├── network/ │ ├── database/ │ ├── common/ (通用扩展、工具) │ └── design/ (UI组件、主题) └── domain/ (领域模块，纯Kotlin) ├── model/ └── repository/

4.3 组件间通信

• 页面跳转：使用 Deep Link 或路由框架（如 App Startup + 自研路由，或第三方库）。
• 数据传递：通过接口暴露服务。可以使用 Service Locator 模式或依赖注入框架（如 Hilt/Dagger）来管理组件间的依赖。
• 避免循环依赖：通过抽取公共接口到:core:api模块等方式解决。

5. 实战：构建一个组件化 MVVM 项目

假设我们要构建一个简单的用户信息展示应用。

5.1 项目结构

MyApp/ ├── app/ (空壳，负责依赖注入和组装) ├── core/ │ ├── network/ (Retrofit 配置) │ ├── database/ (Room 配置) │ └── common/ ├── domain/ │ ├── model/ (User) │ └── repository/ (UserRepository 接口) ├── data/ │ └── repository/ (UserRepository 实现) └── feature/ └── userprofile/ ├── di/ (该功能的 Hilt Module) ├── presentation/ (Activity, ViewModel, State) └── UserProfileFeature.kt

5.2 关键代码示例

1. Domain Layer (纯 Kotlin)

// domain/model/User.ktdataclassUser(valid:String,valname:String,valemail:String)// domain/repository/UserRepository.kt (接口)interfaceUserRepository{suspendfungetUser(id:String):User}

2. Data Layer (实现接口)

// data/repository/UserRepositoryImpl.ktclassUserRepositoryImpl@Injectconstructor(privatevaluserService:UserService,// Retrofit 接口privatevaluserDao:UserDao// Room Dao):UserRepository{overridesuspendfungetUser(id:String):User{// 业务逻辑：优先缓存，网络获取后更新缓存returnuserDao.getUser(id)?:fetchFromNetwork(id)}privatesuspendfunfetchFromNetwork(id:String):User{...}}

3. Presentation Layer (MVVM with State)

// feature/userprofile/presentation/UserProfileViewModel.kt@HiltViewModelclassUserProfileViewModel@Injectconstructor(privatevalgetUserUseCase:GetUserUseCase// UseCase 封装了业务逻辑):ViewModel(){privateval_uiState=MutableStateFlow(UserProfileState())valuiState:StateFlow<UserProfileState>=_uiState.asStateFlow()funloadUser(userId:String){viewModelScope.launch{_uiState.update{it.copy(isLoading=true)}try{valuser=getUserUseCase(userId)_uiState.update{it.copy(isLoading=false,user=user)}}catch(e:Exception){_uiState.update{it.copy(isLoading=false,error=e.message)}}}}}// feature/userprofile/presentation/UserProfileState.ktdataclassUserProfileState(valisLoading:Boolean=false,valuser:User?=null,valerror:String?=null)

6. 架构选择建议与总结

• 新手或小型项目：从MVVM开始。它学习曲线平缓，有强大的官方组件（ViewModel, LiveData）支持，能解决大部分生命周期和数据绑定问题。
• 中型至大型项目：采用分层架构 + MVVM/MVI。引入清晰的领域层和数据层，为模块化打下基础。如果状态管理变得复杂，可以考虑引入 MVI 来获得更可预测的数据流。
• 超大型团队项目：必须推进组件化/模块化。结合单一职责和依赖倒置原则，使用 Hilt/Dagger 进行依赖注入管理模块间通信。

记住，没有“银弹”架构。最好的架构是适合你的团队规模、项目复杂度和迭代速度的架构。核心目标是：控制复杂度，提升代码的可读性、可测试性和可维护性。

架构设计是一个持续演进的过程，随着 Kotlin Multiplatform、Jetpack Compose 等新技术的普及，未来的架构模式也必将有新的发展。保持学习，灵活应用。