Android应用架构前世今生

前言

Android的开发生态系统发展迅速，在开发Android的几年的时间里，用来构建Android应用的架构与技术一直在不断进化。随着项目的不断更新迭代，应用的架构也有不一样的变化。由于开发人员的数量、项目的业务复杂度、需求的开发时间、应用的使用量级，使用的技术架构也不相同。没有最好的架构，只有最合适的。通过设计使程序模块化，做到模块内部的高聚合和模块之间的低耦合。这样做的好处是使得程序在开发的过程中，开发人员只需要专注于一点，提高程序开发的效率，便于项目的后期维护。下面总结及汇总一下目前Android使用的主要应用架构及其优缺点和使用的学习心得，如有不对之处，欢迎交流纠正。

mvc

还记得以前学生时代学习.NET的时候，第一次接触到项目架构叫三层架构。应用层、业务逻辑层及数据访问层。mvc的思想其实也一样，都是一种软件设计典范，用一种业务逻辑、数据、界面显示分离的方法组织代码，在改进和个性化定制界面及用户交互的同时，不需要重新编写业务逻辑。Android的项目设计本身也是采用了mvc的设计思想。

视图层(View)

一般采用XML文件进行界面的描述，使用的时候可以非常方便的引入。同时便于后期界面的修改。逻辑中与界面对应的id不变化则代码不用修改，大大增强了代码的可维护性。

控制层(Controller)

Android的控制层主要就是Activity层。相关View层交互触发及数据展示逻辑都在Activity中进行编码。

模型层(Model)

我们通常针对业务数据，都会定义好对应的Model层。数据库的操作、对网络等的操作都应该在Model里面处理，当然对业务计算等操作也是必须放在的该层的

所以一直以来我们使用Android默认的项目结构开发，主要都是在采用mvc的架构思想。

优点：适用了简单的页面展示，业务逻辑不复杂。开发效果高，代码层级也简单易懂

缺点：当业务复杂时，Activity非常臃肿，不便于维护及测试

mvp

mvp这是目前我们项目中主要采用的应用架构方式，MVP从更早的MVC框架演变过来，与MVC有一定的相似性：Controller/Presenter负责逻辑的处理，Model提供数据，View负责显示。mvp架构的演变，解决了Activity代码臃肿的问题，当我们将Activity复杂的逻辑处理移至另外的一个类（Presenter）中时，Activity其实就是MVP模式中的View，它负责UI元素的初始化，建立UI元素与Presenter的关联（Listener之类），同时自己也会处理一些简单的逻辑（复杂的逻辑交由 Presenter处理）。项目开发中，UI是容易变化的，且是多样的，一样的数据会有N种显示方式；业务逻辑也是比较容易变化的。为了使得应用具有较大的弹性，我们期望将UI、逻辑（UI的逻辑和业务逻辑）和数据隔离开来，而MVP是一个很好的选择。在MVP模式里通常包含3个要素（加上View interface是4个）：

View:负责绘制UI元素、与用户进行交互(在Android中体现为Activity)

Model:负责存储、检索、操纵数据(有时也实现一个Model interface用来降低耦合)

Presenter:作为View与Model交互的中间纽带，处理与用户交互的负责逻辑。

View interface:需要View实现的接口，View通过View interface与Presenter进行交互，降低耦合，方便进行单元测试

优点：

1. Model与View完全分离，修改互不影响

2. 更高效地使用，因为所有的逻辑交互都发生在一个地方—Presenter内部

3. 一个Preseter可用于多个View，而不需要改变Presenter的逻辑（因为View的变化总是比Model的变化频繁）。

4. 更便于测试。把逻辑放在Presenter中，就可以脱离用户接口来测试逻辑（单元测试）

缺点：需要拿捏好Presenter、View interface的颗粒度设计，容易出现Presenter过于简单或则复杂化。

mvvm

MVVM可以算是MVP的升级版，其中的VM是ViewModel的缩写，ViewModel可以理解成是View的数据模型和Presenter的合体，ViewModel和View之间的交互通过Data Binding完成，而Data Binding可以实现双向的交互，这就使得视图和控制层之间的耦合程度进一步降低，关注点分离更为彻底，同时减轻了Activity的压力。

View（视图层）采用XML文件进行界面的描述；

Model（模型层）通过网络和本地数据库获取视图层所需数据；

ViewModel（视图-模型层）负责View和Model之间的通信，以此分离视图和数据。

View和Model之间通过Android Data Binding技术，实现视图和数据的双向绑定；ViewModel持有Model的引用，通过Model的方法请求数据；获取数据后，通过Callback（回调）的方式回到ViewModel中，由于ViewModel与View的双向绑定，使得界面得以实时更新。同时，界面输入的数据变化时，由于双向绑定技术，ViewModel中的数据得以实时更新，提高了数据采集的效率。

采用ViewModel解决MVP中View(Activity)和Presenter相互持有对方应用的问题，界面由数据进行驱动，响应界面操作无需由View(Activity)传递，数据的变化也无需Presenter调用View(Activity)实现，使得数据传递的过程更加简洁，高效。

推荐教程：精通 Android Data Binding（https://github.com/LyndonChin/MasteringAndroidDataBinding）

优点：

双向绑定技术，当Model变化时，View-Model会自动更新，View也会自动变化。很好做到数据的一致性

Google官方支持databing，易于集成

缺点：

数据绑定使得 Bug 很难被调试

数据双向绑定不利于代码重用及扩展

代码的阅读性降低

android-architecture

google在官方示例中给出了一系列不同架构的app实现，项目目的是通过展示各种架构app的不同方式来帮助开发者解决架构问题。项目中通过不同的架构概念及方式实现了功能相同的app。

Google官方MVP架构示例项目（https://github.com/googlesamples/android-architecture）

TODO-MVP-RXJAVA

使用RXJAVA对数据流进行处理，并且通过Repository进行数据的集中管理，通过协议类XXXContract来对View和Presenter的接口进行内部继承，在presenter的实现类中，可以对Model数据进行操作。实例中，数据的获取、存储、数据状态变化都是model层的任务，presenter会根据需要调用该层的数据处理逻辑并在需要时将回调传入。这样model、presenter、view都只处理各自的任务，实现单一责任原则。

推荐教程：

Google官方MVP+Rxjava项目详解（https://www.jianshu.com/p/e469467a903b）

组件化

随着项目的推进，及企业业务的发展。有一天可以发现团队内部需要开发多个APP，且多个APP中存在相同的业务模块，一开始的做法为了赶项目进度可能就是黏贴复制，到后面就慢慢发现越来越吃力，重复劳动。

慢慢随着时间的推移，恶性循环。慢慢发现项目代码结构混乱、层次不清，各业务技术方案不统一；甚至连基本的包结构也是胡乱不堪，都是不停地往上堆砌代码添加新功能，前人挖坑后人填。可见组件化对于不断迭代的项目有着深远的意义。

1. 避免重复造轮子，提高开发效率

2. 减低耦合度，提高复用性

3. 保持团队的技术方案统一性

4. 便于维护升级

基础组件化

通常项目中常用的结构如下：

看似没什么问题，但通常我们的一些库都是以代码的形式集成在代码中，随着项目推进，慢慢发现一些比较严重的问题。

1. 业务代码侵入组件代码中 （例如一些全局的网络返回响应，直接在库中编码等）

2. 团队内部没约束，各自集成不同的基础库（例如图片加载有的用Glide，有的用ImageLoader）

3. 部分第三方组件停止更新，项目代码耦合高，替换新方案难

所以在实际设施组件化的过程中，建议参考：

1. 独立library库（Common基础组件），避免在主工程中直接以代码集成，使用aar方式引用

2. 第三方的库调用最好再装一层接口，以便后续维护升级

3. 有成员专门负责维护，可以以SDK的方式提供业务层的调用

业务模块化

随着项目逻辑不断的增加，慢慢是不是发现代码编译速度是不是越来越慢？（PS：我们目前项目编译一次2分钟，且已是经过一些优化处理）

另外当团队内部有多个项目时，是不是经历过产品经理让你把项目A的某个功能移到项目B去，这个时候… …

业务模块化的作用性就很明显了

1. 业务模块间避免耦合，提高复用性

2. 业务模块独立编译运行

推荐教程：

DDComponentForAndroid（https://github.com/luojilab/DDComponentForAndroid）

Android彻底组件化方案实践（https://www.jianshu.com/p/1b1d77f58e84）

思考

项目架构都是不断演进，不是一蹴而就

没有最好的架构，只有在适当的时机，最合适的架构

项目重构过程是艰难的，但长痛不如短痛