我们需要重新规划Android项目的目录结构，分两步走：
第一步：建立AndroidLib类库，将与业务无关的逻辑转移到AndroidLib。
AndroidLib中应该包括哪些业务无关的逻辑呢？应至少包括五大部分.
这几部分的说明如下：
activity包中存放的是与业务无关的Activity基类。Activity基类要分两层，如图1-3所示。
AndroidLib下的基类BaseActivity封装的是业务无关的公用逻辑，主项目中的AppBaseActivity基类封装的是业务相关的公用逻辑。
net包里面存放的是网络底层封装。这里封装的是AsyncTask。
cache包里面存放的是缓存数据和图片的相关处理。
ui包中存放的是自定义控件。
utils包中存放的是各种与业务无关的公用方法，比如对SharedPreferences的封装。
第二步：将主项目中的类分门别类地进行划分，放置在各种包中.
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这个包的存在意义。