于炳虎

摘要：近两年，随着智能手机的普及和移动互联网的兴起，带动了移动应用市场的快速发展，移动APP逐渐成为互联网用户新入口，重要性越来越突出，用户对APP产品的功能性和非功能性的要求也越来越高。然而，随着大批APP应用的涌入市场，问题却逐渐凸显，众多APP架构的先天不足直接影响了产品的功能性和稳定性，逐渐成为APP长期发展的瓶颈。本文从APP整体架构角度，将分析与设计相结合，阐述如何进行移动应用的整体构建，为后续广大移动应用领域的APP开发者奠定架构基础，提供参考价值。

关键词：APP应用；整体架构；架构设计

中图分类号：TP311.52 文献标识码：A 文章编号：1007-9416（2017）01-0133-03

1 引言

移动互联网技术的不断创新，带动了移动互联网市场的快速蓬勃发展。凯度中国观察最近发布了2016年前三季度移动操作系统占有率报告，该报告显示，全球Android手机的市场份额上升至87.5%，用户的海量增长，致使APP应用市场“一片繁荣”，新的App更是层出不穷，今年1月份的数据显示，以Android系统为主的Google Play应用商店，APP数量超过140万，我们的日常生活已然被移动APP淹没了，越来越多的APP改变了人们以往的生活方式和消费方式。

APP应用软件数量已经多到不可计数，并且每天还有数以万计的APP软件不断上新到应用市场，但是很多APP产品较为注重眼前利益，只注重前期用户的快速积累和圈钱，而APP在设计开发之初，没有重视产品的功能架构与后期的更新维护，导致产品在功能、性能和稳定性等方面存在很大的问题和隐患，用户在使用的过程中体验较差，用户粘性较低，用户逐渐流失。为此，本文提出一套基于Android系统的APP开发整体架构方案，旨在提高App产品的整体质量和用户体验，为后续广大移动应用领域的APP开发者奠定架构基础。

2 UI架构设计模式分析

移动产品的用户体验和交互体验可以说是这个产品的灵魂，UI作为与用户最为直接的交互层，直接影响着用户的使用体验，而这里的UI架构包含的不仅仅只是展示层，还有业务层和数据层，这是一个完整的UI架构体系。Android应用开发的UI架构设计模式历经了MVC、MVP到MVVM的演进，前期的架构设计承载着整个软件的设计思想和关键决策，架构模式是面向开发者的，它在一定程度上存在性能的损耗，但在开发过程中具有更好的代码可阅读性、可测试性和可维护性。

2.1 MVC

MVC全名是Model View Controller，是模型（Model）、视图（View）、控制器（Controller）的缩写，是软件架构中最常见的一种框架，并且是经典的框架模式之一，它在多个开发领域中都有广泛的应用，尤其在Java EE领域。MVC简单来说就是通过Controller的控制去操作Model层的数据，并且返回给View层展示，MVC架构设计见图1所示。

MVC模式的最大优势是将视图的展示与数据处理和业务逻辑相分离，视图层只需关注UI的展示。在Android应用开发中，业务逻辑和数据处理等担任了Model角色，XML布局文件等担任了View角色，Activity和Fragment担任了Controller角色。控制器的角色可以看作一个中间桥梁的作用，通过接口通信来协同 View（视图）和Model（模型）工作，起到了两者之间的通信作用。控制器还起到了一定解耦的作用，将View视图和Model模型分离，但是在Activity中依然有很多关于视图UI的显示代码，可见View视图和Activity控制器并不是完全分离的，也就是说一部分View视图和Controller控制器Activity是绑定在一个类中的。

MVC在Web开发中使用极为广泛，但使用在Android中，问题还是较多的，xml布局文件作为视图层，控制能力较弱，如果动态的去改变界面，只能把代码写在Activity中，这就造成了Activity既是Controller层，又是View层的这样一个窘境。MVC还有一个重要的缺陷，图1可以看到，View层和Model层是相互可知的，这意味着两层之间存在耦合，虽然控制器起到了一定的解耦作用，但也只是在一定程度上，耦合对于一个大型程序来说是非常致命的，因为这表示开发，测试，维护都需要花大量的精力。

2.2 MVP

MVP是模型（Model）、视图（View）、主持人（Presenter）的缩写，分别代表项目中3个不同的模块。MVP作为MVC的演化，更适用在移动应用的开发中，解决了MVC存在的缺点，对于Android来说，MVP的Model层相对于MVC是一样的，而Activity和Fragment不再是Controller层，而是纯粹的View层，所有关于用户事件的转发全部交由Presenter层处理。

图2是MVP的设计模式图，从图中可以看出，与MVC最明显的差别就是View层和Model层是不连通的，做到了完全的解耦，当View层某个界面需要展示某些数据的时候，首先会调用Presenter层的接口，然后Presenter层会调用Model层请求数据，当Model层数据加载成功之后会调用Presenter层的回调方法通知Presenter层数据加载完毕，最后Presenter层再调用View层的接口将加载后的数据展示给用户。这就是MVP模式的整个核心过程。

在整个过程中，Presenter层充当了桥梁的作用，View层和Model层完全没有联系。在层与层的通信交互中，主要是通过接口和回调机制实现的。这样分层的好处就是大大减少了Model与View層之间的耦合度。一方面可以使得View层和Model层单独开发与测试，互不依赖。另一方面Model层可以封装复用，可以极大的减少代码量。不仅如此，还可以编写测试用的View，模拟用户的各种操作，从而实现对Presenter的测试。在MVC模式中测试和维护较难解决的问题，在MVP中都解决了。

2.3 MVVM

Android应用中的MVVM是在2015年Google的IO大会上推出的。提到MVVM，大多数开发者都会想Data Binding，Data Binding是Google官方推出的一个基于MVVM设计模式实现的框架，MVVM可以实现视图和逻辑代码的超级解耦，按照Google的说法，使用了MVVM的开发模式，还可以提高布局文件的解析速度。从图3中可以看到，MVVM和MVP的结构上区别不大，Presenter层换成了ViewModel层，View层和ViewModel层是相互绑定的关系，这意味着当更新ViewModel层的数据的时候，View层的UI会相应的变动。

在MVVM设计模式中，通过ViewModel和View的映射，完成了View和Model的双向绑定。View的事件直接传递到ViewModel，ViewModel去对Model进行操作并接受更新。进而反馈到View上。相比于MVP去掉了Presenter，但View层略显过重，同时View的复用成为了一个新的问题。

2.4 分析比较

经过上面的分析，可见MVC已不太适用Android等移动应用的开发设计中了，相比来说MVP和MVVM是更适合在移动应用的开发中使用，MVP和MVVM这两个MVC的升级延续孰优孰劣，并没有结论，还是要根据具体的项目、具体产品来分析。

3 整体架构的设计与实现

优秀的APP架构应该具有清晰的层次划分，功能模块划分和业务逻辑划分，同一层模块间充分解耦，模块内部高内聚，各分层设计符合面向对象设计六大原则，提高程序的封装性、复用性、可维护性，最后应该在功能，性能，稳定性等方面达到综合最优。基于此，APP架构可分为四层，如图4所示，最顶层是应用层，是面向用户的第一层，然后是应用组件层，提供了封装组件服务，再下是基础组件层，为APP提供基础功能组件，最下面是系统层，直接面向系统底层开发。

3.1 应用层

应用层专注于业务领域的实现，与需求的业务功能关联，直接面向用户，是用户对产品感知的第一层，应用层包含以下细分的三层，如图5所示。

（1）视图层，与用户直接交互的界面，是用户和系统之间交流的橋梁，它一方面为用户提供了交互的工具，另一方面也为显示和数据处理实现了一定的逻辑，协调用户和系统的操作。（2）业务层，包含了APP需要的所有功能上的算法和逻辑处理，并与数据层和视图层交互。抽象的说，业务层是处理与业务相关的部分，包含一系列的执行与数据的操作。（3）数据层，提供访问数据的功能，在分层设计中，所有读取数据或写入数据的工作都属于这一层的任务，不做过多的数据逻辑处理，操作的是非原始数据。

3.2 应用组件层

应用组件层为上层封装业务功能，以服务的表现形式提供，不涉及UI和平台的特性，应用组件层的服务是独立的，可移植的，不依赖特定的开发和使用环境，如图6所示，主要包括有社交分享、推送服务、扫码组件、键盘组件、手势密码等。

3.3 基础组件层

基础组件是相对于业务功能来说的，它是对复用率比较高的代码的一种抽离，它提供APP的公有特性，实现依赖特定的平台环境，这一层也是用户对产品的一种感知，这种感知表现在稳定性、性能等方面，直接关系到产品的用户体验。如图7所示主要包括有数据库操作、网络通信处理、日志记录、图片缓存、数据解析（JSON/XML）、加解密等。

3.4 系统层

系统层主要是基于底层的一些系统模块，如图8所示，主要包括进程通信、线程管理、内存管理、消息处理等，在Android APP的开发中，进程和内存的管理是较难处理的，Android采取了一种有别于Linux的进程管理策略，在进程活动停止后并不立刻结束该进程，Android把这些进程都保留在内存中，直到系统需要更多内存为止。这些保留在内存中的进程通常情况下不会影响整体系统的运行速度，并且当用户再次激活这些进程时，提升了进程的启动速度，Android其实已经为开发者做好了很多事情，系统层的开发应多参考源码标准。

4 关键技术实现

4.1 应用层

应用层作为与用户交互的第一层，直接影响着用户的交互体验，因此采用成熟的设计框架更为稳妥，本文分析了Android中常用的UI设计架构模式，MVC的设计思想是从Model出发，而没有考虑到View端的复杂性，这样导致的问题是Model难以符合复杂多变的View端变化。相对这点，MVP和MVVM就要好得多。它们都独立出了Presenter 和ViewModel来对应每个View。MVP模式是一个真正意义上的隔离View的细节和复杂性的模式，在MVP模式中的V代表的是一个接口，一个将UI界面提炼而抽象出来的接口。接口意味着任何实现了该接口的界面，都能够复用已有的Presenter和Model代码。在MVVM模式中，一个ViewModel和一个View匹配，它没有MVP中的IView接口，而是完全的和View绑定，所有View中的修改变化，都会自动更新到ViewModel中，同时ViewModel的任何变化也会自动同步到View上显示。MVP与MVVM两者没有严格的好坏之分，在具体选择实现时，还是要要具体分析APP的需求复杂度和具体的业务场景。

4.2 应用组件层

应用组件层为上层封装业务功能，以服务的表现形式提供，社交分享、推送服务等，它们的实现最简单的方式就是使用第三方平台，具体的整合，第三方平台都已经提供了很完善的API接口文档。同时补充一点，事件总线也分布在此层，在Android系统中，事件总线简化了Activity、Fragment、Service等组件之间的交互，很大程度上降低了它们之间的耦合，使得我们的代码更加简洁，耦合性更低，提升我们的代码质量。

4.3 基础组件层

基础组件层提供APP的公有特性，数据库操作是应尽量使用ORM框架，ORM是一种程序设计技术，用于实现面向对象编程语言里不同类型系统的数据之间的转换。现在较为成熟的是ORMLite与GreenDao。网络、图片、JSON等的处理，依靠成熟的框架是较为明智的选择。日志记录是一个基础且极为重要的组件，可帮助开发人员代码调试，快速错误定位，Android系统中提供了Log类来记录日志，使用起来方便简单，也可以使用功能更为强大的开源日志记录库Logger，具体的选择依赖于开发者的使用习惯。

4.4 系统层

系统层的开发更偏向于Linux环境开发，Android系统是以Linux内核为基础，所以对于进程的管理自然离不开Linux本身提供的机制。在Android系统中，进程可以大致分为系统进程和应用进程两大类，开发者更多关注的是应用进程，Android应用程序是通过消息来驱动的，系统为每一个应用程序维护一个消息队列，应用程序的主线程不断地从这个消息队列中获取消息，然后对这些消息进行处理，这样就实现了通过消息来驱动应用程序的执行。系统层的开发实现，Android提供了较为丰富的实现方式，包括上层Java的封装实现，和下层C/C++的底层实现。本文不再详细介绍。

5 结语

本文通过一系列的分层与整合，剥离和组合等方式优化了APP应用的整体架构，在关键技术实现上，本文也给出了一定的技术指导。在应用的设计开发中使用分层架构模式，一方面能提高APP的功能性、稳定性和可维护性，另一方面提高了用户的产品使用体验，这样才能促使APP产品长期发展下去。