Android-UI架构演进

  1. Android-UI架构演进
  • 前言
  • 1. MVC
  • 2. MVP
  • 3. MVVM
  • 4. MVI
  • 5. MVP、MVVM 和 MVI 的对比
  • Android-UI架构演进

    前言

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

    img


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

    img


    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。

    img

    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

    img

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    68
    69
    70
    71
    72
    73
    74
    // 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,响应式编程似乎有一统天下的趋势。未来会怎么样,我们拭目以待。


    转载请注明来源,欢迎对文章中的引用来源进行考证,欢迎指出任何有错误或不够清晰的表达。可以在下面评论区评论,也可以邮件至 nathanwriting@126.com

    文章标题:Android-UI架构演进

    字数:2k

    本文作者:Nathaniel

    发布时间:2020-11-19, 15:28:59

    最后更新:2023-11-06, 22:59:18

    原始链接:http://example.com/2020/11/19/android-mvx/

    版权声明: "署名-非商用-相同方式共享 4.0" 转载请保留原文链接及作者。

    ×

    喜欢就点赞,疼爱就打赏