当前位置:  编程技术>综合

[1]java设计模式-观察者模式初探

1、什么是观察者模式？
观察者模式定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对象。这个主题对象在状态发生变化时，会通知所有观察者对象，让他们自动更新自己。

举个例子：在java GUI程序中，一个按钮有多个监听器，当这个按钮被点击时，即上面所说的主题对象状态发生变化，多个监听器自动得到调用。

2、观察者模式的组成：可以概括为两个抽象和两个具体。
- 抽象主题(Subject)角色：把所有对观察者对象的引用保存在一个集合中，每个抽象主题角色都可以有任意数量的观察者。抽象主题提供一个接口，可以增加和删除观察者角色。一般用一个抽象类或接口来实现。
- 抽象观察者(Observer)角色：为所有具体的观察者定义一个接口，在得到主题的通知时更新自己。
- 具体主题角(ConcreteSubject)色：在具体主题角色内部状态改变时，给所有登记过的观察者发出通知。具体主题角色通常由一个子类来实现。
- 具体观察者(ConcreteObserver)角色：该角色实现抽象观察者角色所要求的更新接口，以便使本身的状态与主题的状态相协调。如果需要，具体观察者角色可以保存一个指向具体主题角色的引用。通常用一个子类来实现。

上面说的还是很抽象，还是用代码来说话吧！

代码如下：
//抽象主题角色：

//抽象主题角色
public interface Subject
{
	//注册观察者对象
	public void addWatcher(Observer watcher);
	
	//删除观察者对象
	public void removeWatcher(Observer watcher);
	
	//通知所有的观察者对象
	public void notifyWatchers(String str);
}

//具体主题角色：

//具体主题角色
public class ConcreteSubject implements Subject
{
	//把所有对观察者对象的引用保存在一个集合中
	private List<Observer> list = new ArrayList<Observer>();
	
	@Override
	public void addWatcher(Observer watcher)
	{
		list.add(watcher);
	}

	@Override
	public void removeWatcher(Observer watcher)
	{
		list.remove(watcher);
	}

	@Override
	public void notifyWatchers(String str)
	{
		for(Observer watcher : list)
		{
			watcher.update(str);
		}
	}	
}

//抽象观察者角色：

//抽象观察者角色
public interface Observer
{
	public void update(String str);
}

//具体观察者对象：

//具体观察者对象
public class ConcreteObserver implements Observer
{
	@Override
	public void update(String str)
	{
		System.out.println(str);
	}
}

//测试类：

public class TestObserver
{
	public static void main(String[] args)
	{
		//相当于GUI中一个按钮
		Subject watched = new ConcreteSubject();
		
		//相当于按钮的事件监听器
		Observer watcher1 = new ConcreteObserver();
		Observer watcher2 = new ConcreteObserver();
		Observer watcher3 = new ConcreteObserver();
		
		//将监听器注册到主题角色中
		watched.addWatcher(watcher1);
		watched.addWatcher(watcher2);
		watched.addWatcher(watcher3);
		
		//在单击按钮后，触发了事件
		watched.notifyWatchers("hello");
		System.out.println("-----------");
		
		watched.removeWatcher(watcher1);
		watched.notifyWatchers("world");
	}
}

3、总结：java在GUI编程中大量使用了观察者模式，在jdk中也提供了对观察者模式的支持，它们在java.util包中的Obserable类和Observer接口，其中的实现思路与上面的代码大体相同，所以在理解了上面简单代码的基础上，再去研究jdk对观察者模式所提供的源码就不是什么难事了。

已有 0 人发表留言，猛击->>这里<<-参与讨论


ITeye推荐

• —软件人才免语言低担保 赴美带薪读研！—

[2]MANIFEST.MF格式总结

[3]Android 4.2 Wifi Display核心分析 （一）

作者： Wolf Geek     转载请说明出处

        上一回，主要介绍了有关WifiDisplay设备连接和建立数据流的流程，这一回将接着向底层前进。由于涉及的内容较多，这里仅仅理清一个大概的头绪，细节的部分将不再展开，如果有什么错误的地方我会及时更正。

       当Source端通过RemoteDisplay.cpp的构造函数注册了Wifidisplay处理线程，并且ANetworkSession初始化了通信所用的数据管道并且开始监听数据流变化后，Source端将通过函数mSource->start(iface)开始建立RTSP连接并且向Sink端传递数据流。接下来，将具体分析其流程。mSource->start(iface)的具体实现在以下文件，

 frameworks/av/media/libstagefright/wifi-display/source/WifiDisplaySource.cpp

status_t WifiDisplaySource::start(const char *iface) {
    CHECK_EQ(mState, INITIALIZED);

    sp<AMessage> msg = new AMessage(kWhatStart, id());
    msg->setString("iface", iface);

    sp<AMessage> response;
    status_t err = msg->postAndAwaitResponse(&response);

    if (err != OK) {
        return err;
    }

    if (!response->findInt32("err", &err)) {
        err = OK;
    }

    return err;
}

该函数首先通过CHECK_EQ来判断当前Source端状态是否为 INITIALIZED，如果是将通过 AMessage创建 标识为kWhatStart的消息，用于在onMessageReceived处理分支中进行匹配，msg->setString(“iface”,iface)用于在传递消息过程中携带网络地址端口信息， msg->postAndAwaitResponse用于返回相应结果。这种方式在Android的流媒体类中相当常见，是一种异步消息处理框架。与该框架相关的类主要有ALooper、AHandler、ALooperRoster等，具体请见。

接下来，我们来看看当Source端接收到kWhatStart的消息后做何种处理，

void WifiDisplaySource::onMessageReceived(const sp<AMessage> &msg) {
    switch (msg->what()) {
        case kWhatStart:
        {
            uint32_t replyID;
            CHECK(msg->senderAwaitsResponse(&replyID));

            AString iface;
            CHECK(msg->findString("iface", &iface));

            status_t err = OK;

            ssize_t colonPos = iface.find(":");  //寻找“:”所在位置

            unsigned long port;

            if (colonPos >= 0) {
                const char *s = iface.c_str() + colonPos + 1;

                char *end;
                port = strtoul(s, &end, 10);  //得到port号

                if (end == s || *end != '\0' || port > 65535) {
                    err = -EINVAL;
                } else {
                    iface.erase(colonPos, iface.size() - colonPos);  
                }
            } else {
                port = kWifiDisplayDefaultPort;
            }

            if (err == OK) {
                if (inet_aton(iface.c_str(), &mInterfaceAddr) != 0) {  //将IP地址转化为32位的网络序列IP地址
                    sp<AMessage> notify = new AMessage(kWhatRTSPNotify, id());//建立标识为 kWhatRTSPNotify的消息作为参数传递

                    err = mNetSession->createRTSPServer(
                            mInterfaceAddr, port, notify, &mSessionID);
                } else {
                    err = -EINVAL;
                }
            }

            if (err == OK) {
                mState = AWAITING_CLIENT_CONNECTION;
            }

            sp<AMessage> response = new AMessage;
            response->setInt32("err", err);
            response->postReply(replyID);
            break;
        }
      ...
   }
}

首先，可以看到当Source端接收到消息标识为 kWhatStart的消息后，消息指针msg会通过函数msg->senderAwaitsResponse(&replyID)获取对应于postAndAwaitResponse函数的响应标识，并把处理中的错误信息作为消息载体通过response->postReply(replyID)传递回start(iface)函数。然后，该处理函数将接收到的网络地址端口信息iface拆分为IP地址和端口两个部分,并且利用 createRTSPServer创建RTSP服务端，函数会返回相应的Session编号。如果RTSP服务端创建成功，则将Source端状态更改为 AWAITING_CLIENT_CONNECTION，表示等待客户端连接。

 接着看创建RTSP服务端具体做了哪些动作，

frameworks/av/media/libstagefright/wifi-display/ANetworkSession.cpp

status_t ANetworkSession::createRTSPServer(
        const struct in_addr &addr, unsigned port,
        const sp<AMessage> ¬ify, int32_t *sessionID) {
    return createClientOrServer(
            kModeCreateRTSPServer,
            &addr,
            port,
            NULL /* remoteHost */,
            0 /* remotePort */,
            notify,
            sessionID);
}

可以看到函数createRTSPServer具体又调用了 createClientOrServer函数。在此类中，与建立管道数据流相关的函数都会调用该函数，它们分别是createRTSPClient、createRTSPServer、createUDPSession、createTCPDatagramSession等函数。

其中可以不用关注函数createTCPDatagramSession，这是因为Sink端默认选择了UDP方式进行传输。具体起关键性作用的是在WifiDisplaySink.h头文件中的static const bool sUseTCPInterleaving = false变量 ，具体而言，该变量为false就导致Sink端不会向Source端发送“Transport: RTP/AVP/TCP”这样的请求，这样在Source端就不会将Sender类中的mTransportMode变量设置为TRANSPORT_TCP或者 TRANSPORT_TCP_INTERLEAVED，所以在Sender类中最终并不会调用函数createTCPDatagramSession。        

接下来，将重点看看函数createClientOrServer，其中与建立RTSP服务端无关的步骤先省略不看。

status_t ANetworkSession::createClientOrServer(
        Mode mode,
        const struct in_addr *localAddr,
        unsigned port,
        const char *remoteHost,
        unsigned remotePort,
        const sp<AMessage> ¬ify,
        int32_t *sessionID) {
    Mutex::Autolock autoLock(mLock);

    *sessionID = 0;
    status_t err = OK;
    int s, res;
    sp<Session> session;

    s = socket(
            AF_INET,
            (mode == kModeCreateUDPSession) ? SOCK_DGRAM : SOCK_STREAM,
            0);    //建立类型为流套接字的socket

  ...

    if (mode == kModeCreateRTSPServer
            || mode == kModeCreateTCPDatagramSessionPassive) {
        const int yes = 1;
        res = setsockopt(s, SOL_SOCKET, SO_REUSEADDR, &yes, sizeof(yes));//允许socket和一个已在使用中的地址捆绑
    err = MakeSocketNonBlocking(s);  //设置socket为非阻塞方式

    struct sockaddr_in addr;
    memset(addr.sin_zero, 0, sizeof(addr.sin_zero));
    addr.sin_family = AF_INET;

    if (mode == kModeCreateRTSPClient
            || mode == kModeCreateTCPDatagramSessionActive) {
     ...
    } else if (localAddr != NULL) {
        addr.sin_addr = *localAddr;
        addr.sin_port = htons(port);
    } else {
        ...
    }

    if (mode == kModeCreateRTSPClient
            || mode == kModeCreateTCPDatagramSessionActive) {
       ...
       
    } else {
        res = bind(s, (const struct sockaddr *)&addr, sizeof(addr));//socket与
sockaddr结构体指针绑定，sockaddr对应与iface
        if (res == 0) {  //绑定成功
            if (mode == kModeCreateRTSPServer
                    || mode == kModeCreateTCPDatagramSessionPassive) {
                res = listen(s, 4);  //作为服务端开始监听rtsp连接请求
            } else {
                  ...
                }
            }
        }
    }
     ...
    Session::State state;
    switch (mode) {
        ...

        case kModeCreateRTSPServer:
            state = Session::LISTENING_RTSP;   //设置Session状态为 LISTENING_RTSP
            break;
       ...
    }

    session = new Session(
            mNextSessionID++,
            state,
            s,
            notify);    //创建一个session对象,sessionID加1

    ...
    mSessions.add(session->sessionID(), session); //将该对象加入vector结构中保存

    interrupt();  //向管道写端写数据

    *sessionID = session->sessionID();  //由指针带出当前sessionID

    goto bail;
...

bail:
    return err;
}

可以看到建立RTSP服务端的步骤没什么特别的地方，无非是建立socket,绑定地址然后监听等步骤，只不过为了标识不同的请求和区分当前状态，这里用Session结构体和相应的状态来管理对应的socket。

回到RemoteDisplay.cpp的构造函数中，可以看到在Source端调用函数mSource->start(iface)之前就通过mNetSession->start()开启了ANetworkSession线程，接下来看一下mNetSession->start()究竟干了什么事。

status_t ANetworkSession::start(){
   ...
   int res =pipe(mPipeFd);  //建立读写管道，控制threadLoop的执行
   if (res != 0) {
        mPipeFd[0] = mPipeFd[1] = -1;
        return -errno;            
   }
   mThread = new NetworkThread(this); //构造ANetworkSession的内部结构线程
   status_t err = mThread->run("ANetworkSession", ANDROID_PRIORITY_AUDIO);//开启该线程，将会调用NetworkThread线程中threadLoop，进一步会调用AnetworkSession::threadLoop()
   ...
   return OK;
}

   可以看到 ANetworkSession采用了管道的方式来控制