《Android源码设计模式解析与实战》第12章观察者模式笔记
介绍
观察者模式定义对象间的依赖关系，使得每当一个对象改变状态，则所有依赖它的对象都会得到通知并且被自动更新。
观察者模式的使用还是比较多的，它比较常用的地方是GUI、订阅–发布系统。这个模式的一个重要作用就是解耦，使观察者和被观察之间的依赖变小。比如GUI系统中，业务的改变，应用的界面也会随之变化，但是业务逻辑基本变化不大，此时，GUI系统需要一套机制来应对这种变化，使得UI层与具体的业务逻辑解耦，观察者模式此时就派上用场了。
关于观察者涉及模式的UML和使用可以看这里
使用场景
关联行为场景，需要注意的是，关联行为是可拆分的，而不是‘组合’关系
事件多级触发
跨系统的消息交换场景，如消息队列、事件总线的处理机制。
Android源码中的使用
1.） ListView中的使用
ListView是Android中比较重要的一个控件，而ListView最重要的一个功能就是Adapter，通常，在我们往ListView添加数据的时候，都会调用Adapter的notifyDataSetChanged()方法来更新界面。对它的源码讲解可以看这篇
大致总结下它的过程，AdapterView中有一个内部类AdapterDataSetObserver，在ListView中设置Adapter时会构建一个AdapterDataSetObserver，并且注册到Adapter中，这就是一个观察者。而Adapter中包含一个数据集可观察者DataSetObservable，在数据数量发生变化的时候，开发者手动调用Adapter.notifyDataSetChanged，而它实际上会调用DataSetObservable的notifyChanged函数，该函数会遍历所有观察者的onChanged函数。在这个函数中会获取Adapter中数据集的新数量，然后调用ListView的requestLayout()方法重新布局，更新用户界面。
2.）BroadcastReceiver中的使用
BroadcastReceiver是Android的四大组件之一，它是应用内，进程间的一种重要通信手段，它也是一个典型的发布–订阅模式，也就是观察者模式。具体内部实现方式可以看这篇文章BroadcastReceiver注册和发送过程
3.）EventBus中的使用
EventBus在我们平时项目开发过程中使用也很多，它是线程间，页面间通信的一种常用框架，可以大大简化页面间的耦合，用户只需要通过post发送事件，而接受方只需要通过register注册事件，就可以进行通信了。它也是观察者涉及模式，具体的内部实现可以看这里
比较常用的还有Otto，但是它的效率比不上EventBus，以及AndroidEventBus，使用得也很方便，但是效率比不上EventBus，框架的内部大多使用得观察者设计模式。通过查看它们的源码可以加深我们对设计模式的理解。
总结
观察者涉及模式主要的作用就是对象解耦，将观察者和被观察者完全隔离，使得代码达到一种低解耦、高灵活性的作用。
优点：
观察者和被观察者之间是抽象耦合，应对业务变化。
增加系统灵活性、可扩展性
缺点：
- 在应用观察者模式时候需要考虑下开发效率和运行效率问题，程序中包含一个被观察者、多个观察者、开发和调试等内容会比较复杂，而在java中消息的通知默认是顺序执行，一个观察者卡顿，会影响整体的执行效率，在这种情况下，一般考虑采用异步的方式。