软件研发中，耗费最多的并不是编写代码，而是代码编译和代码不断调试的过程。对于我们Android来说，随着项目的不断迭代，以及业务模块的不断增加，项目技术栈的增加，项目编译会越来越慢。随着业务的扩展，相信很多的公司都已经做了模块化/组件化。

背景

创建一个 Project 后可以创建多个 Module，这个 Module 就是所谓的模块。一个简单的例子，可能在写代码的时候我们会把首页、消息、我的模块拆开，每个 tab 所包含的内容就是一个模块，这样可以减少 module 的代码量，但是每个模块之间的肯定是有页面的跳转，数据传递等，比如 A 模块需要 B 模块的数据，于是我们会在 A 模块的 gradle 文件内通过 implementation project(':B')依赖 B 模块，但是 B 模块又需要跳转到 A 模块的某个页面，于是 B 模块又依赖了 A 模块。这样的开发模式依然没有解耦，改一个bug依然会改动很多模块，并不能解决大型项目的问题。于是就有了组件的概念，我们日常业务需求开发的组件叫做业务组件，如果这个业务需求是可以被普遍复用的，那么叫做业务基础组件，譬如图片加载、网络请求等框架组件我们称为基础组件。于是一个典型的组件化架构通常如下图所示。

实线表示直接依赖关系，虚线表示间接依赖。比如壳工程肯定是要依赖业务基础组件、业务组件、module_common公共库的。业务组件依赖业务基础组件，但并不是直接依赖，而是通过”下沉接口“来实现间接调用。业务组件之间的依赖也是间