1. Handler方式
Handler 方式是了解了 Handler 的人最容易想到的，但是 Handler 不仅会增加各个模块之间的耦合性，而且只能单向通信，例如如果在 Activity 中实例化 Handler ，那么就只能由 Fragment 向 Activity 发送消息，而如果反过来 Activity 向 Fragment 发送消息则不易实现，既然不能双向，那么 Fragment 之间的通信也就无法实现了。
2. 接口方式
接口方式是最简单易用的方式，当我确定 Handler 方式无法满足需求的时候，我立刻想到了接口。但当我经过一番实践，发现接口方式仍然不行，如果只是一对一通信，那么接口或许是最好的方案，不仅轻便，而且丝毫不影响性能。但如果是一（Activity）对多（Fragment）通信，那么只能是由 Activity 来实现接口，Fragment 调用该接口，向 Activity 发送消息；反过来就不行了，需要定义很多个接口，每个 Fragment 需要实现不同的接口，然后 Activity 实例化每一个接口来调用，如果有数十个 Fragment 需要向 Activity 发送信息，那么就得让 Activity 实现数十个接口，这得是多么愚蠢的事情，并且使用接口也还是无法实现 Fragment 之间的通信。
3.共有方法
至于公有方法，也就是互相调用对方被公开的方法。比如可以在 Fragment 中调用宿主 Activity 中的公有方法，也可以通过宿主 Activity 查找到其他 Fragment ，然后可以在 Activity 中稍作判断，继而再调用本身或者其他 Fragment 中的方法。然而这样会大大增加程序之间的耦合性，不利于以后的维护和扩展。
4.发广播
广播是一种能够面向系统中所有应用程序发送通知的机制，使用广播来完成单一 APP 内部的消息通信，有点杀鸡焉用牛刀的感觉，另外通过广播需要被发送的对象实现序列化接口，会略微影响性能，所以一般不使用广播来进行通信。
5.EventBus
EventBus 的核心也是观察者模式，通过订阅事件来收取通知信息，同时通过反射找到对应的方法名来实现消息的通信，肯定也是会对性能有一定的影响（3.0 版本已经不再使用反射，而是通过注解实现，免去了反射查找方法的诸多弊端），如果代码混淆的时候保留对 EventBus 的混淆，则会暴露方法名，给逆向留下口子，可如果强制混淆，又会导致无法通过反射来找到对应的方法。
