还在用MVP，MVVM？Android T-MVVM深度解耦开发框架

作者：tqzhang
链接：https://www.jianshu.com/p/80ba37cb5abc

前言

自从官方MVP的Sample出来后,闹得热火朝天的MVP,小码也未能幸免加入MVP大坑中,入坑近2年的MVP的架构终于要说拜拜了，最近由于公司项目相对稳定，做了一次较大的重构，原来的MVP架构切换到了T-MVVM，模型和视图彻底分离，整个项目清爽了许多。

问题

MVP缺点:

• Presenter中除了逻辑以外，还有大量的View->Model，Model->View的逻辑操作，造成     Presenter臃肿，维护困难。

•  对UI的渲染放在了Presenter中，所以UI和Presenter的交互会过于频繁。

• Presenter过多地渲染了UI，往往会使得它与特定的UI的交互频繁。一旦UI变动，Presenter也需要变

• 接口暴增,可以说代码量成倍增长,交互都需要通过接口传递信息,让人无法忍受.

基本上用过MVP的码友们都能发现了以上诸多弊端。于是小码就尝试从传统的MVP过度到T-MVVM,深度结构,告别繁琐的接传递信息。

优秀的架构能让软件高内聚、低耦合、可维护、可扩展，其实，对于MVP或者MVVM没有绝对好坏，MVP->MVVM只不过让模型和视图分离得更加的彻底，优化成了前者的缺点，如果项目业务不是很多或者业务相对简单，其实完全没有必要使用MVP/MVVM,反而让项目变得更为复杂。

T-MVVM代码,如果有帮助记得star哦

基于ViewModel,LiveData,Retrofit,OkHttp,Rxjava实现T-MVVM体系结构的架构，泛型限定，深度解耦。

ViewModel优点：

• 同步关联生命周期

• 数据共享 

• 复用性强 

LiveData优点：

• 确保UI界面的数据状态

•  没有内存泄漏,不会因为Activity的不可见导致Crash

• 不用再人为的处理生命周期

• 共享资源

此架构未使用DataBinding原由：

• 数据绑定增加Bug调试难度

• 复杂的页面，model也会很大，虽然使用方便了也很容易保证了数据的一致性，当时长期持有，不利于释放内存

•  数据双向绑定不利于View重用

T-MVVM代码调用

MVVM的调用和MVP类似，在MVP中全部由Presenter负责

VieModel之间数据同步操，而MVVM中ViewModel到充当了
Presenter的角色，ViewModel是View与 Model的连接器，持有可
被观察的数据持有者和网络请求操作，数据变更实时渲染UI。

T-MVVM架构分层代码

1：先定义BaseViewModel基类

BaseViewModel通过泛型类型参数BaseRepository子类初始化Repository数据仓库，同时在activity/fragment走onDestroy()生命周期方法时 BaseViewModel回调onCleared，即页面销毁是用来取消网络请求或资源释放等操作。

正常开发一般不建议直接通过ViewModel获取网络数据，这里我们将工作交给一个新的模块Repository。Repository只负责数据处理，提供干净的api，同时方便切换数据来源。

2：再定义BaseRepository

BaseRepository中内容相对简单，主要是获取ApiService和网络请求订阅容器，方便管理网络请求，即页面销毁是取消网络请求操作。

3：然后自定义AbsLifecycleFragment基类继承BaseFragment，BaseFragment可自行编写。如不需要使用T-MVVM，可自行继承BaseFragment，互不影响。

在initView方法中通过BaseViewModel子类泛型类型参数获取Class<T>，在通过ViewModelProviders.of(fragment).get(modelClass))实例化ViewModel

到此我们的基类基本编写完毕。

4：下面我们以一个简单业务实战下，获取文章列表

4-1:ArticleFragment

我们可以看出来ArticleFragment中只有UI初始化,发请网络请求action以及数据观察更新UI，列表展示用了TRecyclerView,欢迎star哦面向holder开发高复用，多类型的刷新库，从此只关心你的列表的Item展示。通过泛型除去了MVP中通过接口传递信息的大量代码，从此see you Mass implementation of interfaces。

4-2:ArticleViewModel

ArticleViewModel中持有可被观察的数据持有者LiveData和真正发起网络请求动作，在接收到服务端返回的数据通过mArticleData.postValue(articleObject)方式通知注册的Observer进行数据的刷新，此处需注意的是，setValue方法只能在主线程中调用，而postValue可以在任何线程中调用，如果是在后台子线程中更新LiveData的值，必须调用postValue。

4-3:ArticleRepository

最后我们的ArticleRepository中就提供不含任何杂质的纯净的数据，此处只提供了网络层的数据，在实际应用中可拆分类loacl data和remote data,可根据实际项目需求自行处理。

至此咋们一个简单业务代码就完成了，是驴子是马，拉出来溜溜就知道，实践出真知，效果图奉上：

之前有码友们提到多个网络请求如何处理，如果同一页面有多个网络请求操作，其实多网络请求可以合并处理，统一返回结果然后组装数据返回，同时也有利于控制空页面的显示逻辑。

市面上各种各样开发架构，萝卜青菜各有所爱，没有最好的架构，只有最适合自己的，大家在选型开发架构时理应多多斟酌，当前很火的架构并不一定适合自己,结合自身项目进行舍取。

项目地址github地址：https://github.com/SelfZhangTQ/T-MVVM，欢迎大家交流，star。

                        喜欢 就关注吧，欢迎投稿！