1 背景
Android开发中你的模块(Module)一般只有一个app主模块，随着功能不断扩展你会发现一个模块的缺点就是各种业务高度耦合，你就想测试登录模块，那么你可能会把支付模块也编译进去了，代价就是编译耗时，降低效率。
大牛就提出了组件化开发的概念，假如一个App包括登录，选购，支付三个模块，那么就分成三个app，一个用来做登录，一个用来展示商品让用户选购，一个用来做支付，这样互相不影响而且编译的话只会编译当前模块的代码，提高了时间效率。
具体如何让自己的App成为组件化App请看这位博主的博客
Android组件化开发
2 原理
既然知道了组件化开发，那么我们看下下面这张图
箭头表示依赖关系，举例：BaseModule指向module1-login模块、Module2-Pay模块，表示在Login、Pay的build.gradle文件中包含对baseModule的依赖(即下面代码)
compile project(path: ':baseModule')
app是我们的主模块，module1模块是登录模块，module2是支付模块，baseModule是基础模块，baseModule的作用是搭建模块间的桥梁，让所有模块共享资源，举个例子：我把网络请求框架，图片缓存框架保存在baseModule里面，这样module1和module2都依赖baseModule即可，每个module只关心做本业务的事就可以了，所有模块都需要的事情交给baseModule去做即可。
主模块可以和下面的所有子模块通信调用，但是如果两个子模块之间需要调用该怎么弄呢？因此，我们需要搭建模块间的桥梁，下面就是今天要说的Android模块间通信了
假如登录模块的登录页面验证完毕要跳转到支付模块的支付页面应该如何做呢？
哼，这不简单吗？直接startAcitivity进行跳转不就可以吗？
哦！不对，module1没有添加对module2的依赖，所以我无法获取到module2中的PayActivity这个类！
哼，难得倒我？Class c=Class.forName(“类名”)，反射直接拿到类，module1引用baseModule的方法进行跳转！
不错不错，你会使用反射说明已经很有潜力解决这个问题了，让我们来看下这个方法的问题出在哪里——你无法获取这个类的名字，当我们合作开发的时候我们是不知道其他人的模块里面的类定义是什么名字的(即使你知道名字，万一有一天他改了包结构，类名变了呢？你的反射就会抛出异常了)
我知道这点小困难是难不住你的
那这样吧，module1的开发者和module2的开发者说好，我们用一个标志来表示module2的支付页面吧，比如叫
pay,我给你传的参数是pay你就跳到你定义的支付页面，test就跳转到你的测试页面，我不用管也不想管你以后怎
么定义你的类名和包名了
说干就干，我们在baseModule中定义一个接口用于表示要进行跳转的标志，斜杠前面表示的模块名，后面是表示的标志(为什么这样定义后面会解释)
下面是demo的效果，主页中直接开启module1，然后跳转至module2，两个子module相互点击跳转：
让我们整理接下来的实现思路：
module1和module2均会实现baseModule的跳转分发TaskDistribution接口，接口第二个参数会传递一个标志给
baseModule的接口TaskDistribution，Distributor为跳转分发的实现类，里面利用反射创建各个子module的
跳转类，据此就可以找到各个子module的页面类，页面类会根据这个标志flag进行判断跳转
解析：baseModule不依赖module2，他也是无法获取支付类的，要想跳转到支付类，只能把跳转的任务交给module2，我们定义“module1/login”是为了保证baseModule分发标志的时候可以发给相应的模块
接上面的分发跳转任务这件事，那么module2中应该有一个类是要接受消息进行处理并且跳转到相应的页面的，因为每个模块有有可能接受或者发送消息，所以都需要定义一个这样的类，这样我们就会想到在baseModule中定义一个收消息处理的接口，让每个模块实现这个接口去跳转到本模块的相应页面
base中的消息转发接口：
/**
* Description 每个模块分发标志到对应的页面
*/
public interface TaskDistribution {
void distribution(Context context, String flag, Object... objects);
}
子模块1的跳转实现：
public class Taskimp1 implements TaskDistribution{
@Override
public void distribution(Context context, String flag, Object... objects) {
if(flag.endsWith("login")){
//跳转到登录页面
//context.startActivity(...);
}
if(flag.endsWith("login")){
Intent intent = new Intent(context, ModuleOneActivity.class);
context.startActivity(intent);
}
}
}
子模块2的跳转实现：
public class Taskimp2 implements TaskDistribution {
@Override
public void distribution(Context context, String flag, Object... objects) {
if(flag.endsWith("pay")){
Intent intent = new Intent(context, ModuleTwoActivity.class);
context.startActivity(intent);
}
}
}
到这里仅解决了任务分发到各个子module里面后的启动activity的逻辑，但是在baseModule中怎么拿到各个子工程的引用呢？
新的问题来了…..你是baseModule，你怎么可能拿到Taskimp2和Taskimp1两个类呢？你不依赖他们，而是他们依赖于你呢！
天无绝人之路！
那些有潜力的小伙子终于到你们大显身手的时候了，反射派上用场了！既然我拿不到每个类的名字，那我拿到转发器Taskimp1、Taskimp2的类名总可以了吧？(注意为什么拿转发器而不是类的名字，以为类是很多的，我们不可能知道所有的类的名字，但是我们只定义一个转发器，这个是固定的，所以获取转发器的名字更为现实)
baseModule利用反射获取到非依赖的类全限定名，进行跳转转发：
/**
* Description 用于获取模块转发器的类名
*/
public class Distributor {
private static HashMaphashMap = new HashMap<>();
private static TaskDistribution taskDistribution;
public static void init() {
hashMap.put("m1", "ctrip.module1.Taskimp1");
hashMap.put("m2", "ctrip.module2.Taskimp2");
}
private static void getTaskDistribution(String flag) {
try {
Class c = null;
if (flag != null && flag.startsWith("module1")) {
c = Class.forName(hashMap.get("m1"));
}
if (flag != null && flag.startsWith("module2")) {
c = Class.forName(hashMap.get("m2"));
}
taskDistribution = (TaskDistribution) c.newInstance();
} catch (ClassNotFoundException e) {
e.printStackTrace();
} catch (IllegalAccessException e) {
e.printStackTrace();
} catch (InstantiationException e) {
e.printStackTrace();
}
}
public static void turn2Acitivity(Context context, String flag, Object... objects) {
getTaskDistribution(flag);
taskDistribution.distribution(context, flag, objects);
}
}
这个Distributor我们把所有的方法耦合到一个类里面其实是不太好的，比如hashMap用不用呢？比如能不能自由选择添加module而不是init把所有的module都添加进去呢？完全自己可以根据业务需求扩展，但是源头就是在这个类中。
总结下来我们就会发现这个模块间通信其实用的就是：反射+多态
项目地址：https://github.com/buder-cp/DesignPattern/tree/master/Android-Module-Protocol-master
参考：https://blog.csdn.net/LosingCarryJie/article/details/78760204
