组件化就是多module划分业务和基础功能。这样可解耦，提高代码复用。在正式开始讲解组件化之前可以先看一下一个组件化架构图来对组件化有一个初步的认识。
1.基础层中一般会包括一些基础库，比如图片加载，网络加载，数据存储等等。
2.组件层就是业务逻辑相关的代码，比如登录、支付等
3.应用层就是把所有的组件组合起来，发布一个完整的App
组件层中有很多Activity，这些Activity都需要在相应Module中AndroidManifest中注册，合并成一个App的过程中，Manifest也会被合并，这正是组件化能够进行的原因。
1.组件化Application
和每个Module中都可以有Activity一样，每个Module中也可以有一个Application，如果不做任何处理，直接添加一个Module，编译之后就会报错Manifest Merge failed:Attribute application @name value=(xxx.xx.xApplication) from AndroidManifest.xml is also present at xxxx...这是因为AndroidStudio的Gradle插件默认会启用Manifest Merge Tool，如果Module 项目中也定义了与主项目相同的属性，如（android：icon或者android：theme），就会合并失败。
可以在Module中Manifest文件中添加tools:replace="android:name，android:theme"来声明Module的Application中相关属性是可以被替代的，这样就可以解决冲突。
通常我们需要做一些全局弹窗，比如常见的App升级弹窗，或者一些广告弹窗，那么我们就需要获取顶层Activity的Context并传递给需要弹出的Dialog。如何获取顶层的Activity？这时就需要介绍一个方法：Application的registerActivityLifecycleCallback()，这个方法可以监听App所有的Activity活动，包括各种生命周期事件。当然也能获取顶层Activity对象。
2.组件化编程
谈到组件化编程前我们先思考一个问题：如何启动一个无法获取类名的Activity？一个简单的方法就是隐式意图。关于如何使用隐式意图不在本文的讨论范围内，不熟悉的童鞋请自行查看相关代码。
组件化编程为什么要涉及到这个问题呢？因为组件化编程中，不同的页面会在不同的Module中，Module和Module之间是相互隔离（再看一遍架构图），无法直接访问到对方。既然无法访问到对方，肯定无法得到需要启动的Activity的类名的。这就延伸出了上一段提到的问题。当然是用隐式意图可以做到这一点，但是除了不安全外（整个系统都可以监听到这个隐式意图），更多是考虑到编写隐式意图代码的繁杂，有大量的boring code。有没有更好的替代方案？
这就引申出了一些组件化路由方案的存在。
什么是路由？通俗的说即从一个地方到另一个地方。这个词经常出现在计算机网络术语中，表示路由器从端口获取数据并根据数据包的内容分发到指定端口的过程。
我们的Activity就像一个一个端口，跳转的Intent就像数据，我们需要找到一种合适方法将intent分发到指定的Activity。很多第三方框架已经可以很好地帮我们完成这个过程，比如ARouter。在路由的过程中可以对路由的信息做一些处理，当然这就和业务逻辑向关联起来了，以后再做讨论。
首先需要在Base module中添加一些配置，导入ARouter库。详细的配置过程参考ARouter的接入Wiki。
接入完成后我们跳转Activity的代码就变成了：
ARouter.getInstance().build("/login/register")
.withString("name","laotie")
.navigation();
这里面build("/login/register")是指想要跳转的Activity的@Route（"/login/register"）注解名称，withString("name","laotie")相当于需要传递到Intent中的param。跳转目标的Activity可以像获取普通Intent中的参数一样获取里面的值。"/login/register"中login就是groupName，不同的Module应该有不同的groupName。否则会编译报错。
ARouter后面的原理是在Application加载ARouter的init()方法后，建立起"login/register"和相应Activity的映射关系，如果查看源码，跳转的时候本质上还是调用的startActivty()。
3.反射和组件化编程
通常我们采用的是Activity+Fragment的方式来将页面和Activity解耦。在组件化架构就会出现在这样一个问题，这里需要的Fragment在另个一Module里面。直接引用相应的Fragment除了Module之间不应该直接访问外，如果移除了相应的Module，必然会带来找不到类的错误。这时我们就需要通过反射的方式到相应的module中获取该Fragment的实例。（虽然反射效率降低，但是可以提高解耦）反射获取相关的类的知识点请自行研究。
和隐式意图一样，手动去写反射的代码也很繁杂。ARouter同样提供了很好地跨模块解决方案：Fragment f = (Fragment) ARouter.getInstance().build("/login/register_fragment").navigation();拿到了Fragment就可以加载到Activity中，如果查看源码的话，底层的原理依然是反射。
可是每次都这么写的话三个module就需要把相同的代码写三遍，要是能在Fragment所在的Module中有一个提供该Fragment的方法，其他模块只需跨模块调用这个方法即可添加相应的Fragment。在这样的想法下想把Fragment初始化的方法解耦到每个需要的module中，就需要跨module调用方法。ARouter也提供了跨模块调用对象的方法。
- 扩展IProvider接口，创建一个初始化参数接口
public interface FragmentProvider extends IProvider{
Fragment newInstance(Activity activity,@IdRes int containerId,FragmentManager manager,Bundle bundle,String tag);
}
- 继承扩展接口并实现初始化Fragment的方法
@Router(path="/login/register_fragment_provider")
public class NewFragmentProvider implements FragmentProvider{
@Override
public void init(Context context){
}
@Override
public Fragment newInstance(Activity activity,@IdRes int containerId,FragmentManager manager,Bundle bundle,String tag){
return ViewUtils.(activity, containerId, manager, bundle,RegisterFragment.class, tag);
}
}
- 通过ARouter的IProvider接口和路由地址调用初始化Fragment方法。
((FragmentProvider) ARouter.getInstance().build("/login/register_fragment_provider")
.navigation()).newInstance(activity, containerId, manager, bundle, tag);
这样我们就可以在不同的module中调用方法获取Fragment，也避免了很多重复的代码。
谈完了Activity和Fragment，让我们再回过头来看看Application。
通常我们会在Application中初始化一些第三方库。但是一些第三方库只和对应的module有关系，如果强制把他们塞到base module的gradle中就会显得很臃肿，而且这个Module如果被移除了，我们用不到这个第三方库，但是我们的工程中依然会有这个第三方库，这样就无形增大工程的无用代码和app的体积。如何解决这个问题？
到对应的Module中引用并初始化这些类库！说的简单，Module中没有Application，怎么做到这一点？
1.方法一 反射
在Moduel中定一个初始化类Init.class，里面的init（）方法会初始化相应的库。和直接获取Fragment一样，我们可以定义好该初始化类在工程中的路径，通过反射获取该类，然后调用init（）方法即可。
2.方法二 通过ARouter的跨Module方法调用完成初始化
有没有感觉很熟悉，既然第一个方法和直接获取Fragment类似，那么对应的，我们也可以像第二种添加Fragment的方法一样，通过IProvider类，直接提供对初始化类Init.class的init()方法的调用。详细的代码参考上面的就可以了。
到这里就可以粗略的对组件化有一个大概的认识，知道了怎么去构建一个简单的组件化框架。下面一篇文章将会介绍如何在不同的Module中通信、存储数据、管理权限请求等，还有如何更好地解耦等等。慢慢一步一步填充组件化开发过程中的细节问题。
