Android UI 架构演进：从 MVC 到 MVP、MVVM、MVI

最新推荐文章于 2024-05-15 00:15:14 发布

Android-海绵

最新推荐文章于 2024-05-15 00:15:14 发布

阅读量915

点赞数 2

分类专栏： Android开发文章标签： ui mvc android

本文链接：https://blog.csdn.net/m0_64365896/article/details/125073979

版权

Android开发专栏收录该内容

102 篇文章 6 订阅

订阅专栏

前言

为了优化代码设计，业界先后提出了 MVC、MVP、MVVM 和 MVI 等架构设计。这四个模式讨论是 “如何管理 UI” 这个话题，采用的手段都是 “关注点分离”，只是实现的细节不同。最开始是没有采用任何模式的状态，不管是视图代码还是表现逻辑全都写在 Activity 里面，很明显这样的代码耦合度非常高，难以进行维护和测试，可读性也不好。

提示：耦合度高是现象，关注点分离是手段，易维护性和易测试性是结果，模式是可复用的经验。

1. MVC

MVC 其实是 Android 默认的设计，MVC 里将代码分为三个部分：

View： Layout XML 文件；
Model： 负责管理业务数据逻辑，如网络请求、数据库处理；
Controller： Activity 负责处理表现逻辑。

MVC 初步解决了 Activity 代码太多的问题，但也有缺点：我们的初衷 Activity / Fragment 是只处理表现逻辑的部分，但现实是 Activity 天然不可避免要处理 UI，也要处理用户交互，说明 Activity 本身天然承担了 View 的角色。那么这个架构就会造成 Activity 里糅合了视图和业务的代码，分离程度不够。

2. MVP

为了将 Activity 中的表现逻辑彻底分离出来，业界提出了 MVP 的设计。MVP 同样将代码划分为三个部分：

View： Activity 和 Layout XML 文件；
Model： 负责管理业务数据逻辑，如网络请求、数据库处理；
Presenter： 负责处理表现逻辑。

在实现细节上，View 和 Presenter 中间会定义一个协议接口 Contract，这个接口会约定 View 如何向 Presenter 发指令和 Presenter 如何 Callback 给 View。这样的架构里 Activity 不再有表现逻辑的部分，Activity 作为 View 的角色只处理和 UI 有关的事情。但还是存在一些缺点：

双向依赖： View 和 Presenter 是双向依赖的，一旦 View 层做出改变，相应地 Presenter 也需要做出调整。在业务语境下，View 层变化是大概率事件；
内存泄漏风险： Presenter 持有 View 层的引用，当用户关闭了 View 层，但 Model 层仍然在进行耗时操作，就会有内存泄漏风险。虽然有解决办法，但还是存在风险点和复杂度（弱引用 / onDestroy() 回收 Presenter）。
协议接口类膨胀： View 层和 Presenter 层的交互需要定义接口方法，当交互非常复杂时，需要定义很多接口方法和回调方法，也不好维护。

3. MVVM

MVVM 模式改动在于中间的 Presenter 改为 ViewModel，MVVM 同样将代码划分为三个部分：

View： Activity 和 Layout XML 文件，与 MVP 中 View 的概念相同；
Model： 负责管理业务数据逻辑，如网络请求、数据库处理，与 MVP 中 Model 的概念相同；
ViewModel： 存储视图状态，负责处理表现逻辑，并将数据设置给可观察数据容器。

在实现细节上，View 和 Presenter 从双向依赖变成 View 可以向 ViewModel 发指令，但 ViewModel 不会直接向 View 回调，而是让 View 通过观察者的模式去监听数据的变化，有效规避了 MVP 双向依赖的缺点。但 MVVM 本身也存在一些缺点：

多数据流： View 与 ViewModel 的交互分散，缺少唯一修改源，不易于追踪；
LiveData 膨胀： 复杂的页面需要定义多个 MutableLiveData，并且都需要暴露为不可变的 LiveData。

DataBinding、ViewModel 和 LiveData 等组件是 Google 为了帮助我们实现 MVVM 模式提供的架构组件，它们并不是 MVVM 的本质，只是实现上的工具。

Lifecycle： 生命周期状态回调；
LiveData： 可观察的数据存储类；
databinding： 可以自动同步 UI 和 data，不用再 findviewById()；
ViewModel： 存储界面相关的数据，这些数据不会在手机旋转等配置改变时丢失。

4. MVI

MVI 模式的改动在于将 View 和 ViewModel 之间的多数据流改为基于 ViewState 的单数据流。MVI 将代码分为以下四个部分：

View： Activity 和 Layout XML 文件，与 MVVM 中 View 的概念相同；
Intent： 定义数据操作，是将数据传到 Model 的唯一来源，相比 MVVM 是新的概念；
ViewModel： 存储视图状态，负责处理表现逻辑，并将 ViewState 设置给可观察数据容器；
ViewState： 一个数据类，包含页面状态和对应的数据。

在实现细节上，View 和 ViewModel 之间的多个交互（多 LiveData 数据流）变成了单数据流。无论 View 有多少个视图状态，只需要订阅一个 ViewState 便可以获取所有状态，再根据 ViewState 去响应。当然，实践中应该根据状态之间的关联程度来决定数据流的个数，不应该为了使用 MVI 模式而强行将多个无关的状态压缩在同一个数据流中。

唯一可信源： 数据只有一个来源（ViewModel），与 MVVM 的思想相同；
单数据流： View 和 ViewModel 之间只有一个数据流，只有一个地方可以修改数据，确保数据是安全稳定的。并且 View 只需要订阅一个 ViewState 就可以获取所有状态和数据，相比 MVVM 是新的特性；
响应式： ViewState 包含页面当前的状态和数据，View 通过订阅 ViewState 就可以完成页面刷新，相比于 MVVM 是新的特性。

但 MVI 本身也存在一些缺点：

State 膨胀： 所有视图变化都转换为 ViewState，还需要管理不同状态下对应的数据。实践中应该根据状态之间的关联程度来决定使用单流还是多流；
内存开销： ViewState 是不可变类，状态变更时需要创建新的对象，存在一定内存开销；
局部刷新： View 根据 ViewState 响应，不易实现局部 Diff 刷新，可以使用 Flow#distinctUntilChanged() 来刷新来减少不必要的刷新。

不过，MVI 并不是一个全新的设计模式，其背后设计理念与 Redux 模式如出一辙。在 Redux 里完全可以找到与 MVI 相同的各个要素，而且明显 Redux 的命名方式更加清晰无歧义，小伙伴们知道 Model - View - Intent 这个命名方式的原始出处的话，可以告诉我一声。

View - View
Action - Intent
Store - ViewModel
State - ViewState
Reducer - Model

// 1、ViewModel
class MainViewModel: ViewModel() {

    private val mModel = MainModel()

    val mIntent = Channel<MainIntent>(Channel.UNLIMITED)

    private val _state = MutableStateFlow<MainViewState>(MainViewState.Idle)
    val state: StateFlow<MainViewState>
        get() = _state

    init {
        viewModelScope.launch {
            mIntent.consumeAsFlow().collect {
                when (it) {
                    is MainIntent.FetchNew -> fetchNews()
                }
            }
        }
    }

    private fun fetchNews() {
        viewModelScope.launch {
            _state.value = MainViewState.Loading
            _state.value = try {
                MainViewState.News(mModel.fetchNews())
            } catch (e: Exception) {
                MainViewState.Error(e.localizedMessage)
            }
        }
    }
}

// 2、ViewState
sealed class MainViewState {
    object Idle : MainViewState()
    object Loading : MainViewState()
    data class News(val news: List<New>) : MainViewState()
    data class Error(val error: String?) : MainViewState()

}
// 3、Intent
sealed class MainIntent {
    object FetchNew : MainIntent()
}
// 4、View
class MainActivity : AppCompatActivity() {

    private lateinit var mainViewModel: MainViewModel

    private fun observeViewModel() {
        lifecycleScope.launch {
            mainViewModel.state.collect {
                when (it) {
                    is MainViewState.Idle -> {

                    }
                    is MainViewState.Loading -> {
                    }

                    is MainViewState.News -> {
                        renderList(it.news)
                    }
                    is MainViewState.Error -> {
                    }
                }
            }
        }
    }

    private fun renderList(news: List<New>) {
        // do something
    }
}

5. MVP、MVVM 和 MVI 的对比

MVVM 和 MVP 的思想是相同的，最本质的概念就是 Activity 里做的事情太多了，所以要把 Activity 中与 UI 无关的部分抽离出来，交给别人做。这个 “别人” 在 MVP 里叫作 Presenter，在 MVVM 里叫作 ViewModel。而不论是 MVP 中的约定接口，还是 ViewModel 里的观察者模式，这些都是实现上的细节而已。

MVI 与前者的主要区别不在于强调严格的单向数据流，而在于从命令式的开发模式，转变为响应式的开发模式。我们并不是说越新潮，越复杂的架构就是最好的，只有合适的架构才是最好的。但是不可否认，从 React 到 Flutter，从 MVI 到 Compose，响应式编程似乎有一统天下的趋势。未来会怎么样，我们拭目以待。

文末

要想成为架构师，那就不要局限在编码，业务，要会选型、扩展，提升编程思维。此外，良好的职业规划也很重要，学习的习惯很重要，但是最重要的还是要能持之以恒，任何不能坚持落实的计划都是空谈。

如果你没有方向，这里给大家分享一套由阿里高级架构师编写的《Android八大模块进阶笔记》，帮大家将杂乱、零散、碎片化的知识进行体系化的整理，让大家系统而高效地掌握Android开发的各个知识点。
在这里插入图片描述
相对于我们平时看的碎片化内容，这份笔记的知识点更系统化，更容易理解和记忆，是严格按照知识体系编排的。

一、架构师筑基必备技能

1、深入理解Java泛型
2、注解深入浅出
3、并发编程
4、数据传输与序列化
5、Java虚拟机原理
6、高效IO
……

在这里插入图片描述

二、Android百大框架源码解析

1.Retrofit 2.0源码解析
2.Okhttp3源码解析
3.ButterKnife源码解析
4.MPAndroidChart 源码解析
5.Glide源码解析
6.Leakcanary 源码解析
7.Universal-lmage-Loader源码解析
8.EventBus 3.0源码解析
9.zxing源码分析
10.Picasso源码解析
11.LottieAndroid使用详解及源码解析
12.Fresco 源码分析——图片加载流程

在这里插入图片描述

三、Android性能优化实战解析

腾讯Bugly:对字符串匹配算法的一点理解
爱奇艺：安卓APP崩溃捕获方案——xCrash
字节跳动：深入理解Gradle框架之一：Plugin, Extension, buildSrc
百度APP技术：Android H5首屏优化实践
支付宝客户端架构解析：Android 客户端启动速度优化之「垃圾回收」
携程：从智行 Android 项目看组件化架构实践
网易新闻构建优化：如何让你的构建速度“势如闪电”？
…

在这里插入图片描述

四、高级kotlin强化实战

1、Kotlin入门教程
2、Kotlin 实战避坑指南
3、项目实战《Kotlin Jetpack 实战》

从一个膜拜大神的 Demo 开始
Kotlin 写 Gradle 脚本是一种什么体验？
Kotlin 编程的三重境界
Kotlin 高阶函数
Kotlin 泛型
Kotlin 扩展
Kotlin 委托
协程“不为人知”的调试技巧
图解协程：suspend

在这里插入图片描述

五、Android高级UI开源框架进阶解密

1.SmartRefreshLayout的使用
2.Android之PullToRefresh控件源码解析
3.Android-PullToRefresh下拉刷新库基本用法
4.LoadSir-高效易用的加载反馈页管理框架
5.Android通用LoadingView加载框架详解
6.MPAndroidChart实现LineChart（折线图）
7.hellocharts-android使用指南
8.SmartTable使用指南
9.开源项目android-uitableview介绍
10.ExcelPanel 使用指南
11.Android开源项目SlidingMenu深切解析
12.MaterialDrawer使用指南
在这里插入图片描述

六、NDK模块开发

1、NDK 模块开发
2、JNI 模块
3、Native 开发工具
4、Linux 编程
5、底层图片处理
6、音视频开发
7、机器学习

在这里插入图片描述

七、Flutter技术进阶

1、Flutter跨平台开发概述
2、Windows中Flutter开发环境搭建
3、编写你的第一个Flutter APP
4、Flutter开发环境搭建和调试
5、Dart语法篇之基础语法(一)
6、Dart语法篇之集合的使用与源码解析(二)
7、Dart语法篇之集合操作符函数与源码分析(三)
…
在这里插入图片描述

八、微信小程序开发

1、小程序概述及入门
2、小程序UI开发
3、API操作
4、购物商场项目实战……

在这里插入图片描述

全套视频资料：

一、面试合集
在这里插入图片描述
二、源码解析合集

在这里插入图片描述
三、开源框架合集

在这里插入图片描述
欢迎大家一键三连支持，若需要文中资料，直接点击文末CSDN官方认证微信卡片免费领取【保证100%免费】↓↓↓

Android-海绵

关注

2
点赞
踩
12

收藏

觉得还不错? 一键收藏
0
评论
Android UI 架构演进：从 MVC 到 MVP、MVVM、MVI

为了优化代码设计，业界先后提出了 MVC、MVP、MVVM 和 MVI 等架构设计。这四个模式讨论是 “如何管理 UI” 这个话题，采用的手段都是 “关注点分离”，只是实现的细节不同。最开始是没有采用任何模式的状态，不管是视图代码还是表现逻辑全都写在 Activity 里面，很明显这样的代码耦合度非常高，难以进行维护和测试，可读性也不好。MVC 其实是 Android 默认的设计，MVC 里将代码分为三个部分：MVC 初步解决了 Activity 代码太多的问题，但也有缺点：我们的初衷 Activity /
复制链接

扫一扫