Android开发经验谈Android技术知识Android

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

2022-03-09  本文已影响0人  像程序那样去思考

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


一、MVC

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

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


二、MVP

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

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


三、MVVM

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

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

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

Lifecycle: 生命周期状态回调;

LiveData: 可观察的数据存储类;

databinding: 可以自动同步 UI 和 data,不用再 findviewById();

ViewModel: 存储界面相关的数据,这些数据不会在手机旋转等配置改变时丢失。


四、MVI

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

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

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

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

// 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
    }
}

五、MVP、MVVM 和 MVI 的对比

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

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

最后

前段时间还收集整理了Android高工必备技能知识脑图和核心知识点笔记文档!既能够夯实底层原理核心技术点,又能够掌握普通开发者,难以触及的架构设计方法论。那你在工作中、团队里、面试时,也就拥有了同行难以复制的核心竞争力。

相关的一些知识点解析都已经做了收录整理上传至公号中:Android开发之家,大家可以自行访问查阅。

上一篇下一篇

猜你喜欢

热点阅读