Activity和Fragment剥离了数据处理的责任后，持有DataManager的引用，负责获取数据并展示，向DataManager传递数据，绝不进行网络请求和缓存读写。
举一个例子，分页加载
一般来说分页加载接口返回的数据是这样的
{
“code”:0,
“message”:“success”,
“data”:{
“page”:1,
“totalPage”:10,
“pageSize”:20,
“total”:200,
“list”:[…]
}
}
在传统的写法中，一般在Activity/Fragment中缓存page，totalPage，pageSize去进行分页请求，根据请求结果刷新数据并判断是否还有更多；每一个分页接口都要写一遍，假如把这段逻辑放到DataManager会怎么样？我是这么写的
//定义回调接口
public interface ActionCallback {
void onSuccess(T data);
void onFailure(String message, Throwable e);
}
分页加载DataManager实现
public class PageLoadDataManager extends BaseDataManager {
private static final int PAGE_COUNT = 20;
private List mDataList = new ArrayList<>();
private int currentPage = 0;
private int totalPage = 0;
public PageLoadDataManager() {
// init something…
}
public void loadData(final boolean refresh, ActionListener listener) {
if (refresh) {
currentPage = 0;
}
currentPage++;
RequestParams params = new RequestParams();
params.put(“page”, currentPage);
Request request = new Request(url, params);
request.request(new RequestCallback(){
@Override
public void onSuccess(JSONObject data) {
if (refresh) {
mDataList.clear();
}
totalPage = response.optInt(“total_page”);
// 返回数据添加到 mDataList …
if (listener != null) {
boolean hasMore = currentPage <= totalPage
listener.onSuccess(hasMore);
}
}
@Override
public void onFailure(String message, Throwable e) {
if (listener != null) {
listener.onFailure(message, e);
}
}
});
}
public List getDataList() {
return mDataList;
}
}
Activity/Fragment初始化DataManager之后，只需要将数据源绑定到Adapter，loadData设置的回调告诉上层还有没有更多数据，UI层调用adapter.notifyDataSetChanged( )；至于数据从哪来，分页逻辑，根本不需要UI层管理。UI层只需要通过loadData(refresh)，告诉DataManager是否需要重新加载分页，与下拉刷新的逻辑完美契合。
当然，在此基础上实现数据库缓存读写，也毫无压力。DataManager也很容易实现对某一数据的多个接口的统一管理，通过单例模式或者其他管理方法，将数据配发给多个页面。
优点： 大幅减轻Activity/Fragment的压力，实现数据统一管理，DataManager层成为了一个UI无关的AppSDK层
缺点： 需要添加嵌套回调，这个问题在引入RxJava之后被完美处理
其实到了这一步，已经能满足大多数几万行代码规模中小App的框架需求了，而且分层架构统一处理数据以及代码复用度高的特点，使得项目中按照框架思路实现业务成为最快速可靠的开发方法。
我认为一个优秀的框架，很重要的特性就是方便业务开发而不是给开发找麻烦，比如在分层设计过后，就算开发时间再紧张，依托分层框架依然是最快最保险的开发方法，假如某个接口直接在UI中写了，就意味着数据管理层提供的一切便利都无法直接使用，而且假如其他UI用到这个接口，还得再复制粘贴一遍改来改去，相反，依托框架，网络调用只实现一遍，上层即可重复使用这一业务接口（比较典型的：关注、收藏等）
即便如此，项目规模进一步往上之后，DataManager，Activity/Fragment的压力仍然会增大，更高的测试需求，要求进一步分离Activity/Fragment的代码。这时候就可以看看MVP和MVVM了
MVC的C是即持有具体Model，又持有具体View，所以C很臃肿，分层架构就算抽出了DataManager，实质上仍然是一个MVC架构，而MVP和MVVM则是C持有具体View这个问题做了点文章，其中MVP就是将大量的View <-> Model 交互剥离出来交由Presenter，Presenter持有抽象的View。
在去年写这个回答的时候，我曾经写过这么一段：
看上去很美好，但是网上很多博客的那种Demo写法我在尝试应用中发现并不实用，就是抽象出很多View接口，然后建立Presenter类来作为Presenter，这样做写些简单的列表获取，登录之类看起来很漂亮，好像做到了代码分离，但是业务场景一复杂就有点蛋疼
那个时候我还仅仅只是尝试，不实用是一个很感性的认识，也没有多说，那时候是在做一个商城应用，使用MVP编写诸如购物车之类复杂场景的时候遇到了很大的困难，以至于让我怀疑我是不是在用MVP给自己找麻烦，写登录这些还好，写到购物车的时候我就开始怀疑人生了。
一个ICartView，我要写多少接口？购物车查删改、优惠券满减查、凑单、价格计算、运费……二十个接口少不了吧？那么这个抽象的View除了给CartActivity用，还有其它什么卵用吗？
假如我写成ICartView，IBonusView，IXXXView……可是有的界面并不需要删改购物车列表啊，难道我还要再细分？然后让Activity实现一堆接口？搞成这个样子，假如哪天需求变了怎么办……
Presenter听起来很吊，主导者啊，但是没有Activity和Fragment的资源啊，我要怎么才能让它主导？需要获取系统的一些信息（需要Context）的时候怎么办？不持有Context难道再开接口吗？
写这么多接口，接口实现，Presenter，多写了几百行代码n个类，就为了把1~200行代码从Activity移出去？
还是放弃吧……
后来Google出了TODO-MVP，但是发现跟上面那种Demo写法一样很麻烦，我也没有实际运用。后来反编译了某个大型App，发现其正好是MVP架构，于是仔细看了一下代码，就如同我最开始的想法，一个IXXXView有多少功能就写多少接口。再看看Presenter的实现，我忽然就明白我为什么会感觉不实用了：
任何想要构建一个其他什么东西取代Activity/Fragment地位的尝试都是自找麻烦
MVP正是一个典型
既然MVP把Activity/Fragment抽象为View，那么就意味着当它作为一个抽象View去使用的时候，生命周期，Context这些极其重要的资源Presenter是看不到的，但是这些东西是不可能不使用的。为了能让Presenter使用到这些，Presenter就必须持有Context，绑定Activity、Fragment的生命周期，就算如此，在一些需要确定使用Activity、Fragment的场合，仍需要使用强制转型。
正因为Presenter这个“主导”，导致Presenter和Activity/Fragment高度绑定，Presenter和IXXXView，没有什么复用性。
这是我对目前Android MVP的一点看法，如果有小伙伴有比较好的实践经验，可以在评论告诉我。
在我研究MVP的时间点，MVVM也是一个很火的概念，基于data-binding框架的demo也很多，但是我看过之后立刻否决了这个方案，大部分应用在从接口获取数据后都会进行数据变换，哪怕拿到一个图片URL都会在Java层添加后缀获取缩略图，有的要根据数据源控制View大小，显隐，XML能做的事情太少了，如果将Model绑定到XML，大规模应用将会面临多少坑……
MVVM相比于MVP，最重要的一个概念就是“数据绑定”，Presenter还持有抽象的View，ViewModel连这个都不需要，View通过ViewModel订阅其所需的数据源，ViewModel向View提供改变数据的接口，当View的操作引起数据改变或者数据源发生改变时，ViewModel通过订阅告知View，View进行视图更新。
这就是MVVM吸引人的地方，ViewModel只提供数据订阅和数据接口，做到了与UI分离，ViewModel体量比Presenter小，复用性要比Presenter强太多，而且基于分层架构可以做到小幅修改就能实现。唯一的痛点在于：如何实现数据绑定？
之前提到的data-binding，并不是那么如意，而这次Google I/O 2017放出的android-architecture-components则很好的解决了这个问题
ViewModel组件规范了ViewModel的所处地位，生命周期，生成方式，以及一个Activity下多个Fragment共享ViewModel数据的问题
LiveData组件则提供了在Java层面View订阅ViewModel数据源的实现方案，很轻量。
ViewModel的引入能够很好应对Activity销毁重建时大规模数据的恢复问题，以及多个界面依赖一个接口返回数据的场景，在这两个组件的规范下实现MVVM架构会十分容易，而且十分有意义。
由于我已经在项目中大规模使用了RxJava，因此数据绑定我是采用RxJava方案实现的
关于使用 android-architecture-components 组件实现MVVM的方案可以参考
googlesamples/android-architecture-components
关于 新型MVVM结构的思路，推荐这三篇文章
自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。
深知大多数Android工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！
因此收集整理了一份《2024年Android移动开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Android开发知识点，真正体系化！
由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且后续会持续更新
如果你觉得这些内容对你有帮助，可以添加V获取：vip204888 （备注Android）
结尾
最后，针对上面谈的内容，给大家推荐一个Android资料，应该对大家有用。
首先是一个知识清单：（对于现在的Android及移动互联网来说，我们需要掌握的技术）
泛型原理丶反射原理丶Java虚拟机原理丶线程池原理丶
注解原理丶注解原理丶序列化
Activity知识体系（Activity的生命周期丶Activity的任务栈丶Activity的启动模式丶View源码丶Fragment内核相关丶service原理等）
代码框架结构优化（数据结构丶排序算法丶设计模式）
APP性能优化（用户体验优化丶适配丶代码调优）
热修复丶热升级丶Hook技术丶IOC架构设计
NDK（c编程丶C++丶JNI丶LINUX）
如何提高开发效率？
MVC丶MVP丶MVVM
微信小程序
Hybrid
Flutter
接下来是资料清单：（敲黑板！！！）
1.数据结构和算法
2.设计模式
3.全套体系化高级架构视频；七大主流技术模块，视频+源码+笔记
4.面试专题资料包（怎么能少了一份全面的面试题总结呢~）
不论遇到什么困难，都不应该成为我们放弃的理由！共勉~
如果你看到了这里，觉得文章写得不错就给个赞呗？如果你觉得那里值得改进的，请给我留言。一定会认真查询，修正不足。谢谢。
mg-Mj9IvDOY-1711968249202)]
2.设计模式
[外链图片转存中…(img-aEieyT7y-1711968249202)]
3.全套体系化高级架构视频；七大主流技术模块，视频+源码+笔记
[外链图片转存中…(img-Sg5mzIOn-1711968249202)]
4.面试专题资料包（怎么能少了一份全面的面试题总结呢~）
[外链图片转存中…(img-BiQYG2mm-1711968249202)]
不论遇到什么困难，都不应该成为我们放弃的理由！共勉~
如果你看到了这里，觉得文章写得不错就给个赞呗？如果你觉得那里值得改进的，请给我留言。一定会认真查询，修正不足。谢谢。
[外链图片转存中…(img-GLBQs5v8-1711968249203)]
171
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
