去年10月底换到了新公司，作移动研发组的负责人，刚开始接手android项目时，发现该项目真的是一团糟。首先是其架构，是按功能模块进行划分的，原本按模块划分也挺好的，但是，他却分得太细，总共分为了17个模块，而好几个模块也就只有两三个类而已。但应用自己其实比较简单，要按功能模块来分的话，最多五个模块就够了。另外，有好多模块划分也很模糊，也有不少类按其功能其实能够属于多个模块的，也有些类定义不明确，作了不应作的事。有时候，我要找一个界面的Activity，按照其功能应该属于A模块的，但是在A模块里却找不到，因而，我只好去AndroidManifest文件里找了，找到才发现原来在B模块里。也有时候，我要找另外一个界面的Activity，可我看遍了全部模块，也没看出这个界面应该属于哪一个模块，无法子，又只能去AndroidManifest文件里找了，找到才发现居然在C模块里。代码也是又乱又臭，致使出现一大堆bug又很差找，改好一个bug又出现另外一个。整个项目从架构到代码都是又臭又乱，开发人员只是不停地改bug，根本无法作新功能，更别谈扩展了。当时，公司已经有为不一样客户定制化app的需求，而现有的架构彻底没法知足这样的需求。所以，我决定重构，搭建一个易维护、易扩展、可定制的项目。java
我将项目分为了四个层级：模型层、接口层、核心层、界面层。模型层定义了全部的模型；接口层封装了服务器提供的API；核心层处理全部业务逻辑；界面层就处理界面的展现。几个层级之间的关系以下图所示：
下面展开说明具体的每一个层次：android
接口层
接口层封装了网络底层的API，并提供给核心层调用。刚开始，为了简单，该层的核心类我只定义了4个：json
PostEngine，请求引擎类，对请求的发送和响应结果进行处理；数组
Response，响应类，封装了Http请求返回的数据结构；缓存
Api，接口类，定义了全部接口方法；服务器
ApiImpl，接口实现类，实现全部接口方法。微信
PostEngine将请求封装好发送到服务器，并对响应结果的json数据转化为Response对象返回。Response其实就是响应结果的json数据实体类，json数据是有固定结构的，分为三类，以下：网络
{"event": "0", "msg": "success"}
{"event": "0", "msg": "success", "obj":{...}}
{"event": "0", "msg": "success", "objList":[{...}, {...}], "currentPage": 1, "pageSize": 20, "maxCount": 2, "maxPage": 1}
event为返回码，0表示成功，msg则是返回的信息，obj是返回的单个数据对象，objList是返回的数据对象数组，currentPage表示当前页，pageSize则表示当前页最多对象数量，maxCount表示对象数据总量，maxPage表示总共有多少页。根据此结构，Response基本的定义以下：数据结构
public class Response<T> {
private String event;
private String msg;
private T obj;
private T objList;
private int currentPage;
private int pageSize;
private int maxCount;
private int maxPage;
//getter和setter方法
...
}
每一个属性名称都要与json数据对应的名称相一致，不然没法转化。obj和objList用泛型则能够转化为相应的具体对象了。架构
Api接口类定义了全部的接口方法，方法定义相似以下：
public Response<Void> login(String loginName, String password);
public Response<VersionInfo> getLastVersion();
public Response<List<Coupon>> listNewCoupon(int currentPage, int pageSize);
ApiImpl则实现全部Api接口了，实现代码相似以下：
@Override
public Response<Void> login(String loginName, String password) {
try {
String method = Api.LOGIN;
List<NameValuePair> params = new ArrayList<NameValuePair>();
params.add(new BasicNameValuePair("loginName", loginName));
params.add(new BasicNameValuePair("password", EncryptUtil.makeMD5(password)));
TypeToken<Response<Void>> typeToken = new TypeToken<Response<Void>>(){};
return postEngine.specialHandle(method, params, typeToken);
} catch (Exception e) {
//异常处理
}
}
实现中将请求参数和返回的类型定义好，调用PostEngine对象进行处理。
接口层的核心基本上就是这些了。
核心层
核心层介于接口层和界面层之间，主要处理业务逻辑，集中作数据处理。向上，给界面层提供数据处理的接口，称为Action；向下，调用接口层向服务器请求数据。向上的Action中定义的方法相似以下：
public void getCustomer(String loginName, CallbackListener<Customer> callbackListener);
这是一个获取用户信息的方法，由于须要向接口层请求服务器Api数据，因此添加了callback监听器，在callback里对返回的数据结果进行操做。CallbackListener就定义了一个成功和一个失败的方法，代码以下：
public interface CallbackListener<T> {
/** * 请求的响应结果为成功时调用 * @param data 返回的数据 */
public void onSuccess(T data);
/** * 请求的响应结果为失败时调用 * @param errorEvent 错误码 * @param message 错误信息 */
public void onFailure(String errorEvent, String message);
}
接口的实现基本分为两步：
参数检查，检查参数的合法性，包括非空检查、边界检查、有效性检查等；
使用异步任务调用接口层的Api，返回响应结果。
须要注意的是，Action是面向界面的，界面上的数据可能须要根据不一样状况调用不一样的Api。
后续扩展能够在这里添加缓存，但也要视不一样状况而定，好比有些变化太快的数据，添加缓存就不太适合了。
界面层
界面层处于最上层，其核心就是负责界面的展现。
由于公司有为不一样商户定制不一样app的需求，所以，这里就须要创建多个app的界面，这是一个很麻烦的事情，还好，Android Studio提供了很方便的方法能够大大减小工做量，主要经过设置Gradle，不一样app能够添加不一样的productFlavors。
界面层package的定义我也并不按照旧版的功能模块划分，而根据不一样类型划分，主要分为如下几个包：
其中，activity、adapter、fragment各自都有一个基类，作统一的处理，好比定义了一些共用的常量、对象和方法等。
界面层是最复杂，最容易变得混乱不堪，最容易出问题的层级。因此，从架构到代码，不少东西都须要设计好，以及规范好，才能保证程序易维护、易扩展。后续的文章里将会详细分享下我在这方面的经验。
模型层
模型层横跨全部层级，封装了全部数据实体类，基本上也是跟json的obj数据一致的，在接口层会将obj转化为相应的实体类，再经过Action传到界面层。另外，模型层还定义了一些常量，好比用户状态、支付状态等。在Api里返回的是用一、二、3这样定义的，而我则用枚举类定义了这些状态。用枚举类定义，就能够避免了边界的检查，同时也更明了，谁会记得那么多一、二、3都表明什么状态呢。然而用枚举类定义的话，就必须能将一、二、3转化为相应的枚举常量。这里，我提供两种实现方式：
1.使用gson的@SerializedName标签，好比0为FALSE，1为TRUE，则能够以下定义：
public enum BooleanType {
@SerializedName("0")
FALSE,
@SerializedName("1")
TRUE
}
2.经过定义一个value，以下：
public enum BooleanType {
FALSE("0"),
TRUE("1");
private String value;
BooleanType(String value) {
this.value = value;
}
public String getValue() {
return value;
}
}
经过gson的方式，直接访问TRUE或FALSE就会自动序列化为1或0；若是经过第二种方式，由于没有序列化，则须要经过getValue方式获取1或0。
结束
以上就是最基本的架构了，讲得比较简单，只列了几个核心的东西。并无进一步去扩展，扩展是下一步的事情了，后续的文章里会慢慢展开。
本文分享自微信公众号 - Keegan小钢（keeganlee_me）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。