单一工程
顾名思义，就是一个代码工程(Project)对应一个APP了，这个APP的所有业务功能都是集中在同一个工程里实现的。
组件化
简单来说，就是将一个APP的业务功能进行拆分，每一个功能都是一个单独的工程（Module），每个工程都能独立运行，且只包含自己的业务，我们姑且叫这个独立的功能为一个组件服务，最后由一个空壳APP将多个拆分出的组件集成而成。
单一工程
优点
**
- 适合人数较少(1-3)，较小项目
- 写起代码来比较行云流水，反正我基本哪里都能访问到…
**
缺点
**
- 对工程的任意修改，都要编译整个工程，效率十分低下；
- 不利于多人团队协同开发，别人改了一个地方影响到了你了解一下，合并代码了解一下…
- 无法做到功能复用，例如要做客制化…
- 业务模块耦合严重，时间长了很可能会你中有我，我中有你，修改一个业务可能会牵一发而动全身，不利于后期迭代与维护。
**
组件化工程
优点
**
- 极大提高了编译速度，只需要编译当前的模块；
- 业务模块解耦，有利于多人协同开发，彼此互不打扰，模块代码质量只会局限于自身模块内；
- 组件化是功能重用的基石；
- 模块之间互相不依赖，就没有耦合。
**
缺点
**
- 前期需要花费更多的时间来模块划分；
- 一个人的小项目没有必要组件化，会带来更多的工作量；
- 组件化需要良好的架构设计，需要高水平的架构师统筹全局，经验不足的同学盲目进行组件化可能会适得其反。
**
组件化需要解决的几个问题：
- 如何分成各个模块？
- 各个模块之间如何进行数据共享和数据通信？
- 如何将各个模块打包成一个独立的 APP 进行调试？
- 如何防止资源名称冲突？
- 如何解决 library 重复依赖以及 sdk 和依赖的第三方版本号控制问题？
解决方案：
- 根据业务进行拆分，拆分出来的模块不要过多，会增加维护的难度。
- 我们可以把需要共享的数据划分成一个单独的模块来放置公共数据。各个模块之间的数据通信，我们可以使用阿里的 ARouter 进行页面的跳转，使用封装之后的 RxJava 作为 EventBus 进行全局的数据通信。
- 我们可以在各个模块的 gradle 文件里面配置需要加载的 AndroidManifest.xml 文件，并可以为每个应用配置一个独立的 Application 和启动类。
- 遵守命名规约就能规避资源名冲突问题。
- 可以将各个模块公用的依赖的版本配置到 settings.gradle 里面，并且可以建立一个公共的模块来配置所需要的各种依赖。