最近在重构公司的一个项目，准备把项目进行模块化，顺便记录一下在重构过程中的一些感想。
Android模块化设计方案系列文章：
Android发展到现在，关于各种模块化开发的文章不胜枚举，尽管有很多珠玉在前，但我还想记录一下我对模块化开发的的一些想法，算是对自己学习过程的一个总结和肯定。
关于模块化开发的优势，网上有很多介绍，这里就不再赘述了，直接上图。
上图是我对模块化设计的一个观点，下面解释一下各个模块的意义：
实线箭头：依赖关系
虚线箭头：派生关系
App ①、App ②：这两个最顶层的模块就是我们打包app时候的壳工程，模块中不包含具体的业务逻辑。
ModuleA、ModuleB...：把项目主体功能拆分成的能各自独立运行的模块，比如购物城功能、用户信息管理等，这些模块之间关联不是那么紧密，在协作开发过程中，也往往不是同一个人负责，拆分成不同的模块也能在协作开发的过程中，把相互间的干扰降到最低，提高协作开发的效率。
Router：路由组件，无需赘言。
ApiA、ApiB...：对应的ModuleA、ModuleB中对外暴露出的接口、实体类、路由表等。在我们开发过程中，虽然尽最大可能的避免模块间的耦合，但是夸模块的调用始终无法避免，为了解决需要跨模块调用的接口、实体类等下沉到Common中导致Common臃肿的问题，通过对类的api化，从module中派生出对应的api模块，提供给其他模块依赖。
Business Common：与项目相关的基础依赖库，主要用于存放模块间共享的资源，比如TitleBar，NavigateBar等，这些widget或者资源文件与我们的业务息息相关，又在多个模块中需要使用，于是用单独的模块进行管理。
ThridLibs：第三方类库我们在开发过程中不可避免的会使用到第三方类库，比如分享，地图，编解码等模块，这些模块的核心功能与业务关联不大，因此我们在对三方类库进行封装之后放入单独的模块，并把需要暴露的方法抽象成接口，供上层模块调用。
ThridLibs Proxy：第三方类库的代理模块，是为了避免直接使用三方类库，对上面的那个模块抽象出来的接口进行动态/静态代理，方便我们以后敏捷的对三方类库进行更改。
Base Common：与业务无关的基础模块，比如我们封装的BaseActivity、BaseFragment等，我们可以把这个类库用到其他的项目中，也是我们在开发中的基础沉淀。
Utils：这个模块比较简单，就是日常中用到的一些工具类，比如FileUtil、AppUtil等。
这些module可以Git子模块的形式存在于住项目之中的（还不了解子模块的同学请进传送门：Git子模块），或者对于一些不会频繁维护的模块，直接打包成aar上传到maven仓库也是可以的。
子模块的简单介绍：Git支持在主仓库中引用其它独立仓库，这些在仓库中引入的其它仓库被称为子模块。子模块同正常的GIt仓库一样，能够独立的进行版本维护，而主仓库只需要索引子模块commit的MD5值，不用维护子模块的文件，对降低项目耦合度是一个非常不错的手段。
凡是有利就有弊，模块化开发虽然能够将项目解耦成不同的模块，但是也有一些明显的弊端：
其一、项目的维护成本增加。原本一个仓库就能解决的事情，现在要细分到多个仓库，越是细小颗粒度的模块化，维护成本越高。在小团队甚至个人开发的时候，是否采用模块化的开发方案是一个需要慎重考虑的问题。
其二、跨模块依赖变得复杂。因为同级模块之间不直接进行依赖，所以跨模块调用的问题比单一模块要复杂上许多。
欢迎点赞关注~
