前言

想要设计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 2017放出的android-architecture-components则很好的解决了这个问题

ViewModel组件规范了ViewModel的所处地位，生命周期，生成方式，以及一个Activity下多个Fragment共享ViewModel数据的问题
LiveData组件则提供了在Java层面View订阅ViewModel数据源的实现方案，很轻量。

ViewModel的引入能够很好应对Activity销毁重建时大规模数据的恢复问题，以及多个界面依赖一个接口返回数据的场景，在这两个组件的规范下实现MVVM架构会十分容易，而且十分有意义。

最后

在技术领域内，没有任何一门课程可以让你学完后一劳永逸，只有不断提升才能不被时代淘汰。

如果你觉得自己学习效率低，缺乏正确的指导，可以扫描下方二维码，免费领取Android相关的学习资料，并有机会加入大牛交流群深入了解行业风向、精进专业技能，获得大厂内推机会！！

作者：0x8421bcd
链接：https://www.zhihu.com/question/45517397/answer/99293671

Android项目开发如何设计整体架构？相关推荐

android最新面试题及答案，Android项目开发如何设计整体架构
首先,讲讲为什么我们要讲JAVA的语言进阶,从整体来讲,Java和Android的区别在于Android程序是基于组件和配置的,而且Android开发以Java语言为开发工具,表面上看他们有点同宗不同 ...
Android项目开发如何设计整体架构？大牛最佳总结
前言金九银十面试季,相信大家肯定急需一套Android面试宝典,今天小编就给大家准备了我珍藏已久的Android高阶面试宝典,一份超级详细的Android面试必备知识点,供大家学习 ! 想必每一个安 ...
Android项目开发如何设计整体架构？深夜思考
概述想了很久怎么样可以让文章的标题不那么悲观,但是各种文案都在我脑海里面不断的被否定,要么是不那么抓眼球,要么是立意不匹配.最后想了想,这个标题是真的符合我最近的感悟. 希望看过文章,能有同感的朋友 ...
Android程序员的春天！Android项目开发如何设计整体架构？太香了
前言随着移动网络的不断升级,客户端的网络传输由3G进化到Wifi.4G.5G,且Wifi场景越来越多.虽然网络环境在变好,但也对网络的应用提出了更高的要求,会发现很多大厂都十分重视网络指标,如果技术 ...
Java项目开发如何设计整体架构
一.前言最近刚读完一本书:<Netty.Zookeeper.Redis 并发实战>,个人觉得 Netty 部分是写得很不错的,读完之后又对 Netty 进行了一波很好的复习(之前用 sp ...
Android实训内容及过程,Android项目开发实训大纲.doc
Android项目开发实训大纲Android项目开发实训大纲黎明职业大学信息与电子工程学院 <Android项目开发> 实训指导书 2014年6月 <Android项目开发> ...
Swift项目开发实战-基于分层架构的多版本iPhone计算器-直播公开课
Swift项目开发实战-基于分层架构的多版本iPhone计算器-直播公开课本课程采用Q Q群直播方式进行直播,价值99元视频课程免费直播.完整的基于Swift项目实战,手把手教你做一个Swift版i ...
Android项目开发—GeoQuiz
Android项目开发-GeoQuiz 应用规划确定功能必须的界面及界面跳转的流程 ... 界面设计主界面确定模块界面.列表.查看.编辑界面添加需要的组件 ... 数据操作和存储业务实现 ...
Android项目开发：指南针（两种方法实现）
Android项目开发:指南针应用的实现 1.基于方向传感器 activity_main.xml MainActivity.java 2.基于加速度传感器和地磁传感器在Android中可以使用内置传 ...

Android项目开发如何设计整体架构？

前言

1. 传统的Android App架构

2. 分层架构

3. MVP 架构

4. MVVM 架构

最后

Android项目开发如何设计整体架构？相关推荐

最新文章

热门文章