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

前言

为了优化代码设计,业界先后提出了 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 里糅合了视图和业务的代码,分离程度不够。

Android UI 架构演进:从 MVC 到 MVP、MVVM、MVI_第1张图片


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 层的交互需要定义接口方法,当交互非常复杂时,需要定义很多接口方法和回调方法,也不好维护。

Android UI 架构演进:从 MVC 到 MVP、MVVM、MVI_第2张图片


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。

Android UI 架构演进:从 MVC 到 MVP、MVVM、MVI_第3张图片

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

Android UI 架构演进:从 MVC 到 MVP、MVVM、MVI_第4张图片

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

    private val mModel = MainModel()

    val mIntent = Channel(Channel.UNLIMITED)

    private val _state = MutableStateFlow(MainViewState.Idle)
    val state: StateFlow
        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) : 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) {
        // 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开发,ui,mvc,android)