在我们学习组件化之前，我们应该要明白我们为什么要学习组件化？我认为有以下几点：
（1）在很早的时候，我们做一个项目就是用的单一分层模式，如下图分包：
可以看到随着业务的发展，分包将会越来越大，项目逐渐失去层次感，越来越难维护。
（2）包名的限制力太强，导致稍微不注意，就会导致高度耦合
（3）当有多人在开发的时候，容易出现冲突。
从上面几种情况我们可以知道，我们要解决这些问题，于是，组件化就来了。
组件化要遵守的核心：不相互依赖，但是可以相互交互，可以任意组合，高度解耦，自由拆卸，自由组装，重复利用，分层次管理。如下图所示架构：
用户访问流程就有：用户先访问我们的app壳，然后app壳去访问我们的（首页，推荐，聊天，我的等模块）在这里注意：这里是一定不要进行横向依赖，比如首页去依赖推荐，这是严格拒绝的。那是如何解决这个问题的呢？我们可以让首页去访问我们的公共基础库，注意在这里各个模块依赖的公共基础库都是同一个，也就是说首页去访问我们的公共基础库，然后公共基础库通过调用它里面的技术去访问推荐，来达到通信的目的。
应用场景
当我们接到一个项目进行开发时候，我们有测试环境(迭代功能)和正式环境(项目上线)。需要完成以下几个模块：
并且接到测试老大的通知，我测试的时候可以进行分批测试，也就是说模块一，模块二，模块三都可以分别测试，那么也就是说这三个都是可以独立运行的（不依附app壳）。这就是组件化环境。并且等上线的时候，整个项目可以打包成一个apk(集成环境),也就是说app壳能独立运行，其他的模块必须依附app壳才能运行。那么我们怎么才能达到这个目的呢？就是说可以动态的去部署呢？
在这里我们的Gradle就出来了。（用Gradle来控制测试环境和正式环境的部署）
其实我们整个Android项目是交给Gradle去构建的。
1.Gradle的根在哪里？ settings.gradle
2.项目的Gradle：builds.gradle(project:MyApplication)
3.app的Gradle: build.gradle(Moudle:app)
首先先找到根gradle这是第一步，然后再找到项目的gradle。最后再找到app的gradle
我们可以进行打印测试一下：
三段代码如上所示：打印如下结果：
从结果我们可以看出确实是按照上述顺序输出。
现在假如我们模块一，模块二，模块三，都有不同的app gradle.如下图所示，我建立了三个模块。
我们发现各个模块有相同的代码比如：modelfirst举例:
我们抽取出来做一个公共的gradle:(创建一个新的Gradle,我们命名为common.gradle)我们用Groovy语法进行编写:我们写一个扩展快：
我们要在各个模块中引入该公共Gradle,还差一个条件就是将该Gradle引入到project的Gradle中，这样我们各个模块的Gradle都能访问到该common.gradle.如下所示：
然后在app.gradle中将该引入的部分写进去进行更改：如下所示:
我们发现还有一个applicationId,也把它抽取出来，放入common.gradle中，进而发现dependencies下也需要抽取进common.gradle中。通过以上抽取现在来看我们的app.gradle和抽取之后的common.gradle.
其他模块和app.gradle一样直接引入就好了。
那我们怎么控制测试环境和正式环境的部署呢，我们添加一个变量：
isRelease. 如果为false为测试环境反之正式环境。并将测试服务器和正式环境服务器地址写入common.gradle中。 并且我们在打包签名时可以动态部署，我们就要修改我们的app.gradle了，让它达到这种效果，一种是当打包debug签名时，用的是测试环境下的服务器地址，当打包release签名时，用的是正式环境下的地址。
等我们编译完成之后，将会出现一个BuildConfig类，可以帮助我们区别是测试环境下还是在正式环境下。
现在我们可以根据isRelease 判断是否在测试环境下还是在正式环境下。我们是否让组件能不能独立运行，去满足我们测试老大先前踢的要求。
那好，现在我们进入判断吧：
更改各个模块的值:
我们知道要想能独立运行必须满足两个点：
1. applyplugin:'com.android.application'
2. applicationId appID.modelfirst
所以我们以model first.gradle为例进行测试，其他模块相同如下图所示：
可以看到是可以相互独立运行的，当我们更改isRelease为true，会发现都不可一独立运行，只能依附app壳运行。
到此，那我们的模块是不能横向进行依赖的，也许我们可以用以下几种方式进行通信。
比如我想模块一的activity跳到模块二的activity.
1.用Eventbus的方式，（写者一直很排斥用eventBus,因为维护成本太高了，在写者的项目中都移除了eventBus）。
2.广播方式（不好管理）。
3.使用隐式意图，但是AndroidManifest.xml里面配置xml写的太多了。
4.使用类加载的方式。（容易写错包名）
5.使用全局map的方式。（注册的对象太多）
在这里，我用第四个进行举例子。
包名写对就能正常跳转了，当然还可以用第三方，比如阿里的ARoute(封装在公共基础库中)。