相信此时应该明白了EventBus的作用，当然有人会问，那么多界面都注册了EventBus，他怎么知道二页君说的是哪个。可以看一下post方法里的参数，这个就是维系主页和二页的通道了，上帝是通过这个参数来判断的。首页里的这个方法public void onEventMainThread（MyEvent event）里这个参数和post里的参数一样就行了。这个MyEvent不用继承任何类不用实现接口，就是个普通的javaBean（可以携带值），或者就是个空类也行（只做个联系的标记）。还提一个就是可能不只首页要监听第二页的触发，也许有很多个地方（可以不是界面，就一个工具类譬如DB处理类也行）都要监听第二页的触发，那只需要所有监听的都去注册一下自己写明Event是哪个就行了，然后就等着上帝一个一个的捅你菊花就行了。是不是这种感觉很美妙！！！


    根据以往做过的一些场景，我觉得有几个地方是非常适合eventbus来处理的。

    一：注册页面，在注册页面填写了手机号、个人信息，传头像操作后，注册成功了，进入了主界面。此时我们需要在主界面关闭之前的注册的所有页面，此时就可以使用eventbus来通知前几个注册用的activity来关闭自己。这样的目的就是当注册失败时，用户按返回键还是能回到填写信息页。当注册成功后，按返回键就直接退出程序，不再保留注册填信息页了。

二：activity和fragment有交互的场景。这个是最常见的，一个activity里有个viewpager包含几个fragment，activity界面上有类似于全选、计算总额等等之类需要和某个或多个fragment通信的，由于这个控件属于activity是个全局的，而数据都在各个fragment里，所以他们之间的相互响应是比较麻烦的。

三：流程跨多个界面的。譬如一次拍照发朋友圈的操作，在第一页可以选择写文字、拍照、打开相册的操作，然后不同的操作决定了几个不同的流程线，期间要经历几个过渡页面（相册页，裁剪页之类的），但最终对于第一页我们关心的其实就是图片的本地地址和文字，中间的过渡页面是没有意义的。但是呢这些过渡页不同的处理又会对第一页产生不同的结果，此时就需要一个完全解耦的eventbus来处理结果。而不能把第一页的某个引用往外传递，要不然会很难处理。

四：观察者中有相对比较独立的处理逻辑时。譬如要做一个文件传输备份的功能，主页上要有个地方显示当前有多少个正在传输之类的，然后在后台某个地方有文件传输的功能正在传文件，此时还有一个类似于第三方监察者来观察这个传输流程（记录传输结果到数据库，传输中断控制等）。这种功能就是一个被观察者（传输文件）有多个观察者（界面、DB工具类、守护线程），此时eventbus能提供较小的耦合度，来避免被观察者负担过重做太多的对外逻辑处理，只需要管自己的传输就行了。

五：有推送功能，收到推送后需要不同的页面或者不同的工具类来做处理的。

其他的想起来了再补充。