当观察者模式和回调机制遇上Android源码

亦余心之所善兮,虽九死其犹未悔。这篇文章主要讲述当观察者模式和回调机制遇上Android源码相关的知识,希望能为你提供帮助。
上一篇博客跟大家分享了android源码中的装饰者模式,有点意犹未尽,今天跟大家分享下Android中的观察者模式,顺便说一说观察者模式和回调机制的关系,欢迎大家拍砖。
观察者模式定义观察者模式定义了一种一对多的依赖关系,让多个观察者对象同时监听某一个主题对象。这个主题对象在状态上发生变化时,会通知所有观察者对象,使它们能够自动更新自己。
观察者模式的结构

当观察者模式和回调机制遇上Android源码

文章图片

观察者模式所涉及的角色有:
  • 抽象主题(Subject)角色:抽象主题角色把所有对观察者对象的引用保存在一个聚集(比如ArrayList对象)里,每个主题都可以有任何数量的观察者。抽象主题提供一个接口,可以增加和删除观察者对象,抽象主题角色又叫做抽象被观察者(Observable)角色。
  • 具体主题(ConcreteSubject)角色:将有关状态存入具体观察者对象;在具体主题的内部状态改变时,给所有登记过的观察者发出通知。具体主题角色又叫做具体被观察者(Concrete Observable)角色。
  • 抽象观察者(Observer)角色:为所有的具体观察者定义一个接口,在得到主题的通知时更新自己,这个接口叫做更新接口。

  • 具体观察者(ConcreteObserver)角色:存储与主题的状态自恰的状态。具体观察者角色实现抽象观察者角色所要求的更新接口,以便使本身的状态与主题的状态 像协调。如果需要,具体观察者角色可以保持一个指向具体主题对象的引用。
实现抽象主题角色类
public abstract class Subject { /** * 用来保存注册的观察者对象 */ privateList< Observer> list = new ArrayList< Observer> (); /** * 注册观察者对象 * @param observer观察者对象 */ public void attach(Observer observer){list.add(observer); System.out.println("Attached an observer"); } /** * 删除观察者对象 * @param observer观察者对象 */ public void detach(Observer observer){list.remove(observer); } /** * 通知所有注册的观察者对象 */ public void nodifyObservers(String newState){for(Observer observer : list){ observer.update(newState); } } }

具体主题角色类
public class ConcreteSubject extends Subject{private String state; public String getState() { return state; }public void change(String newState){ state = newState; System.out.println("主题状态为:" + state); //状态发生改变,通知各个观察者 this.nodifyObservers(state); } }

抽象观察者角色类
public interface Observer { /** * 更新接口 * @param state更新的状态 */ public void update(String state); }

具体观察者角色类
public class ConcreteObserver implements Observer { //观察者的状态 private String observerState; @Override public void update(String state) { /** * 更新观察者的状态,使其与目标的状态保持一致 */ observerState = state; System.out.println("状态为:"+observerState); }}

测试类
public class Test {public static void main(String[] args) { //创建主题对象 ConcreteSubject subject = new ConcreteSubject(); //创建观察者对象 Observer observer = new ConcreteObserver(); //将观察者对象登记到主题对象上 subject.attach(observer); //改变主题对象的状态 subject.change("new state"); }}

观察者的两种实现方式
  • Push
    主题对象向观察者推送主题的详细信息,不管观察者是否需要,推送的信息通常是主题对象的全部或部分数据。
  • Pull
    【当观察者模式和回调机制遇上Android源码】主题对象在通知观察者的时候,只传递少量信息。如果观察者需要更具体的信息,由观察者主动到主题对象中获取,相当于是观察者从主题对象中拉数据。一般这种模型的实现中,会把主题对象自身通过update()方法传递给观察者,这样在观察者需要获取数据的时候,就可以通过这个引用来获取了。
两种方式的比较
  • Push模型是假定主题对象知道观察者需要的数据;而Pull模型是主题对象不知道观察者具体需要什么数据,没有办法的情况下,干脆把自身传递给观察者,让观察者自己去按需要取值。
  • Push模型可能会使得观察者对象难以复用,因为观察者的update()方法是按需要定义的参数,可能无法兼顾没有考虑到的使用情况。这就意味着出现新情况的时候,就可能提供新的update()方法,或者是干脆重新实现观察者;而Pull模型就不会造成这样的情况,因为Pull模型下,update()方法的参数是主题对象本身,这基本上是主题对象能传递的最大数据集合了,基本上可以适应各种情况的需要。
回调机制和观察者模式Android中有非常多的地方使用了回调机制,例如Activity的生命周期、按钮的点击事件、线程的run()方法等。
下面是回调的基本模型:
public interface CallBack { public void oncall(); }public class A { private CallBack callback; //注册一个事件 public void register(CallBack callback){ this.callback = callback; } // 需要调用的时候回调 public void call(){ callback.oncall(); } }public static void main(String[] args) { A a = new A(); a.register(new CallBack() { @Override public void oncall() { System.out.println("回调函数被调用"); } }); a.call();

}
这样看来,回调机制和观察者模式是一致的,区别是观察者模式里面目标类维护了所有观察者的引用,而回调里面只是维护了一个引用。
Android中的观察者模式Android中大量的使用了观察者模式,Framework层里面的事件驱动都是基于观察者模式实现的。另外在Framework层里面的各种服务在数据变更的时候,也是通过观察者模式实现上层数据更新的。像View的Listener监听、GPS位置信息监听、BroadcastReceiver等都是基于观察者模式实现的。下面我们说一说ListView中的观察者模式是如何实现的,RecyclerView大同小异,感兴趣的可以自己研究下。
Listview的notifyDataSetChanged()我们先来看下listview部分观察者模式的结构
当观察者模式和回调机制遇上Android源码

文章图片

其中为了方便研究关系,我们省略了Adapter部分的一些类的关系。接下来我们看下具体调用关系。
首先当我们数据改变的时候我们会调用adapter的notifyDataSetChanged()方法。
/** * Common base class of common implementation for an {@link Adapter} that can be * used in both {@link ListView} (by implementing the specialized * {@link ListAdapter} interface) and {@link Spinner} (by implementing the * specialized {@link SpinnerAdapter} interface). */ public abstract class BaseAdapter implements ListAdapter, SpinnerAdapter { private final DataSetObservable mDataSetObservable = new DataSetObservable(); public boolean hasStableIds() { return false; }public void registerDataSetObserver(DataSetObserver observer) { mDataSetObservable.registerObserver(observer); }public void unregisterDataSetObserver(DataSetObserver observer) { mDataSetObservable.unregisterObserver(observer); }/** * Notifies the attached observers that the underlying data has been changed * and any View reflecting the data set should refresh itself. */ public void notifyDataSetChanged() { mDataSetObservable.notifyChanged(); }/** * Notifies the attached observers that the underlying data is no longer valid * or available. Once invoked this adapter is no longer valid and should * not report further data set changes. */ public void notifyDataSetInvalidated() { mDataSetObservable.notifyInvalidated(); } }

根据上述代码我们可以定位到mDataSetObservable.notifyChanged()方法。
/** * A specialization of {@link Observable} for {@link DataSetObserver} * that provides methods for sending notifications to a list of * {@link DataSetObserver} objects. */ public class DataSetObservable extends Observable< DataSetObserver> { /** * Invokes {@link DataSetObserver#onChanged} on each observer. * Called when the contents of the data set have changed.The recipient * will obtain the new contents the next time it queries the data set. */ public void notifyChanged() { synchronized(mObservers) { // since onChanged() is implemented by the app, it could do anything, including // removing itself from {@link mObservers} - and that could cause problems if // an iterator is used on the ArrayList {@link mObservers}. // to avoid such problems, just march thru the list in the reverse order. for (int i = mObservers.size() - 1; i > = 0; i--) { mObservers.get(i).onChanged(); } } }/** * Invokes {@link DataSetObserver#onInvalidated} on each observer. * Called when the data set is no longer valid and cannot be queried again, * such as when the data set has been closed. */ public void notifyInvalidated() { synchronized (mObservers) { for (int i = mObservers.size() - 1; i > = 0; i--) { mObservers.get(i).onInvalidated(); } } } }

我们看到,调用notifyChanged()方法,会去遍历mObservers,调用所有观察者的onchange()方法。
那么问题来了,我们的观察者对象是什么时候添加进去的呢?我们去看下ListView第一次和BaseAdapter产生关联的地方,也就是setAdapter(ListAdapter adapter)方法。
@Override public void setAdapter(ListAdapter adapter) { //如果已经设置过了Adapter,那么取消注册对应的观察者。 if (mAdapter != null & & mDataSetObserver != null) { mAdapter.unregisterDataSetObserver(mDataSetObserver); }//省略部分代码if (mAdapter != null) { mAreAllItemsSelectable = mAdapter.areAllItemsEnabled(); mOldItemCount = mItemCount; mItemCount = mAdapter.getCount(); checkFocus(); //创建一个对应数据的观察者 mDataSetObserver = new AdapterDataSetObserver(); //间接调用DataSetObservable的注册方法 mAdapter.registerDataSetObserver(mDataSetObserver); //省略部分代码 } else { mAreAllItemsSelectable = true; checkFocus(); // Nothing selected checkSelectionChanged(); }requestLayout(); }

这样我们的四个角色就全了,Observable—> Subject; DataSetObservable—> Concrete Subject; DataSetObserver—> Observer; AdapterDataSetObserver—> Concrete Observer。然后我们注册的地方也找到了。
最后就剩下我们的数据是如何刷新这一个问题了。AdapterDataSetObserver定义在ListView的父类AbsListView中,它又继承自AbsListView的父类AdapterView的AdapterDataSetObserver。
class AdapterDataSetObserver extends DataSetObserver {private Parcelable mInstanceState = null; //当我们调用Adapter的notifyDataSetChanged的时候会调用所有观察者的onChanged方法,核心实现就在这里 @Override public void onChanged() { mDataChanged = true; mOldItemCount = mItemCount; // 获取Adapter中数据的数量 mItemCount = getAdapter().getCount(); // Detect the case where a cursor that was previously invalidated has // been repopulated with new data. if (AdapterView.this.getAdapter().hasStableIds() & & mInstanceState != null & & mOldItemCount == 0 & & mItemCount > 0) { AdapterView.this.onRestoreInstanceState(mInstanceState); mInstanceState = null; } else { rememberSyncState(); } checkFocus(); // 重新布局ListView、GridView等AdapterView组件 requestLayout(); }// 代码省略public void clearSavedState() { mInstanceState = null; } }

requestLayout()方法在View里有实现,子View按需求重写。我们看下注释好了。
/*Call this when something has changed which has invalidated the layout of this view. This will schedule a layout pass of the view tree./
好了,到这里所有的调用关系我们基本就搞清楚了。当ListView的数据发生变化时,调用Adapter的notifyDataSetChanged函数,这个函数又会调用DataSetObservable的notifyChanged函数,这个函数会调用所有观察者 (AdapterDataSetObserver) 的onChanged方法。在onChanged函数中会获取Adapter中数据集的新数量,然后调用ListView的requestLayout()方法重新进行布局,更新用户界面。
瞎总结ListView主要运用了Adapter和观察者模式使得可扩展性、灵活性非常强,而耦合度却很低,这是我认为设计模式在Android源码中优秀运用的典范。那我们就要开始思考了,我们有没有其他更漂亮的套路来实现ListView组件,我们可以把这件实现思路应用到哪里?
人是会思考的芦苇,思考着思考着我们就成为了别人眼中的大神。
参考链接:
http://www.itdadao.com/articles/c15a265623p0.html
http://blog.csdn.net/bboyfeiyu/article/details/44040533
http://www.cnblogs.com/mythou/p/3370340.html


    推荐阅读