Question

庭院深深深几许，杨柳堆烟，帘幕无重数。用这首词来形容当前市面上Android项目的代码再贴切不过了。

我做过很多App，少则70多个页面，多则200个页面左右，我的切身感受是，无论什么App，开发人员都喜欢把所有的代码、类放在一个项目下，这也就罢了，更有甚者，无论是Activity还是Adapter都位于一个Package下，或者将Adapter内置在Activity中。这就相当于一个房间里既有餐桌又有马桶，床上还放着酱油瓶。

我们需要重新规划Android项目的目录结构，分两步走：

第一步：建立AndroidLib类库，将与业务无关的逻辑转移到AndroidLib。重构后的项目结构请参见图1-1，其中YoungHeart是主项目，保持了对AndroidLib类库的引用。

如何将AndroidLib项目设置为类库，以及如何在YoungHeart项目中添加对AndroidLib类库的引用，这些我就不多说了，请参考相关教程。

AndroidLib中应该包括哪些业务无关的逻辑呢？应至少包括五大部分，如图1-2所示。

图1-1　重构后的项目依赖关系

图1-2　AndroidLib项目结构

这几部分的说明如下：

·activity包中存放的是与业务无关的Activity基类。Activity基类要分两层，如图1-3所示。AndroidLib下的基类BaseActivity封装的是业务无关的公用逻辑，主项目中的AppBaseActivity基类封装的是业务相关的公用逻辑。

·net包里面存放的是网络底层封装。这里封装的是AsyncTask。

·cache包里面存放的是缓存数据和图片的相关处理。

·ui包中存放的是自定义控件。

·utils包中存放的是各种与业务无关的公用方法，比如对SharedPreferences的封装。

第二步：将主项目中的类分门别类地进行划分，放置在各种包中，如图1-4所示。

图1-3　基类的继承关系

图1-4　Android重构后的项目结构

对图1-4中各个包的介绍如下：

·activity：我们按照模块继续拆分，将不同模块的Activity划分到不同的包下。

·adapter：所有适配器都放在一起。

·entity：将所有的实体都放在一起。

·db：SQLLite相关逻辑的封装。

·engine：将业务相关的类都放在一起。

·ui：将自定义控件都放在这个包中。

·utils：将所有的公用方法都放在这里。

·interfaces：真正意义上的接口，命名以I作为开头。

·listener：基于Listener的接口，命名以On作为开头。

这些划分主要是为了以下两个目的：

1）每个文件只有一个单独的类，不要有嵌套类，比如在Activity中嵌套Adapter、Entity。

2）将Activity按照模块拆分归类后，可以迅速定位具体的一个页面。此外，将开发人员按照模块划分后，每个开发人员都只负责自己的那个包，开发边界线很清晰。

曾经有人问我，Activity按照模块拆分了，为什么Adapter、Entity不如法炮制也进行相应的拆分呢？这个问题其实是可以商量的。我不做拆分的原因是，看代码时，肯定是先找到页面从Activity看起，而不会从Adapter看起，所以把Activity分好类就够了。此外，Adapter的逻辑大同小异，如果开发人员都严格遵守Android编码，那么代码中的方法和实现基本相同。这就有别于Activity了，每个Activity都有着很复杂的业务逻辑，所以Activity才是最重要的。

Entity也是这个样子，Entity中应该只有属性，否则就不叫Entity。只是当Entity有上百个时，就需要考虑按照模块划分。

由于Entity中应该只有属性，不应该有业务逻辑的方法，那么如果确实需要，我们就要将其转移到Engine这个包中的某个类下面，这也是Engine这个包的存在意义。

主席说过：“打扫干净屋子再请客。”对于项目而言，划分好组织结构也是这个道理。我们只有把项目结构规划好，才能进行下一步的重构工作。