写在前面
以前听说过一句话,说是** 自己写过代码总量没有超过10w行谈设计模式那都是耍流氓 **。我信了,所以一直没怎么系统的看已经买了的《Android源码设计模式》。最近有个小伙伴在群里问recyclerview怎么刷新数据,以前大概也做过,流程也就是那么两步:1.更新Adapter里数据集的引用,让他指向最新的数据集。2.调用Adapter的notifyDataSetChanged()来更新ui。之后小伙伴又问了notifyDataSetChanged()到底如何更新ui的,当时只是看出了一个观察者模式,还有一些细节没想明白。而且讲真的观察者模式的应用还是非常多的,无论是Android还是最近很火的RxJava,其中都可以看到观察者模式的身影,所以决定这周把观察者模式撸一遍。
1、什么是观察者模式
观察者模式(Observer Pattern)定义了对象间一种一对多的依赖关系,使得每当一个对象改变状态,则所有依赖于它的对象都会得到通知并被自动更新,观察者模式又叫做发布-订阅(Publish/Subscribe)模式。
定义总是这么精准而抽象,让我们结合一些Android中的场景来简单的理解一下:在Android最常用的点击事件,我们会通过设置控件的OnClickListener并传入一个OnClickListener的实现类来回调点击事件。这种我们便可以将之看做一个观察者模式。我们的OnClickListener是观察者,被观察者是控件,当有点击事件的时候控件发布点击事件,观察者OnClickListener就会接收到点击事件。当然了,说到底,就是回调。
2、用回调写一个简单的观察者模式
首先我们想一个生活中的场景,来凑个观察者模式出来。平时我们要烧水吧,总要派个人看着,水烧开的时候把电源拔了装水。在这个场景里水壶就是被观察者(Observable),观察者(Observer)就是人。首先我们用以上我说的,那玩意就是回调,用回调来写一个看看。那我们先写一个被观察者“水壶”来看看:
1 | public class Kettle<T> { |
首先我们这个水壶是被观察者,内部肯定要维护一个观察者的引用,或者一个观察者队列的引用,方便我们进行回调,当然更多的事我们尽量不要通过Observer这个东西来做,在这个观察者模式中我希望Observer仅仅作为一个纯粹的回调。因为观察模式本身的特性之一就是解耦,如果你要通过Observer干更多的事无疑会加重Observable和Observer之间的耦合。更多信息可以看代码,我注释已经写得很详细了。
接下来看看上面提到的那个Observer我是咋写的:
1 | public interface Observer<T> { |
很简单的一个接口,写上泛型,嗯,顺便练习一下泛型…只有一个方法,用来回调。有接口那我们肯定要有实现类,我这个场景里说了,人是观察者,于是我写了一个Observer的实现类:
1 | public abstract class People implements Observer<String> { |
我把这个People设计为一个抽象类,这样我可以在接收到这个事件的时候做一些简单的处理(把他打印出来……),然后再把具体的逻辑交给这个抽象类的子类来做,我这逻辑比较简单,就没传什么参数进去了。最后免不了跑起来看看了~
1 | public class Test { |
这里实现了一个加单的观察者模式,观察者也只能注册一个,不过例子么,简单的才容易看懂嘛接下来看一下Java util里自带的Observable和Observer,看一下别人的套路
3、Java中的观察者模式
在Java的util包里也有Observable和Observer那么这俩兄弟跟我们上面自己实现的有啥不同呢?首先还是那个水壶的例子,有了上面的基础,我就直接把所有的类和测试代码甩上来了,相信以各位看官的实力都是小case:
1 | public class HelloWorld { |
之后还是看一下运行结果
代码上完了,那么这里实现的观察模式又是个什么套路呢?不比比直接看源码,先从简单的Observer看起:
1 | public interface Observer { |
我去,这跟我上面的设计不符啊…这货怎么把Observable传过来了…这只是设计类和接口的一些设计理念不一样,作为jdk他需要考虑各种兼容性和安全性的问题,所以不可能像我们客户端程序员一样,很多时候写的都非常任性。先不扯那么多,我们要看的是套路~这玩意是个接口,就像我说的那样,做个回调就行了,剩下的都交给实现类来操心。
看完了Observer我们再来看看Observable:
1 | public class Observable { |
可以看出Observable内部使用了一个Vector来维护订阅的Observer,关于Vector这里不做更多的了解,在这就把他当做一个普通的Observer容器就行了。让我们看看和这个容器有关的套路,为了防止各位产生代码疲劳,我特意贴心的给各位截了个图23333333:
添加和删除Observer就是在容器obs里做增删操作,这套路很简单,不过为了线程安全加了个synchronized。之后看一下重点,通知Observers时调用的notifyObservers(),notifyObservers()最终会调用他自身带参的重载方法,看下代码:
1 | public void notifyObservers(Object arg) { |
先除去那大段的注释不看,这里就是拿到Observable内部维护的Observer容器,然后遍历回调这些Observer的update方法以实现让所有Observer收到通知。但是后面那段代码被执行是有条件的,就是Observable内部的changed字段为true才会执行,而这个字段只有通过setChanged()方法来将其值置为true。但是在上面的源码中我们可以发现这个方法是protected修饰的,所以不通过特殊手段的话,我们只有通过继承才能来调用这个方法了。所以在我以上的实现代码中是有一个继承于Observable的类的。
回头再看看那段注释(自己的烂翻译…有错请指出…):
我们不想让Observer在持有他自己的监听时在回调任意代码。抽取这段代码存储存储Observer需要同步的状态,但是并不通知这些Observer。任何潜在的竞争条件可能会导致的最坏情况是:
- 新添加的Observer将会错过一个正在进行的通知
- 最近被解除注册的Observer可能会错误的同步一个他不关心的玩意
这些东西说实话,我只是有一点点想法,并不能说的很清楚。我觉得是多线程情况下这段代码需要加上一个同步锁,不然可能会引发他注释里写的那两点糟糕的情况。我接触的多线程还是有点少的,所以这段我就先这么翻着,而且这对我们理解观察者模式的套路并没有非常大的影响。
分析完了Java中的观察者模式,接下来回到文章最前面提到的那个问题,RecyclerView中的ui更新到底是咋回事。
4、RecyclerView中的ui更新
其实要弄清楚这个首先得看Adapter,因为Adapter才是掌控数据集的那个。那么让我们来看一下RecyclerView.Adapter的nonotifyDataSetChanged()方法
1 | public final void notifyDataSetChanged() { |
继续追踪这个源码,看看咋回事
1 | static class AdapterDataObservable extends Observable<AdapterDataObserver> { |
可以看到notifyChanged()这个方法里就两行代码,经过上面的一番学习,我闭着眼睛也能猜到mObservers是一个Observer的集合,通过遍历的去调用onChanged,然后这个onChanged是回调。既然知道这一点,那么我们就需要在RecyclerView中找到Observer的具体实现类,不过在此之前我们找孩子之前得先找他爸~很简单,追踪onChanged()的源码,看看到底是谁的方法。
1 | public static abstract class AdapterDataObserver { |
找到了,都是空方法,你可能回说这还不是接口,没事,接口能做的抽象类也能做,我们只要找这个抽象类的孩子就行了。鸡贼的我果断ctrl+f输入了我的查找:
看一下他的源码:
1 | private class RecyclerViewDataObserver extends AdapterDataObserver { |
这里简单的看一下第一行代码是检查recyclerview,如果有错就会抛异常。之后第一个if,不看了,默认是false,那么就看第二个条件内的代码。第一个是存储一个状态,第二个是我们要看到的东西了,点进去看下源码:
1 | private void setDataSetChangedAfterLayout() { |
可以看到它会遍历ViewHolder,然后给holder添加flag:** FLAG_ADAPTER_POSITION_UNKNOWN**这个flag会让viewholder重新绑定到recyclerview上以确定自己的position,最后一个方法会让缓存的viewholder也打上上面提到的flag。
最后再回顾一下(如果有纰漏敬请指出,因为我这源码也没非常仔细的阅读):
在想要更新RecyclerView的界面时,我们通常会先更新数据源(List之类的),然后调用Adapter的notifyDataSetChanged()方法
在RecyclerView内部notifyDataSetChanged()方法调用了mObservable.notifyChanged();而mObservable是一个被观察者。
在RecyclerView内部找到mObservable的真实类型,发现是RecyclerViewDataObserver,寻找notifyChanged()时会调用的onChanged()方法。
发现onChanged()方法最终会给viewholder设置flag,让他们重新绑定到RecyclerView上,在重新绑定的过程中无疑是会在onBindViewHolder里重新设置数据的,而数据源我们已经更新过了,新的数据就会被显示到界面上,以上就是这整个流程了。
5、最后的一点思考
说实话最近在写东西的时候经常用回调,因为一些工具类或者dialog、window之类的,在自己自定义的时候通常需要回调把点击事件传出来,不然感觉传view设置点击什么的感觉也挺麻烦的,不如我里面逻辑处理好,就把点击事件传出来就好了。但是写到后面我这又是用的MVP,activity里各种回调满天飞,不过怎么说呢,我自己写的,我看起来逻辑还是很清晰的。如果是后面来人接手呢?虽然我注释写的都很清晰了,但是他在阅读代码的时候不得不深入我的工具类或者dialog window里去看我这个回调到底干了什么,所以这种方便自己麻烦别人的东西,我现在在想到底是算好的代码风格还是差的,有点糊涂。
好了,也挺久没发文了,而且干了七天,相信大家都很累了,休息休息了,祝各位有一个好的周末。
最后安利一下这个主播,小缘,安静听歌的感觉不错
参考资料:
《Android源码设计模式》