Android架构重构

转自&＃xff1a;http://keeganlee.me/post/architecture/20160303

去年10月底换到了新公司&＃xff0c;做移动研发组的负责人&＃xff0c;刚开始接手android项目时&＃xff0c;发现该项目真的是一团糟。首先是其架构&＃xff0c;是按功能模块进行划分的&＃xff0c;本来按模块划分也挺好的&＃xff0c;可是&＃xff0c;他却分得太细&＃xff0c;总共分为了17个模块&＃xff0c;而好几个模块也就只有两三个类而已。但应用本身其实比较简单&＃xff0c;要按功能模块来分的话&＃xff0c;最多五个模块就够了。另外&＃xff0c;有好多模块划分也很模糊&＃xff0c;也有很多类按其功能其实可以属于多个模块的&＃xff0c;也有些类定义不明确&＃xff0c;做了不该做的事。有时候&＃xff0c;我要找一个界面的Activity&＃xff0c;按照其功能应该属于A模块的&＃xff0c;可是在A模块里却找不到&＃xff0c;于是&＃xff0c;我只好去AndroidManifest文件里找了&＃xff0c;找到才发现原来在B模块里。也有时候&＃xff0c;我要找另一个界面的Activity&＃xff0c;可我看遍了所有模块&＃xff0c;也没看出这个界面应该属于哪个模块&＃xff0c;没法子&＃xff0c;又只能去AndroidManifest文件里找了&＃xff0c;找到才发现竟然在C模块里。代码也是又乱又臭&＃xff0c;导致出现一大堆bug又不好找&＃xff0c;改好一个bug又出现另一个。整个项目从架构到代码都是又臭又乱&＃xff0c;开发人员只是不停地改bug&＃xff0c;根本没法做新功能&＃xff0c;更别谈扩展了。当时&＃xff0c;公司已经有为不同客户定制化app的需求&＃xff0c;而现有的架构完全无法满足这样的需求。因此&＃xff0c;我决定重构&＃xff0c;搭建一个易维护、易扩展、可定制的项目。

我将项目分为了四个层级&＃xff1a;模型层、接口层、核心层、界面层。模型层定义了所有的模型&＃xff1b;接口层封装了服务器提供的API&＃xff1b;核心层处理所有业务逻辑&＃xff1b;界面层就处理界面的展示。几个层级之间的关系如下图所示&＃xff1a;

下面展开说明具体的每个层次&＃xff1a;

接口层

接口层封装了网络底层的API&＃xff0c;并提供给核心层调用。刚开始&＃xff0c;为了简单&＃xff0c;该层的核心类我只定义了4个&＃xff1a;

1. PostEngine&＃xff0c;请求引擎类&＃xff0c;对请求的发送和响应结果进行处理&＃xff1b;
2. Response&＃xff0c;响应类&＃xff0c;封装了Http请求返回的数据结构&＃xff1b;
3. Api&＃xff0c;接口类&＃xff0c;定义了所有接口方法&＃xff1b;
4. ApiImpl&＃xff0c;接口实现类&＃xff0c;实现所有接口方法。

PostEngine将请求封装好发送到服务器&＃xff0c;并对响应结果的json数据转化为Response对象返回。Response其实就是响应结果的json数据实体类&＃xff0c;json数据是有固定结构的&＃xff0c;分为三类&＃xff0c;如下&＃xff1a;

event为返回码&＃xff0c;0表示成功&＃xff0c;msg则是返回的信息&＃xff0c;obj是返回的单个数据对象&＃xff0c;objList是返回的数据对象数组&＃xff0c;currentPage表示当前页&＃xff0c;pageSize则表示当前页最多对象数量&＃xff0c;maxCount表示对象数据总量&＃xff0c;maxPage表示总共有多少页。根据此结构&＃xff0c;Response基本的定义如下&＃xff1a;

每个属性名称都要与json数据对应的名称相一致&＃xff0c;否则无法转化。obj和objList用泛型则可以转化为相应的具体对象了。

Api接口类定义了所有的接口方法&＃xff0c;方法定义类似如下&＃xff1a;

ApiImpl则实现所有Api接口了&＃xff0c;实现代码类似如下&＃xff1a;

实现中将请求参数和返回的类型定义好&＃xff0c;调用PostEngine对象进行处理。
接口层的核心基本上就是这些了。

核心层

核心层介于接口层和界面层之间&＃xff0c;主要处理业务逻辑&＃xff0c;集中做数据处理。向上&＃xff0c;给界面层提供数据处理的接口&＃xff0c;称为Action&＃xff1b;向下&＃xff0c;调用接口层向服务器请求数据。向上的Action中定义的方法类似如下&＃xff1a;

这是一个获取用户信息的方法&＃xff0c;因为需要向接口层请求服务器Api数据&＃xff0c;所以添加了callback监听器&＃xff0c;在callback里对返回的数据结果进行操作。CallbackListener就定义了一个成功和一个失败的方法&＃xff0c;代码如下&＃xff1a;

接口的实现基本分为两步&＃xff1a;

1. 参数检查&＃xff0c;检查参数的合法性&＃xff0c;包括非空检查、边界检查、有效性检查等&＃xff1b;
2. 使用异步任务调用接口层的Api&＃xff0c;返回响应结果。

需要注意的是&＃xff0c;Action是面向界面的&＃xff0c;界面上的数据可能需要根据不同情况调用不同的Api。
后续扩展可以在这里添加缓存&＃xff0c;但也要视不同情况而定&＃xff0c;比如有些变化太快的数据&＃xff0c;添加缓存就不太适合了。

界面层

界面层处于最上层&＃xff0c;其核心就是负责界面的展示。
因为公司有为不同商户定制不同app的需求&＃xff0c;因此&＃xff0c;这里就需要建立多个app的界面&＃xff0c;这是一个很麻烦的事情&＃xff0c;还好&＃xff0c;Android Studio提供了很方便的方法可以大大减少工作量&＃xff0c;主要通过设置Gradle&＃xff0c;不同app可以添加不同的productFlavors。
界面层package的定义我也并不按照旧版的功能模块划分&＃xff0c;而根据不同类型划分&＃xff0c;主要分为以下几个包&＃xff1a;

其中&＃xff0c;activity、adapter、fragment各自都有一个基类&＃xff0c;做统一的处理&＃xff0c;比如定义了一些共用的常量、对象和方法等。
界面层是最复杂&＃xff0c;最容易变得混乱不堪&＃xff0c;最容易出问题的层级。所以&＃xff0c;从架构到代码&＃xff0c;很多东西都需要设计好&＃xff0c;以及规范好&＃xff0c;才能保证程序易维护、易扩展。后续的文章里将会详细分享下我在这方面的经验。

模型层

模型层横跨所有层级&＃xff0c;封装了所有数据实体类&＃xff0c;基本上也是跟json的obj数据一致的&＃xff0c;在接口层会将obj转化为相应的实体类&＃xff0c;再通过Action传到界面层。另外&＃xff0c;模型层还定义了一些常量&＃xff0c;比如用户状态、支付状态等。在Api里返回的是用1、2、3这样定义的&＃xff0c;而我则用枚举类定义了这些状态。用枚举类定义&＃xff0c;就可以避免了边界的检查&＃xff0c;同时也更明了&＃xff0c;谁会记得那么多1、2、3都代表什么状态呢。然而用枚举类定义的话&＃xff0c;就必须能将1、2、3转化为相应的枚举常量。这里&＃xff0c;我提供两种实现方式&＃xff1a;
1.使用gson的&＃64;SerializedName标签&＃xff0c;比如0为FALSE&＃xff0c;1为TRUE&＃xff0c;则可以如下定义&＃xff1a;

2.通过定义一个value&＃xff0c;如下&＃xff1a;

通过gson的方式&＃xff0c;直接访问TRUE或FALSE就会自动序列化为1或0&＃xff1b;如果通过第二种方式&＃xff0c;因为没有序列化&＃xff0c;则需要通过getValue方式获取1或0。

结束

以上就是最基本的架构了&＃xff0c;讲得比较简单&＃xff0c;只列了几个核心的东西。并没有进一步去扩展&＃xff0c;扩展是下一步的事情了&＃xff0c;后续的文章里会慢慢展开。