Android 应用架构概述

作者: 大利猫 | 来源:发表于2016-01-03 16:26 被阅读3389次

通常一个App的成长过程都是这样的：

第一阶：先用最少的成本和时间快速把东西做出来。

第二阶段：积累一定用户量之后再小步快跑的迭代功能。

第三阶段：性能和体验上逐步求精。

我发现好多项目在第二阶段和第三阶段耗费了好多本来不应该浪费的人力成本、时间成本。究其原因就是因为前期忽略了合理的架构，我甚至经历过因为前期的设计不合理导致后期技术债务太多项目濒临死掉、整个项目组全员换掉重造锅炉的境地。所以，我们为什么不既能使用最简洁的方式实现功又能要保证后期灵活的扩展能力呢？下面是本人最近项目实践的一些整理，抛砖引玉，希望一起讨论。文章首发：http://www.liuguangli.win/archives/299。

视图和数据

好的代码一定是层次分明、职责分明，糟糕的代码架构就是没有层次没有模块，每次修改代码都是牵一发动全身。从大的方面来讲Android应用都会被分为两层：视图层、数据层。

数据和视图

视图：一般以Activity为依托的各种View，包含View、ViewGroup和WebView，还有各种fragment。

数据：支撑整个应用逻辑的数据，分为两类。一类存储在远端服务器上的，一类在本地。远端数据需要通过网络（通常是Http）获取，本地数据包括sqlite存储的关系型数据，文件系统，内存缓存对象。

必然联系

用数据驱动视图变化，这才产生了丰富多彩的应用交互世界，所以，视图和数据的联系是必然的。

视图数据的直接联系

在Android平台和整个移动开发生态都发展的非常快，在Android兴起之初，对层的重要性不是太强调，所有很多开始写Android程序的开发对层划分不是太清晰，看到很多入门书本里很多直接在Activity里面直接处理数据的代码，例如直接在Activity里面直接调SharedPrefrence操作数据，直接在Activity 里面直接调用网络请求等，很多初级选手的很容易写出这样没有层次的代码出来。当接口变更，当存储方式更好的时候整个UI层面的逻辑都受影响。

解耦

好一点的设计必然会做一次隔离：尽量做到UI和数据彼此透明、“互不干涉内政”。

解耦

隔离的好处是：一、提高可维护性。在UI逻辑发生变化甚至整个端掉都不会影响到处理逻辑。二、提高可复用性。复用通常只数据的复用，数据逻辑不受UI的左右，由此可以服务于多个UI视图。三、可读性。层次分清之后按照统一的架构思路去理解代码，当然还得靠开发人员良好的编程素养和代码规范。

那么怎么做到隔离呢？关于解耦，业内比统一的可以归纳为两种：MVC、MVP（MVVM）。

MVC解耦

mvc

V：在MVC架构中Activity（托管Fragment，View，WebView等）首先充当V的角色。

M：业务逻辑层划分出来专门处理数据。例如：数据的http请求，数据解析和储存等逻辑都封装在这一层。Activity不直接和Http，Dao（数据访问对象层）直接有联系了，视图数据从此为路人。

C：C是什么？MVC这个模式及概念，在移动应用开发出新之前就已经产生了，最经典的水用场景JSP +servlet+javabean，我开始接触MVC也是在做JavaWeb开发的时候。后来Android开发火了，把这套模式搬上来。但是C套上了不太好理解。Android应用开发中，套上MVC，Activity 兼具V和C的角色。

MVP解耦

很多时候视图层面还是充斥中很多复杂的逻辑，例如UI事件的响应处理，网络响应的回调等等，充斥着各种监听器的回调。我们期望视图V便当更简单、更纯粹，V只负责绘制和刷新其他逻辑都不用管了，也不想和M有直接的联系。从MVC的VC（Activity）中我们分离一层出来叫做Presenter，由它来负责调度UI何时刷新、由它来接受UI的事件响应并传达指令给M。从此V和M是路人，V和数据的距离跟远了。

mvp

V：Activity为代表，这时候的Activity更为简单了，只负责UI的绘制和刷新。

P：负责传达指令。向上接收V的事件指令并需要的时候传达给M，向下接收M的指令并通知V刷新UI。

M：只负责出来数据逻辑。其实还可以细分一些东西，比如Http请求，很多时候我们的Http框架都是用的第三方开源框架，如果有一天更优秀的框架出现了，要更换，怎么才能做到不影响其他层次？如果我门做了分层隔离那么，我门可以很轻松的换掉，如果没有做分层隔离，那么我门可能要在每一个功能模块的M中修改代码，修改代价是巨大的，所以一遍第三方开源框架我都不会直接使用而是在业务上做一层抽象隔离。同理，本地数据的存储，也有必要做响应的封装或隔离，因为今天是用Litepal，也许某一天想用GreenDao了，只需要修改封装类的代码就好了。

MVP的依赖关系：

MVP依赖关系

MVP类图：

MVP类图

我们把每一层都抽象成一个接口，例如V层，我们定义一个接口为View（不要和Android API里的View弄混了），让后Activity成为这个View的具体实现。每一层对另一层的依赖都是接口依赖，并不关心另一层的具体实现，每一层我们都可以写不同的实现，随时切换，这就意味着，有一天如果有一层不好用了，我们可以轻松的重写另一个实现来替换掉，而不是如履薄冰的修改。