Android 项目重构之路:架构篇

去年10月底换到了新公司,做移动研发组的负责人,刚开始接手android项目时,发现该项目真的是一团糟。

首先是其架构,是按功能模块进行划分的,本来按模块划分也挺好的,可是他却分得太细,总共分为了17个模块,而好几个模块也就只有两三个类而已。但应用本身其实比较简单,要按功能模块来分的话,最多五个模块就够了。

另外,有好多模块划分也很模糊,也有很多类按其功能其实可以属于多个模块的,也有些类定义不明确,做了不该做的事。有时候,我要找一个界面的Activity,按照其功能应该属于A模块的,可是在A模块里却找不到,于是,我只好去AndroidManifest文件里找了,找到才发现原来在B模块里。

也有时候,我要找另一个界面的Activity,可我看遍了所有模块,也没看出这个界面应该属于哪个模块,没法子,又只能去AndroidManifest文件里找了,找到才发现竟然在C模块里。代码也是又乱又臭,导致出现一大堆bug又不好找,改好一个bug又出现另一个。整个项目从架构到代码都是又臭又乱,开发人员只是不停地改bug,根本没法做新功能,更别谈扩展了。

当时,公司已经有为不同客户定制化app的需求,而现有的架构完全无法满足这样的需求。因此,我决定重构,搭建一个易维护、易扩展、可定制的项目。

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

下面展开说明具体的每个层次:

接口层

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

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

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

1

2

3

{"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基本的定义如下:

1

2

3

4

5

6

7

8

9

10

11

12

13

public class ResponseT> {

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接口类定义了所有的接口方法,方法定义类似如下:

1

2

3

public ResponseVoid> login(String loginName, String password);

public ResponseVersionInfo> getLastVersion();

public ResponseListCoupon>> listNewCoupon(int currentPage, int pageSize);

ApiImpl则实现所有Api接口了,实现代码类似如下:

1

2

3

4

5

6

7

8

9

10

11

12

13

@Override

public ResponseVoid> login(String loginName, String password) {

try {

String method = Api.LOGIN;

ListNameValuePair> params = new ArrayListNameValuePair>();

params.add(new BasicNameValuePair("loginName", loginName));

params.add(new BasicNameValuePair("password", EncryptUtil.makeMD5(password)));

TypeTokenResponseVoid>> typeToken = new TypeTokenResponseVoid>>(){};

return postEngine.specialHandle(method, params, typeToken);

} catch (Exception e) {

//异常处理

}

}

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

核心层

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

1

public void getCustomer(String loginName, CallbackListenerCustomer> callbackListener);

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

1

2

3

4

5

6

7

8

9

10

11

12

13

14

public interface CallbackListenerT> {

/**

* 请求的响应结果为成功时调用

* @param data  返回的数据

*/

public void onSuccess(T data);

/**

* 请求的响应结果为失败时调用

* @param errorEvent 错误码

* @param message    错误信息

*/

public void onFailure(String errorEvent, String message);

}

接口的实现基本分为两步:

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

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

界面层

界面层处于最上层,其核心就是负责界面的展示。

因为公司有为不同商户定制不同app的需求,因此,这里就需要建立多个app的界面,这是一个很麻烦的事情,还好,Android Studio提供了很方便的方法可以大大减少工作量,主要通过设置Gradle,不同app可以添加不同的productFlavors。

界面层package的定义我也并不按照旧版的功能模块划分,而根据不同类型划分,主要分为以下几个包:

其中,activity、adapter、fragment各自都有一个基类,做统一的处理,比如定义了一些共用的常量、对象和方法等。

界面层是最复杂,最容易变得混乱不堪,最容易出问题的层级。所以,从架构到代码,很多东西都需要设计好,以及规范好,才能保证程序易维护、易扩展。后续的文章里将会详细分享下我在这方面的经验。

模型层

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

  1. 使用gson的@SerializedName标签,比如0为FALSE,1为TRUE,则可以如下定义:

1

2

3

4

5

6

public enum BooleanType {

@SerializedName("0")

FALSE,

@SerializedName("1")

TRUE

}

  1. 通过定义一个value,如下:

1

2

3

4

5

6

7

8

9

10

11

12

13

14

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。

结束

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

全能程序员交流QQ群290551701,聚集很多互联网精英,技术总监,架构师,项目经理!开源技术研究,欢迎业内人士,大牛及新手有志于从事IT行业人员进入!

时间: 2024-10-05 13:08:42

Android 项目重构之路:架构篇的相关文章

(转)Android项目重构之路:实现篇

前两篇文章Android项目重构之路:架构篇和Android项目重构之路:界面篇已经讲了我的项目开始搭建时的架构设计和界面设计,这篇就讲讲具体怎么实现的,以实现最小化可用产品(MVP)的目标,用最简单的方式来搭建架构和实现代码. IDE采用Android Studio,Demo实现的功能为用户注册.登录和展示一个券列表,数据采用我们现有项目的测试数据,接口也是我们项目中的测试接口. 项目搭建 根据架构篇所讲的,将项目分为了四个层级:模型层.接口层.核心层.界面层.四个层级之间的关系如下图所示:

(转)Android项目重构之路:界面篇

在前一篇文章<Android项目重构之路:架构篇>中已经简单说明了项目的架构,将项目分为了四个层级:模型层.接口层.核心层.界面层.其中,最上层的界面,是变化最频繁的一个层面,也是最复杂最容易出问题的一个层面,如果规划不好,很容易做着做着,又乱成一团了. 要规划好界面层,至少应该遵循几条基本的原则: 保持规范性:定义好开发规范,包括书写规范.命名规范.注释规范等,并按照规范严格执行: 保持单一性:布局就只做布局,内容就只做内容,各自分离好:每个方法.每个类,也只做一件事情: 保持简洁性:保持代

Android项目重构之路:实现篇

项目搭建 根据架构篇所讲的,将项目分为了四个层级:模型层.接口层.核心层.界面层.四个层级之间的关系如下图所示: 实现上,在Android Studio分为了相应的四个模块(Module):model.api.core.app. model为模型层,api为接口层,core为核心层,app为界面层. model.api.core这三个模块的类型为library,app模块的类型为application. 四个模块之间的依赖设置为:model没有任何依赖,接口层依赖了模型层,核心层依赖了模型层和接

Android 项目重构之路:实现篇

前两篇文章<Android项目重构之路:架构篇>和<Android项目重构之路:界面篇>已经讲了我的项目开始搭建时的架构设计和界面设计,这篇就讲讲具体怎么实现的,以实现最小化可用产品(MVP)的目标,用最简单的方式来搭建架构和实现代码. IDE采用Android Studio,Demo实现的功能为用户注册.登录和展示一个券列表,数据采用我们现有项目的测试数据,接口也是我们项目中的测试接口. 项目搭建 根据架构篇所讲的,将项目分为了四个层级:模型层.接口层.核心层.界面层.四个层级之

Android 项目重构之路:界面篇

在前一篇文章<Android项目重构之路:架构篇>中已经简单说明了项目的架构,将项目分为了四个层级:模型层.接口层.核心层.界面层.其中,最上层的界面,是变化最频繁的一个层面,也是最复杂最容易出问题的一个层面,如果规划不好,很容易做着做着,又乱成一团了. 要规划好界面层,至少应该遵循几条基本的原则: 保持规范性:定义好开发规范,包括书写规范.命名规范.注释规范等,并按照规范严格执行: 保持单一性:布局就只做布局,内容就只做内容,各自分离好:每个方法.每个类,也只做一件事情: 保持简洁性:保持代

Android Studio重构之路,我们重新来了解一下Google官方的Android开发工具

Android Studio重构之路,我们重新来了解一下Google官方的Android开发工具 记得我的第一篇博客就是写Android Studio,但是现在看来还是有些粗糙了,所有重构了一下思路,覆写了一篇 Google主推-Android开发利器--Android Studio,这可能是最全的AS教程! Android Studio,自Google2013年发布以来,就倍受Android开发者的喜爱,我们本书,就是基于Android Studio来进行案例演示的,大家都知道,Android

项目重构之路

这段时间在忙着给公司,一个WPF项目做一些功能,该项目的背景介绍 两年以上的运维和迭代历史 有一点点“三层”架构感觉,有View(WPF具体窗口,基本上所有逻辑多在这),Model(没有明确的定义ViewModel,还是数据Model),Bll(提供给View 的是DataSet,DataTable,只是一个提供数据给View封装的地方) 由于是C/S结构的项目,部署环境考虑,通过WebService 来实现程序和数据库沟通,提供的数据结构,是不易于操作的DataSet,DataTable. 对

Jenkins构建Android项目持续集成之findbugs的使用

题外话 这篇本来和之前的系列要一起出的,但是因为中间公司要发布一个版本,给耽搁了,今天工作做完了,又闲了下来.所以就又来继续jenkins构建Android项目持续集成系列的findbugs篇. Findbugs简介 关于findbugs的介绍,可以自行百度下,这里贴下百度百科的介绍.findbugs是一个静态分析工具,它检查类或者 JAR 文件,将字节码与一组缺陷模式进行对比以发现可能的问题.这组缺陷模式是可配置的,通过配置,可以过滤掉一些我们不想或不需要检测的问题. findbugs在gra

[android架构篇]mvp+rxjava+retrofit+eventBus

android架构篇 mvp+rxjava+retrofit+eventBus 高层不应该知道低层的细节,应该是面向抽象的编程.业务的实现交给实现的接口的类.高层只负责调用. 首先,要介绍一下一个项目中好架构的好处:好的软件设计必须能够帮助开发者发展和扩充解决方案,保持代码清晰健壮,并且可扩展,易于维护,而不必每件事都重写代码.面对软件存在的问题,必须遵守SOLID原则(面向对象五大原则),不要过度工程化,尽可能降低框架中模块的依赖性. 之前的一段时间,学习了一些新的技术,并把自己关注的技术整合