前言
想要设计App的整体框架，首先要 清楚我们做的是什么
一般我们与网络交互数据的方式有两种：主动请求(http)，长连接推送
结合网络交互数据的方式来说一下我们开发的App的类型和特点：
数据展示类型的App：特点是页面多，需要频繁调用后端接口进行数据交互，以http请求为主；推送模块，IM类型App的IM核心功能以长连接为主，比较看重电量、流量消耗。手机助手类App：主要着眼于系统API的调用，达到辅助管理系统的目的，网络调用的方式以http为主。游戏：一般分为游戏引擎和业务逻辑，业务脚本化编写，网络以长连接为主，http为辅。
一般我们做的App都是类型1，简要来说这类app的主要工作就是：
1.把服务端的数据拉下来给用户展示
2.把用户在客户端修改的数据上传给服务端处理
所以这类App的网络调用相当频繁，而且需要考虑到网络差，没网络等情况下，App的运行，成熟的商业应用的网络调用一般是如下流程：
UI发起请求 - 检查缓存 - 调用网络模块 - 解析返回JSON / 统一处理异常 - JSON对象映射为Java对象 - 缓存 - UI获取数据并展示
这之中可以看到很明显职责划分，即：数据获取；数据管理；数据展示
确定了职责，就可以进入正题了
1. 传统的Android App架构
Android最原生也是最基础的架构，可以理解为MVC，Controller即是Activity和Fragment，但是这两者掌握了Android系统中绝大多数的资源，并且在内部直接控制View，因此传统的Android App一般是以Activity和Fragment为核心，将网络模块，数据库管理模块，文件管理模块，常用工具类等分离成若干工具类包，供Activity和Fragment使用。
这是比较基础的Android项目架构，市面上大部分App都是这种造型
优点：就是开发简单，以页面为导向；如果构建水平可以，项目就已经基本实现模块化，基于Activity，Fragment这这两个上帝般的存在，很多事情直接就妥了，不用绕。缺点：维护难，因为是以页面为导向的，有些需要共用的业务逻辑就会很烦，don’t repeat your self， 你要不要repeat ？不想repeat就要写模块，慢慢的项目就会多出一堆乱七八糟的小模块。另一方面，测试很困难，因为所有的数据处理都在Activity和Fragment，假如现在想先用假数据显示，就要直接改Activity和Fragment的数据控制逻辑。
2. 分层架构
如果仔细看自己的项目，可以发现绝大多数数据处理的代码是不需要使用Activity和Fragment持有的资源的（比如Context），而很多时候我们需要多个页面共用一套数据和请求逻辑，很经典的例子是应用中的User对象，一般来说都是全局单例。
这些全局的数据源写多了，很容易就能想到将数据处理统一抽出来形成一层，向上层提供数据接口，而上层并不关心数据的来源（内存，缓存，网络），因为不用从Activity和Fragment拿资源而且主要工作是数据处理，所以这一层是UI无关的，大幅提升了复用性，我把这一层称为DataManager层。
这是我一个项目的包结构
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<T> {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<Data> mDataList = new ArrayList<>();private int currentPage = 0;private int totalPage = 0;public PageLoadDataManager() {// init something......}public void loadData(final boolean refresh, ActionListener<Boolean> 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 <= totalPagelistener.onSuccess(hasMore);}}@Override public void onFailure(String message, Throwable e) {if (listener != null) {listener.onFailure(message, e);}}});}public List<Data> 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了
3. MVP 架构
MVC的C是即持有具体Model，又持有具体View，所以C很臃肿，分层架构就算抽出了DataManager，实质上仍然是一个MVC架构，而MVP和MVVM则是C持有具体View这个问题做了点文章，其中MVP就是将大量的View <-> Model 交互剥离出来交由Presenter，Presenter持有抽象的View。
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的一点看法，如果有小伙伴有比较好的实践经验，可以在评论告诉我。
4. MVVM 架构
MVVM相比于MVP，最重要的一个概念就是“数据绑定”，Presenter还持有抽象的View，ViewModel连这个都不需要，View通过ViewModel订阅其所需的数据源，ViewModel向View提供改变数据的接口，当View的操作引起数据改变或者数据源发生改变时，ViewModel通过订阅告知View，View进行视图更新。
这就是MVVM吸引人的地方，ViewModel只提供数据订阅和数据接口，做到了与UI分离，ViewModel体量比Presenter小，复用性要比Presenter强太多，而且基于分层架构可以做到小幅修改就能实现。唯一的痛点在于：如何实现数据绑定？
之前提到的data-binding，并不是那么如意，而这次Google I/O 放出的android-architecture-components则很好的解决了这个问题
ViewModel组件规范了ViewModel的所处地位，生命周期，生成方式，以及一个Activity下多个Fragment共享ViewModel数据的问题
LiveData组件则提供了在Java层面View订阅ViewModel数据源的实现方案，很轻量。
ViewModel的引入能够很好应对Activity销毁重建时大规模数据的恢复问题，以及多个界面依赖一个接口返回数据的场景，在这两个组件的规范下实现MVVM架构会十分容易，而且十分有意义。
最后
在技术领域内，没有任何一门课程可以让你学完后一劳永逸，只有不断提升才能不被时代淘汰。
如果你觉得自己学习效率低，缺乏正确的指导，可以扫描下方二维码，免费领取Android相关的学习资料，并有机会加入大牛交流群深入了解行业风向、精进专业技能，获得大厂内推机会！！
作者：0x8421bcd
链接：/question/45517397/answer/99293671
