主目录见：Android高级进阶知识（这是总目录索引）
这篇文章我们会来讨论另外一个设计模式观察者设计模式，这个设计模式应该来说好理解很多，这个设计模式在我们平常的框架编写中也是可能会被用到的，我们同样的，来看看它的定义：

观察者模式：定义了对象之间的一对多依赖，当一个对象改变状态时，它的所有依赖者都会收到通知并自动更新。

这个定义也不抽象，所谓的定义对象之间的一对多依赖这个很好理解，就是说一个被观察者对应于多个观察者，然后被观察者的状态发现改变，那么就会通知订阅了这个状态变化的观察者。如果还是觉得比较抽象，我们等会会讲，现在先来看下UML类图：

观察者模式

角色介绍：

• Observable:被观察者的接口，定义了一些被观察者需要的方法，比如addObserver添加观察者，deleteObserver删除观察者，notifyObservers通知所有的观察者状态变了。
• Observer:观察者接口，定义了一些观察者需要的方法,比如update更新观察者。
• ConcreteObservable:被观察者，实现了Observable接口，具体实现了Observable接口里面的方法，而且里面有观察者的集合，在通知的时候可以通知到所有的观察者。
• ConcreteObserver:观察者，实现了Observer接口，具体实现了update更新方法，同时在适当的时机会将观察者添加到被观察者的集合里面。

一.目标

这个设计模式学过java的人应该都非常熟悉，java内部有默认实现观察者和被观察者这个角色，可想而知，这个设计模式的用处应该是非常广的，今天我们的目标：
1.明白观察者模式怎么使用；
2.知道在什么场景需要用到观察者模式。

二.模式解析

我们今天就先假设一个场景，比如我们要去学校图书馆借书，但是图书馆这类书没有了，那么我们就在图书馆登记一下，然后图书馆这类书有人还了就通知这几个登记过的人说来借阅吧。这里图书馆就是我们的被观察者了。我们就先来创建我们的被观察者接口和被观察者吧。

1.Observable ConcreteObservable

public interface Observable {
      void addObserver(Observer observer);
      void deleteObserver(Observer observer);
      void notifyObservers(String info);
}

我们看到被观察者接口定义了几个观察者需要的，当然可以创建其他可能用到的方法，比如deleteObservers()删除所有的观察者等等。然后我们来看具体的被观察者图书馆：

public class LibraryObservable implements Observable{
    //观察者集合
     private final ArrayList<Observer> observers;
     
    public LibraryObservable() {
        super();
        observers = new ArrayList<Observer>();
    }

    @Override
    public synchronized void addObserver(Observer observer) {
         if (observer == null)
            throw new NullPointerException();
         if (!observers.contains(observer)) {
            observers.add(observer);
         }
    }

    @Override
    public synchronized void deleteObserver(Observer observer) {
        if (observer == null) {
            throw new NullPointerException();
        }
         
        observers.remove(observer);
    }

    @Override
    public void notifyObservers(String info) {
        
        if (observers == null || observers.size() <= 0) {
            return;
        }
        
        for(Observer observer : observers){
            observer.update(info);
        }
    }
}

我们看到具体的被观察者实现了Observable ，并具体实现了方法。其中notifyObservers就是用来通知所有的观察者，因为具体的被观察者里面维护了一个集合，这是简单实现，根据业务当然还会有你自己的实现方法。

2.Observer ConcreteObserver

接着我们看上面的UML类图可以知道，我们还需要观察者接口和具体观察者对象。这里我们的观察者接口和具体观察者会比较简单：

public interface Observer {
     void update(String info);
}

我们看到这里只有一个更新方法，就是用来实现被通知完要做的动作，这里就是学生要去图书馆借书，这个具体动作由观察者完成：

public class StudentAObserver implements Observer {

    @Override
    public void update(String info) {
        System.out.println(info);
    }
}

我们到这里，所有的角色都应该有了，最后我们就来看看怎么使用观察者模式了：

    //观察者学生
        Observer studentA = new StudentAObserver();
        Observer studentB = new StudentAObserver();
        //被观察者图书馆
        Observable library = new LibraryObservable();
        //在图书馆登记
        library.addObserver(studentA);
        library.addObserver(studentB);
        
        //图书馆有书了通知
        library.notifyObservers("书到了，先到先得");

我们看到这里使用很简单，就是现在被观察者里面注册或者说是添加，然后在适当的时机进行通知，被观察者和观察者的关系就是一对多的关系。如果看到这里还不知道怎么用的话那我们来看在我们之前讲的换肤框架中，观察者模式是怎么被用到的。

3.换肤框架Android-skin-support中的观察者设计模式

我们知道，换肤框架中，当我们点击换肤的时候，不仅要加载皮肤包资源，我们还要通知所有的Activity进行换肤这个操作，而且在Acitivity在resume的时候我们就将它添加进观察者集合里面，这就是注册的操作。这是个典型的观察者设计模式。这个框架里面没有写Observable这个接口，而是直接写的ConcreteObservable：

public class SkinObservable {
    private final ArrayList<SkinObserver> observers;

    public SkinObservable() {
        observers = new ArrayList<>();
    }

    public synchronized void addObserver(SkinObserver o) {
        if (o == null)
            throw new NullPointerException();
        if (!observers.contains(o)) {
            observers.add(o);
        }
    }

    public synchronized void deleteObserver(SkinObserver o) {
        observers.remove(o);
    }

    public void notifyUpdateSkin() {
        notifyUpdateSkin(null);
    }

    public void notifyUpdateSkin(Object arg) {
        SkinObserver[] arrLocal;

        synchronized (this) {
            arrLocal = observers.toArray(new SkinObserver[observers.size()]);
        }

        for (int i = arrLocal.length-1; i>=0; i--)
            arrLocal[i].updateSkin(this, arg);
    }

    public synchronized void deleteObservers() {
        observers.clear();
    }

    public synchronized int countObservers() {
        return observers.size();
    }
}

我们看到这跟我们上面说的ConcreteObservable，里面方法都是典型的观察者模式需要实现的方法。然后我们来看有没有Observer这个接口，这里是有的：

public interface SkinObserver {
    void updateSkin(SkinObservable observable, Object o);
}

我们看到这里也是典型的观察者接口，但是具体的观察者在哪里呢？这个框架里面没有直接把Activity实现SkinObserver(其实这么做也是可以),但是这里做了个小变形，用一个Map将Activity跟ConcreteObserver进行关联：

 private WeakHashMap<Activity, SkinObserver> mSkinObserverMap;

然后在Activity resume的时候添加进观察者集合里面：

  @Override
    public void onActivityResumed(Activity activity) {
        if (activity instanceof AppCompatActivity) {
            SkinCompatManager.getInstance().addObserver(getObserver(activity));
        }
    }

添加的时候会先用Activity查找到对应的具体观察者，然后添加进去：

private SkinObserver getObserver(final Activity activity) {
        if (mSkinObserverMap == null) {
            mSkinObserverMap = new WeakHashMap<>();
        }
        SkinObserver observer = mSkinObserverMap.get(activity);
        if (observer == null) {
            observer = new SkinObserver() {
                @Override
                public void updateSkin(SkinObservable observable, Object o) {
                    updateStatusBarColor(activity);
                    updateWindowBackground(activity);
                    getSkinDelegate((AppCompatActivity) activity).applySkin();
                }
            };
        }
        mSkinObserverMap.put(activity, observer);
        return observer;
    }

我们看到这里每次都会查找到activity相对应的具体观察者，然后添加进具体被观察者中的集合里。updateSkin方法里面就是具体的更新皮肤的代码，我们就不深究。如果想看这个源码分析请移步换肤框架实现解析(二)。
设计模式在应用的过程中有可能会出现很多的变形，但是基本的元素都是存在的，只要我们理解了使用的场景，我们才能处于不变应万变的境地。在android系统中的观察者模式其实还有很多，比如EventBus：

EventBus.getDefault().register(Object subscriber);
EventBus.getDefault().unregister(Object subscriber);

EventBus.getDefault().post(Object event);

这也是一种观察者模式的一个使用例子。还有一个非常受欢迎的库rxjava也是有用到类似的观察者模式，具体就不举例了。
总结：观察者模式用到的地方非常广泛，也是我们经常能听见的一种设计模式，如果我们在实际场景中有一对多订阅这种情况的时候，你可以脑海里面浮现一下看这个设计模式是不是正好适用。好啦，希望大家有点收获。