引用《Android源码设计模式》一书中对观察者模式的总结：
优点：观察者模式主要的作用就是对象解耦，将观察者和被观察者完全隔离，只依赖于Observer和Observable的抽象，可以增强系统的灵活性、可扩展性。
缺点：没有彻底解耦，仍然需要依赖抽象，并且Java中消息的通知默认是顺序执行，一个观察者卡顿，会影响整体的执行效率，在这种情况下，一般考虑采用异步的方式。
其实我没有明白这里说的缺点中，一个观察者的卡顿，会什么会影响整体的执行效率，难道说，必须是调用一个观察者的notify方法结束后，再调用第二个观察者的notify方法？通过本文中的demo，最后打印的log得知，确实如此。
这里总结一下，在android中，观察者模式的一般写法，这里以监听登录状态变化为例。
首先是登录信息类MemberInfoLike:
观察者Observer的抽象接口：
被观察者Observable，或者叫Subject的抽象类 , 其实JDK中也有java.util.Observable，但是并没有提供范型支持，所以，这里是继承自android.database.Observable，其中帮我们维护了一个ArrayList，用来保存当前所有的观察者Observer：
protected final ArrayList<T> mObservers = new ArrayList<T>();
然后MainActivity实现Observer接口，即可在MainActivity监听到登录状态的变化，
随便拖了一个页面布局，两个按钮，模拟登录操作：
为了证明一开始的那个疑问，即是否所有的观察者Observer的notify方法都是顺序同步执行的，打印了log：
得出结论，所有的观察者，都是顺序被回调notify方法的。这应该就是观察者模式的缺点之一，所以一般应该采用异步的方式来实现，以后有时间，应该说是会写异步的观察者模式了，再补上。。。
观察者模式的另外一个缺点就是，没有彻底解耦，抽象的observable仍然依赖抽象的observer，所以，如果要彻底解耦，那么可以参考下文：
后续有时间了，会再加上一篇分析观察者模式在android源码中的使用。