一、Android消息传递之Handler消息机制（www.cnblogs.com/whoislcj/p/5590615.html）
1.前言：无论是现在所做的项目还是以前的项目中，都会遇见线程之间通信、组件之间通信，目前统一采用EventBus来做处理，在总结学习EventBus之前，觉得还是需要学习总结一下最初的实现方式，也算是不忘初心吧，这也是今天来学习总结Handler消息机制的一个原因。
2.Handler机制产生背景：一个Android应用程序被创建的时候都会创建一个UI主线程，但是有时我们会有一些比较耗时的操作，为了防止阻塞UI主线程，我们会将耗时的操作放到子线程中进行处理，处理完之后操作UI，但是Android不允许子线程操作UI，违背了Android单线程模型的原则（即 Android UI操作并不是线程安全的并且这些操作必须在UI线程中执行），所以Android通过Handler消息机制来实现线程之间的通讯。
3.Handler机制主要角色
Message：消息，其中包含了消息ID，消息处理对象以及处理的数据等，由MessageQueue统一列队，终由Handler处理。
Handler：处理者，负责Message的发送及处理。使用Handler时，需要实现handleMessage(Message msg)方法来对特定的Message进行处理，例如更新UI等。
MessageQueue：消息队列，用来存放Handler发送过来的消息，并按照FIFO规则执行。当然，存放Message并非实际意义的保存，而是将Message以链表的方式串联起来的，等待Looper的抽取。
Looper：消息泵，不断地从MessageQueue中抽取Message执行。因此，一个MessageQueue需要一个Looper。
Thread：线程，负责调度整个消息循环，即消息循环的执行场所。
4.Handler机制主要运用
5.Handler机制扩展 --- 为了更加方便的使用Handler消息机制，Android也提供了几种扩展方式，内部实现都是基于Handler消息机制。
二、Android消息传递之组件间传递消息（www.cnblogs.com/whoislcj/p/5593056.html）
需求场景：之前做图片社交App的时候，需要处理一个点赞数据的同步，比如在作品的详情页点赞 需要同时更新列表页该作品的点赞数量。
1.方式一：通过动态注册BroadcastReceiver
2.方式二：通过自己管理事件监听总线
三、Android消息传递之EventBus 3.0使用详解（www.cnblogs.com/whoislcj/p/5595714.html）
1.EventBus产生需求背景：
在做项目的时候往往需要应用程序内各组件间、组件与后台线程间的通信。比如耗时操作，等耗时操作完成后通过Handler或Broadcast将结果通知给UI，N个Activity之间需要通过Listener通信，之前的实现方式我们在Android消息传递之组件间传递消息（二）中已经介绍过了，其实这些都可以通过EventBus轻松实现，EventBus通过发布/订阅(publish/subscribe)方式来管理事件总线。其实EventBus的实现方式更加接近上篇文章的方式二，不同的是EventBus通过注解和反射机制 将订阅者连同订阅函数保存起来，然后在发送订阅的时候 遍历订阅函数数组进行调用，其实从这方面就可以EventBus执行效率多少会受到一点影响。
2.EventBus介绍：
EventBus出自greenrobot，和之前大名鼎鼎的GreenDao出自同一家。之前一直使用的是2.4版本，今天我们将学习分析最新的Event 3.0，EventBus 3.0 最新的特性就是加入了注解，通过注解的方式 告知订阅函数运行在哪个线程中。
github地址：https://github.com/greenrobot/EventBus
官方文档：http://greenrobot.org/eventbus/documentation
3.EventBus主要角色：
Event 传递的事件对象
Subscriber 事件的订阅者
Publisher 事件的发布者
ThreadMode 定义函数在何种线程中执行
3.EventBus配置：
EventBus框架也是采用建造者模式设计的，可以通过EventBusBuilder来设置一些配置信息，例如设置debug模式下要抛出异常：EventBus eventBus=EventBus.builder().throwSubscriberException(BuildConfig.DEBUG).build();
4.EventBus示例:之前做图片社交App的时候，需要处理一个点赞数据的同步，比如在作品的详情页点赞 需要同时更新列表页该作品的点赞数量，这里还是以此为例。
5.EventBus黏性事件
EventBus除了普通事件也支持粘性事件，这个有点类似广播分类中的粘性广播。本身粘性广播用的就比较少，为了方便理解成订阅在发布事件之后，但同样可以收到事件。订阅/解除订阅和普通事件一样，但是处理订阅函数有所不同，需要注解中添加sticky = true
6.EventBus processor使用：
EventBus提供了一个EventBusAnnotationProcessor注解处理器来在编译期通过读取@Subscribe()注解并解析，处理其中所包含的信息,然后生成java类来保存所有订阅者关于订阅的信息，这样就比在运行时使用反射来获得这些订阅者的信息速度要快。
2.)使用索引
此时编译一次，自动生成生成索引类。在\build\generated\source\apt\PakageName\下看到通过注解分析生成的索引类，这样我们便可以在初始化EventBus时应用我们生成的索引了。自动生成的代码：
7.EventBus 3.0 与2.x的区别
以上还是在一个订阅者仅仅订阅一个事件的情况下，如果订阅多个事件，可想而知EventBus 2.x势必导致订阅者要写大量的多态函数，如果订阅多种类型事件，比如普通事件和粘性事件并存，估计要同时调用register，registerSticky两个函数。
2.）性能更优
EventBus 2.x 是采用反射的方式对整个注册的类的所有方法进行扫描来完成注册，当然会有性能上的影响。EventBus 3.0中EventBus提供了EventBusAnnotationProcessor注解处理器来在编译期通过读取@Subscribe()注解并解析、处理其中所包含的信息，然后生成java类来保存所有订阅者关于订阅的信息，这样就比在运行时使用反射来获得这些订阅者的信息速度要快。
四、Android消息传递之基于RxJava实现一个EventBus - RxBus(www.cnblogs.com/whoislcj/p/5816992.html)
1.RxBus实现过程：
考虑到RxBus单例很有可能多线程并发访问，这种存储事件总线采用ConcurrentHashMap
5.）如何使用
事件的订阅者的注册和清除所有注册，订阅者没订阅一个类型的事件都要返回一个Observable对象，这也是个人觉得比较头疼的一件事，很难实现一个订阅者对应多个事件类型，而且解注册的时候也需要这些Observable对象进行一一解除。
