万能接口
众所周知，现如今绝大多数的APP都是基于Activity和Fragment开发的。如下图中的淘宝app
Fragment，在Android 2.3版本后出现，出现的主要目的就是解决Android碎片化太过严重的问题。
那么Activity和Fragment之间是怎么通信的呢？
如上图所示，上面的每个箭头都表示Activity和Fragment之间的通信。但是一个app不可能只有一个Activity,如果每个Activity和Fragment之间频繁的通信，那么app的耦合度就会非常高。那么有人会说了，我们平常做通信都是用第三方，诸如 EventBus、 Rxbus等等。Fragment之间也是Fragment也是通过这些工具也没出过问题啊。
那么重点来了，谷歌官方明确规定
Two Fragments should never communicate diretly.
翻译过来的意思就Fragment之间不允许有直接的通信。因为会造成耦合多高的问题。
其他通信的方式分析
1. EventBus
优点：使用方便，快捷
缺点：
1.大家知道EventBus内部通过反射进行操作，而反射在Android中则会对性能有部分的损耗。而我们的App中，UI显示的速度以及相应时间则尤为重要，可能短暂的延迟和卡顿就会降低用户使用体验度；
2.后期代码维护相对比较困难，想当初学习的时候，各种蒙比，有时候甚至找不到传递的值在哪儿接收；
3.而最重要的一点则是，EventBus是单向传递数据，通俗来讲就是不能返回数据，这边就比较恶心了。
2. handler
优点：能解决问题
缺点：
1.与其配合使用统一反应出的问题就是耦合度太高；
2.无法获取activity的返回结果。比如Fragment发送一个数据到Activity中 要求Activity处理完之后返回到Fragment中，那么这时候Handler有点low了；
3.内存泄漏
3. Static
缺点：用static修改的变量等一般都是存在于内存中，当多个变量存在的时候，便会加大系统内存，无形中也在消耗系统资源
4. 广播
首先要明确，虽然我们玩广播几行代码的事儿，但是我们要知道，广播机制以及内部实现是一个非常庞大且非常复杂的系统应用，同时，也一般被应用于监听系统为主，例如开机，接收短信等等
缺点如下：
1.性能差 有延迟；
2.传播的数据有限；
3.代码冗余，而且一个广播发出，会在多个地方被接受到，无形中消耗资源
5. 接口
优点：
优点 简单 效率高 方便 解耦合
缺点：
代码冗余 每个通信的fragment 都必须定义自己独一无二的接口
原文：https://blog.csdn.net/u012400885/article/details/77892974
我们对接口的方式单独分析下：我们知道，通过接口的方式，每个Fragment都要定一个接口，如果一个Activity需要执行这些接口，那么Activity都需要执行每个接口代码，造成代码量和工作量的增加。
那么今天我们通过接口的方式封装一个万能接口，减少代码量，完成基本的Activity与Fragment，Fragment与Fragment的通信。
先分析下接口：
一个接口包含了: 接口名称、接口返回值、接口参数、没有执行的函数体。
针对返回值和接口的参数有四种状态：
1、无参数无返回值
2、无参数有返回值
3、有参数无返回值
4、有参数有返回值
创建一个接口基类
根据四个状态创建四个接口类实现基类：
1、无参数无返回值
2、无参数有返回值
3、有参数无返回值
4、有参数有返回值
定义完所有的接口抽象类之后，我们在定义一个接口管理类，通过接口管理类来管理调用对应的函数方法：
然后，定义一个要使用回调接口的Fragment的基类。
BaseFragment类：
在MainActivity中添加具体执行
好了，我们测试一下无参有返回值的通知。该通知是FragmentTwo发出的，在MainActivity接收。
那么如果是Fragment之间是要怎么通信呢？前面我们也讲了官方为了降低耦合性不允许Fragment之间的交互。那么我们可以通过Activity的桥梁联系.
Fragment1 --> Activity -->Fragment2
我们来做个图说明
分析一下之前的FunctionManager
1、针对不同的类型，需要用不同的容器来盛放
2、提供添加“接口”到管理类里的方法
3、提供调用不同类型“接口”的方法
4、最好能支持链式调用
综合以上的条件我们可以看到 页面间的交流通知全部通过链式的方式添加到了FunctionManager类中，这里我们使用HashMap的链式方式通过方法名从管理类中取出接口的执行，大大解耦.
