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
基于ViewModel、LiveData、Retrofit、OkHttp和Rxjava实现的T-MVVM体系结构的架构，泛型限定，深度解耦。
ViewModel优点： * 同步关联生命周期 * 数据共享 * 复用性强LiveData优点： * 确保UI界面的数据状态 * 没有内存泄漏,不会因为Activity的不可见导致Crash * 不用再人为的处理生命周期 * 共享资源
此架构未使用DataBinding原因：
* 数据绑定增加Bug调试难度* 复杂的页面，model也会很大，虽然使用方便了也很容易保证了数据的一致性，当长期持有，不利于释放内存* 数据双向绑定不利于View重用
T-MVVM的实现细节：
MVVM的调用和MVP类似，在MVP中全部由Presenter负责ViewModel之间的数据同步，而MVVM中ViewModel充当了Presenter的角色，ViewModel是View与Model的连接器，持有可被观察的数据持有者和网络请求操作，数据变更实时渲染UI。
如何使用T-MVVM架构
1.先定义BaseViewModel基类
/** * @author：tqzhang on 18/7/26 16:15 */ public class BaseViewModel extends AndroidViewModel { public T mRepository; public BaseViewModel(@NonNull Application application) { super(application); mRepository = TUtil.getNewInstance(this, 0); } @Override protected void onCleared() { super.onCleared(); if (mRepository != null) { mRepository.unSubscribe(); } } }
BaseViewModel通过泛型类型参数BaseRepository子类初始化Repository数据仓库，同时在activity/fragment走onDestroy()生命周期方法时 BaseViewModel回调onCleared，即页面销毁是用来取消网络请求或资源释放等操作。
正常开发一般不建议直接通过ViewModel获取网络数据，这里我们将工作交给一个新的模块Repository。Repository只负责数据处理，提供干净的api，同时方便切换数据来源。
2.再定义BaseRepository
public abstract class BaseRepository { protected ApiService apiService; public BaseRepository() { if (null == apiService) { apiService = HttpHelper.getInstance().create(ApiService.class); } } private CompositeSubscription mCompositeSubscription; protected void addSubscribe(Subscription subscription) { if (mCompositeSubscription == null) { mCompositeSubscription = new CompositeSubscription(); } mCompositeSubscription.add(subscription); } public void unSubscribe() { if (mCompositeSubscription != null && mCompositeSubscription.hasSubscriptions()) { mCompositeSubscription.clear(); }}
BaseRepository中内容相对简单，主要是获取ApiService和网络请求订阅容器，方便管理网络请求，即页面销毁是取消网络请求操作。
3.然后自定义AbsLifecycleFragment基类继承BaseFragment，BaseFragment可自行编写。如不需要使用T-MVVM，可自行继承BaseFragment，互不影响。
public abstract class AbsLifecycleFragment extends BaseFragment { protected T mViewModel; /** * init view * @param state */ @Override public void initView(Bundle state) { mViewModel = VMProviders(this, TUtil.getInstance(this, 0)); if (null != mViewModel) { dataObserver(); } } /** * create ViewModelProviders * * @return ViewModel */ protected T VMProviders(BaseFragment fragment, @NonNull Class modelClass) { return ViewModelProviders.of(fragment).get(modelClass); } protected void dataObserver() { } /** * 获取网络数据 */ protected void getRemoteData() { } }
在initView方法中通过BaseViewModel子类泛型类型参数获取Class
4.下面我们以一个简单业务实战下，获取文章列表。
4-1:ArticleFragment
/*** @author：tqzhang on 18/7/2 14:40*/public class ArticleFragment extends AbsLifecycleFragment { protected TRecyclerView mRecyclerView; protected StaggeredGridLayoutManager layoutManager; protected MultiTypeAdapter adapter; public static ArticleFragment newInstance() { return new ArticleFragment(); } @Override public int getLayoutResId() { return R.layout.fragment_list; } @Override public void initView(Bundle state) { super.initView(state); mRecyclerView=findViewById(R.id.recycler_view)； initAdapter()； initRecyclerView(); //获取网络数据 getRemoteData()； } public void initRecyclerView(){ layoutManager=new new StaggeredGridLayoutManager(1, StaggeredGridLayoutManager.VERTICAL); mRecyclerView.setAdapter(adapter); mRecyclerView.setLayoutManager(layoutManager);} //初始化adapter public void initAdapter(){ adapter= new MultiTypeAdapter.Builder<>() .bindArray(ArticleInfoVo.class, new ArticleRem1ItemHolder(context) , new ArticleRem2ItemHolder(context) , new ArticleRem3ItemHolder(context)) .bind(HeaderVo.class, new HeaderViewHolder(context, rogressStyle.Pacman)) .bind(FootVo.class, new FootViewHolder(context, ProgressStyle.Pacman)) .build(); //数据观察 @Override protected void dataObserver() { mViewModel.getArticleList().observe(this, articleVo -> { if (null != articleVo) { mRecyclerView.refreshComplete(articleVo.data.list, false); } }); } //获取网络数据 @Override protected void getRemoteData() { mViewModel.getArticleList(typeId, lastId); }}
我们可以看出来ArticleFragment中只有UI初始化，发请网络请求action以及数据观察更新UI，列表展示用了TRecyclerView面向holder开发高复用，多类型的刷新库，从此只关心你的列表的Item展示。还通过泛型除去了MVP中通过接口传递信息的大量代码，从此see you Mass implementation of interfaces。
4-2:ArticleViewModel
/*** @author：tqzhang on 18/7/26 16:15*/public class ArticleViewModel extends BaseViewModel { private MutableLiveData mArticleData; public ArticleViewModel(@NonNull Application application) { super(application); } public LiveData getArticleList() { if (mArticleData == null) { mArticleData = new MutableLiveData<>(); } return mArticleData; } public void getArticleList(String lectureLevel1, String lastId) { mRepository.loadArticleRemList(new CallBack() { @Override public void onNext(ArticleVo articleObject) { mArticleData.postValue(articleObject); } @Override public void onError(String e) { } }}
ArticleViewModel中持有可被观察的数据持有者LiveData和真正发起网络请求动作，在接收到服务端返回的数据通过mArticleData.postValue(articleObject)方式通知注册的Observer进行数据的刷新，此处需注意的是，setValue方法只能在主线程中调用，而postValue可以在任何线程中调用，如果是在后台子线程中更新LiveData的值，必须调用postValue。
4-3:ArticleRepository
/** * @author：tqzhang on 18/7/28 13:00 */ public class ArticleRepository extends BaseRepository { public void loadArticleRemList(final CallBack listener) { addSubscribe(apiService.getArticleRemList() .compose(RxSchedulers.io_main()) .subscribe(new RxSubscriber() { @Override public void onSuccess(ArticleVo articleObject) { listener.onNext(articleObject); } @Override public void onFailure(String msg) { listener.onError(msg); } }));}
最后我们的ArticleRepository中就提供不含任何杂质的纯净的数据，此处只提供了网络层的数据，在实际应用中可拆分类loacl data和remote data,可根据实际项目需求自行处理。
至此一个简单的业务代码就完成了，是驴子是马，拉出来溜溜就知道，实践出真知，效果图奉上：
之前有码友们提到多个网络请求如何处理，如果同一页面有多个网络请求操作，其实多网络请求可以合并处理，统一返回结果然后组装数据返回，同时也有利于控制空页面的显示逻辑。
市面上各种各样开发架构，萝卜青菜各有所爱，没有最好的架构，只有最适合自己的，大家在选型开发架构时理应多多斟酌，当前很火的架构并不一定适合自己,结合自身项目进行舍取。