[转]Android App总体架构设计的思考

1. 架构设计的目的

        对程序进行架构设计的缘由，归根究竟是为了提升生产力。经过设计使程序模块化，作到模块内部的高聚合和模块之间的低耦合。这样作的好处是使得程序在开发的过程当中，开发人员只须要专一于一点，提升程序开发的效率，而且更容易进行后续的测试以及定位问题。但设计不能违背目的，对于不一样量级的工程，具体架构的实现方式必然是不一样的，切忌犯为了设计而设计，为了架构而架构的毛病。举个简单的例子，一个Android App若是只有3个Java文件，那只须要作点模块和层次的划分就能够，引入框架或者架构反而提升了工做量，下降了生产力。但我当前开发的App最终代码量应该在10W行以上，本地须要进行复杂操做，同时也须要考虑到与其他的Android开发者以及后台开发人员之间的同步配合，那就须要在架构上进行一些思考。

2. 基于MVP的架构设计思路

        在App开发过程当中，常常出现的问题就是某一部分的代码量过大，虽然作了模块划分和接口隔离，但也很难彻底避免。从实践中看到，这更多的出如今UI部分，也就是Activity里。我曾见过2000+行以上基本不带注释的Activity，那时个人第一反应就是想吐。Activity内容过多的缘由其实很好解释，由于Activity自己须要担负与用户之间的操做交互，再加上如今大部分的Activity还对整个App起到控制器的做用，这又带入了大量的逻辑代码，形成Activity的臃肿。为了解决这个问题，咱们引入了MVP框架思路。

2.1 什么是MVP?

        MVP是一种使用普遍的基础架构模式，使用基于事件驱动的应用框架。MVP从更早的MVC框架演变过来的一种框架，与MVC有必定的类似性。MVP框架由3部分组成：View负责显示，Presenter负责逻辑处理，Model提供数据。MVP与MVC之间最主要的区别在控制层上，在MVP框架中，View与Model并不直接交互，全部的交互放在Presenter中；而在MVC里，View与Model会直接产生必定的交互。MVP的Presenter是框架的控制者，承担了大量的逻辑操做，而MVC的Controller更多时候承担一种转发的做用。所以在App中引入MVP的缘由，是为了将此前在Activty中包含的大量逻辑操做放到控制层中，避免Activity的臃肿。MVP的变种有不少，其中使用最普遍的是Passive View模式，即被动视图。在这种模式下，整个框架内部模块之间的逻辑操做均由Presenter控制，View仅仅是整个操做的汇报者和结果接收者，Model根据Presenter的单向调用返回数据(图片来自网络)。而且MVP模式使得View与Model的耦合性更低，下降了Presenter对View的依赖，实现了关注点分离的初衷，方便开发人员的编码和测试工做。

                                        

        具体到Android App中，我通常将App根据程序的结构进行纵向划分，对应MVP分别为模型层，UI层和逻辑层。UI层通常包括Activity，Fragment，Adapter等直接和UI相关的类，UI层的Activity在启动以后实例化相应的Presenter，App的控制权后移，由UI转移到Presenter，二者之间的通讯经过BroadCast、Handler或者接口完成，只传递事件和结果。举个简单的例子，UI层通知逻辑层（Presenter）用户点击了一个Button，逻辑层（Presenter）本身决定应该用什么行为进行响应，该找哪一个模型（Model）去作这件事，最后逻辑层（Presenter）将完成的结果更新到UI层。

2.2 MVP架构存在的问题

        转移逻辑操做以后可能部分较为复杂的Activity内代码量仍是很多，因而在分层的基础上再加入模板方法（Template Method）。具体作法是在Activity内部分层。其中最顶层为BaseActivity，不作具体显示，而是提供一些基础样式，Dialog，ActionBar在内的内容，展示给用户的Activity继承BaseActivity，重写BaseActivity预留的方法。若有必要再进行二次继承，App中Activity之间的继承次数最多不超过3次。

        模型层（Model）中的总体代码量是最大的，通常由大量的Package组成，针对这部分须要作的就是在程序设计的过程当中，作好模块的划分，进行接口隔离，在内部进行分层。

        强化Presenter的做用，将全部逻辑操做都放在Presenter内也容易形成Presenter内的代码量过大，对于这点，个人方法是在UI层和Presenter之间设置中介者Mediator，将例如数据校验、组装在内的轻量级逻辑操做放在Mediator中；在Presenter和Model之间使用代理Proxy；经过上述二者分担一部分Presenter的逻辑操做，但总体框架的控制权仍是在Presenter手中。Mediator和Proxy不是必须的，只在Presenter负担过大时才建议使用。最终的架构以下图所示：

                                               

知乎上个人回答连接：从零开始开发一款Android app，前期须要哪些规划工做避免代码臃肿混乱？

 

接上文：Android App总体架构设计的思考(一) ，本文主要介绍AOP以及一些快速开发框架。

3 基于AOP的框架设计

        AOP(Aspect-Oriented Programming, 面向切面编程)，诞生于上个世纪90年代，是对OOP(Object-Oriented Programming, 面向对象编程)的补充和完善。OOP引入封装、继承和多态性等概念来创建一种对象层次结构，用以模拟公共行为的一个集合。当咱们须要为分散的对象引入公共行为的时候，OOP则显得无能为力。也就是说，OOP容许你定义从上到下的关系，但并不适合定义从左到右的关系。例如日志功能。日志代码每每水平地散布在全部对象层次中，而与它所散布到的对象的核心功能毫无关系。对于其余类型的代码，如安全性、异常处理和透明的持续性也是如此。这种散布在各处的无关的代码被称为横切（Cross-Cutting）代码，在OOP设计中，它致使了大量代码的重复，而不利于各个模块的重用。而AOP技术则偏偏相反，它利用一种称为“横切”的技术，剖解开封装的对象内部，并将那些影响了多个类的公共行为封装到一个可重用模块，并将其名为“Aspect”，即方面。所谓“方面”，简单地说，就是将那些与业务无关，却为业务模块所共同调用的逻辑或责任封装起来，便于减小系统的重复代码，下降模块间的耦合度，并有利于将来的可操做性和可维护性。

                                                                  

3.1 AOP在Android中的使用

        AOP把软件系统分为两个部分：核心关注点和横切关注点。业务处理的主要流程是核心关注点，与之关系不大的部分是横切关注点。横切关注点的一个特色是，他们常常发生在核心关注点的多处，而各处都基本类似。AOP的做用在于分离系统中的各类关注点，将核心关注点和横切关注点分离开来。在Android App中，哪些是咱们须要的横切关注点？我的认为主要包括如下几个方面：Http, SharedPreferences, Json, Xml, File, Device, System, Log, 格式转换等。Android App的需求差异很大，不一样的需求横切关注点必然是不同的。通常的App工程中应该有一个Util Package来存放相关的切面操做，在项目多了以后能够将其中使用较多的Util封装为一个Jar包供工程调用。

4 总结

        在使用MVP和AOP对App进行纵向和横向的切割以后，可以使得App总体的结构更清晰合理，避免局部的代码臃肿，方便开发、测试以及后续的维护。目前不少尚停留在实践和思想，今年上半年会抽时间写一个基于MVP、AOP和IOC的Android框架。

 

5 快速开发框架

        目前网络上也有一些针对Android的快速开发框架，下面介绍3个主要的快速开发框架。针对这些快速开发框架，我的认为能够参考，但并不推荐使用，由于App总体依赖一个我的维护的框架风险实在太大，框架存在一些学习成本，自己也不必定彻底符合App的需求，使用后的收益并无想象中大。

5.1 Afinal

        Afinal是一个Android的IOC，ORM框架，内置了四大模块功能：FinalAcitivity, FinalBitmap, FinalDb, FinalHttp。经过FinalActivity，能够经过注解的方式进行绑定UI和事件。经过FinalBitmap，能够方便的加载Bitmap图片，而无需考虑OOM等问题。经过FinalDB模块，经过一行代码就能够对Android的SQlite数据库进行增删改查。经过FinalHttp模块，能够以Ajax形式请求Http数据。

GitHub项目地址：Afinal

5.2 xUtils

        xUtils目前主要包括4大模块：DbUtils, ViewUtils, HttpUtils, BitmapUtils。包含了不少实用的Android工具；支持大文件上传，更全面的Http请求协议支持，拥有更加灵活的ORM，更多的事件注解支持且不受混淆影响；最低兼容Android 2.2 (Api Level 8)。

GitHub项目地址：xUtils

5.3 ThinkAndroid

        ThinkAndroid是一个免费的开源的、简易的、遵循Apache2开源协议发布的Android开发框架，其开发宗旨是简单、快速的进行 Android应用程序的开发，包含Android MVC、简易SQlite ORM、IOC模块、封装Android HttpClitent的Http模块, 具备快速构建文件缓存功能，无需考虑缓存文件的格式，均可以很是轻松的实现缓存，它还基于文件缓存模块实现了图片缓存功能， 在Android中加载的图片的时候，对OOM的问题，和对加载图片错位的问题都轻易解决。他还包括了一个手机开发中常常应用的实用工具类， 如日志管理，配置文件管理，Android下载器模块，网络切换检测等等工具。

GitHub项目地址：ThinkAndroid

参考目录： AOP技术基础

                   从三层架构到MVC, MVP

                   MVC, MVP以及Model2

                   GOF等。