Android:消息处理机制(Handler,Message,Looper)分析

来源:互联网 发布:js object 增加属性 编辑:程序博客网 时间:2024/05/01 17:22

概叙:

  本文主要讲Android系统中消息处理机制,主要从消息循环,消息发送,消息处理三大方面分析。


为什么要用到Handler?它有什么用处,能解决什么问题?

考虑这个问题,举个例子:假设在一个UI界面上面,有一个按钮,当点击这个按钮的时候,会进行网络连接,并把网络上的一个字符串拿下来显示到界面上的一个 TextView上面,这时就出现了一个问题,如果这个网络连接的延迟过大,可能是10秒钟甚至更长,那我们的界面将处于一直假死状态,而如果这段时间超 5秒钟的话,程序会出现异常。这时我们会想到使用线程来完成以上工作,即当按钮被按下的时候新开启一个线程来完成网络连接工作,并把得到的结果更新到UI上面。但是,这时候又会 出现另一个问题,在Android中,主线程是非线程安全的,也就是说UI的更新只能在本线程中完成,其他线程无法直接对主线程进行操作  为了解决以上问题,Android设计了Handler机制,由Handler来负责与子线程进行通讯,从而让子线程与主线程之间建立起协作的桥梁,使AndroidUI更新的问题得到完美的解决。

参与者:

       Handler,MessageLooper

Message类:消息类

  别名:Task

  作用进行信息数据的封装,以及对指定数据的操作形式

  Message类定义的变量和方法如下:

1public int what:变量,用于定义此Message属于何种操作

2public Object obj:变量,用于定义此Message传递的信息数据,通过它传递信息

3public int arg1:变量,传递一些整型数据时使用

4public int arg2:变量,传递一些整型数据时使用

5public Handler getTarget():普通方法,取得操作此消息的Handler对象。 

 在整个消息处理机制中,message又叫task,封装了任务携带的信息和处理该任务的handlermessage的用法比较简单,但是有这么几点需要注意:

1)尽管Messagepublic的默认构造方法,但是你应该通过Message.obtain()来从消息池中获得空消息对象,以节省资源。

2)如果你的message只需要携带简单的int信息,请优先使用Message.arg1Message.arg2来传递信息,这比用Bundle更省内存

3)擅用message.what来标识信息,以便用不同方式处理message


Looper类:消息循环类

在使用Handler处理Message时,需要Looper(通道)来完成。在一个Activity中,系统会自动帮用户启动Looper对象,而在一个用户自定义的类中,则需要用户手工调用Looper类中的方法,然后才可以正常启动Looper对象。Looper的字面意思是“循环者”,它被设计用来使一个普通线程变成Looper线程。所谓Looper线程就是循环工作的线程。在程序开发中(尤其是GUI开发中),我们经常会需要一个线程不断循环,一旦有新任务则执行,执行完继续等待下一个任务,这就是Looper线程。使用Looper类创建Looper线程很简单:

public class LooperThread extends Thread{@Overridepublic void run() {super.run(); // 将当前线程初始化为Looper线程        Looper.prepare();                 // ...其他处理,如实例化handler                 // 开始循环处理消息队列        Looper.loop();}}

通过上面两行核心代码,你的线程就升级为Looper线程了!那么这两行代码都做了些什么呢?


 首先看Looper.prepare()函数的实现,这是一个静态Looper类的成员函数


1)Looper.prepare()


  public class Looper {    // 每个线程中的Looper对象其实是一个ThreadLocal,即线程本地存储(TLS)对象    private static final ThreadLocal sThreadLocal = new ThreadLocal();    // Looper内的消息队列    final MessageQueue mQueue;    // 当前线程    Thread mThread;    //其他属性    // 每个Looper对象中有它的消息队列,和它所属的线程    private Looper() {        mQueue = new MessageQueue();        mRun = true;        mThread = Thread.currentThread();    }    // 我们调用该方法会在调用线程的TLS中创建Looper对象    public static final void prepare() {        if (sThreadLocal.get() != null) {            // 试图在有Looper的线程中再次创建Looper将抛出异常            throw new RuntimeException("Only one Looper may be created per thread");        }        sThreadLocal.set(new Looper());//将looper对象定义为ThreadLocal    }    // 其他方法} 

从上面代码看出:prepare()背后的工作方式一目了然,其核心就是将looper对象定义为ThreadLocal。使一个普通线程变成Looper线程。具体过程:是在线程中创建一个Looper对象,这个Looper对象是存放在sThreadLocal成员变量里面的,成员变量sThreadLocal的类型为ThreadLocal,表示这是一个线程局部变量,即保证每一个调用了prepare()函数的线程里面都有一个独立的Looper对象。在线程是创建Looper对象的工作是由prepare函数来完成的,而在创建Looper对象的时候,会同时创建一个消息队列MessageQueue,保存在Looper的成员变量mQueue中,后续消息就是存放在这个队列中去


MessageQueue:消息队列

public class MessageQueue {......private int mPtr; // used by native codeprivate native void nativeInit();MessageQueue() {nativeInit();}......}

它的初始化工作都交给JNI方法nativeInit来实现了,这个JNI方法定义:

static void android_os_MessageQueue_nativeInit(JNIEnv* env, jobject obj) {    NativeMessageQueue* nativeMessageQueue = new NativeMessageQueue();    if (! nativeMessageQueue) {        jniThrowRuntimeException(env, "Unable to allocate native queue");        return;    }    android_os_MessageQueue_setNativeMessageQueue(env, obj, nativeMessageQueue);}


 在JNI中,也相应地创建了一个消息队列NativeMessageQueue,NativeMessageQueue类

NativeMessageQueue::NativeMessageQueue() {    mLooper = Looper::getForThread();    if (mLooper == NULL) {        mLooper = new Looper(false);        Looper::setForThread(mLooper);    }}


它主要就是在内部创建了一个Looper对象,注意,这个Looper对象是实现在JNI层的,它与上面Java层中的Looper是不一样的,不过它们是对应的,下面我们进一步分析消息循环的过程的时候,读者就会清楚地了解到它们之间的关系。

   这个Looper的创建过程也很重要,不过我们暂时放一放,先分析完android_os_MessageQueue_nativeInit函数的执行,它创建了本地消息队列NativeMessageQueue对象之后,接着调用android_os_MessageQueue_setNativeMessageQueue函数来把这个消息队列对象保存在前面我们在Java层中创建的MessageQueue对象的mPtr成员变量里面:

static void android_os_MessageQueue_setNativeMessageQueue(JNIEnv* env, jobject messageQueueObj,        NativeMessageQueue* nativeMessageQueue) {    env->SetIntField(messageQueueObj, gMessageQueueClassInfo.mPtr,             reinterpret_cast<jint>(nativeMessageQueue));}


这里传进来的参数messageQueueObj即为我们前面在Java层创建的消息队列对象,而gMessageQueueClassInfo.mPtr即表示在Java类MessageQueue中,其成员变量mPtr的偏移量,通过这个偏移量,就可以把这个本地消息队列对象natvieMessageQueue保存在Java层创建的消息队列对象的mPtr成员变量中,这是为了后续我们调用Java层的消息队列对象的其它成员函数进入到JNI层时,能够方便地找回它在JNI层所对应的消息队列对象。 

     我们再回到NativeMessageQueue的构造函数中,看看JNI层的Looper对象的创建过程,即看看它的构造函数是如何实现?

Looper::Looper(bool allowNonCallbacks) :mAllowNonCallbacks(allowNonCallbacks),mResponseIndex(0) {int wakeFds[2];int result = pipe(wakeFds);......mWakeReadPipeFd = wakeFds[0];mWakeWritePipeFd = wakeFds[1];......#ifdef LOOPER_USES_EPOLL// Allocate the epoll instance and register the wake pipe.mEpollFd = epoll_create(EPOLL_SIZE_HINT);......struct epoll_event eventItem;memset(& eventItem, 0, sizeof(epoll_event)); // zero out unused members of data field unioneventItem.events = EPOLLIN;eventItem.data.fd = mWakeReadPipeFd;result = epoll_ctl(mEpollFd, EPOLL_CTL_ADD, mWakeReadPipeFd, & eventItem);......#else......#endif......}

这个构造函数做的事情非常重要,它跟我们后面要介绍的应用程序主线程在消息队列中没有消息时要进入等待状态以及当消息队列有消息时要把应用程序主线程唤醒的这两个知识点息息相关。它主要就是通过pipe系统调用来创建了一个管道了:

int wakeFds[2];int result = pipe(wakeFds);......mWakeReadPipeFd = wakeFds[0];mWakeWritePipeFd = wakeFds[1];

管道是Linux系统中的一种进程间通信机制,具体可以在一本书《Linux内核源代码情景分析》中的第6章--传统的Uinx进程间通信。简单来说,管道就是一个文件,在管道的两端,分别是两个打开文件文件描述符,这两个打开文件描述符都是对应同一个文件,其中一个是用来读的,别一个是用来写的,一般的使用方式就是,一个线程通过读文件描述符中来读管道的内容,当管道没有内容时,这个线程就会进入等待状态,而另外一个线程通过写文件描述符来向管道中写入内容,写入内容的时候,如果另一端正有线程正在等待管道中的内容,那么这个线程就会被唤醒。这个等待和唤醒的操作是如何进行的呢,这就要借助Linux系统中的epoll机制了。 Linux系统中的epoll机制为处理大批量句柄而作了改进的poll,是Linux下多路复用IO接口select/poll的增强版本,它能显著减少程序在大量并发连接中只有少量活跃的情况下的系统CPU利用率。但是这里我们其实只需要监控的IO接口只有mWakeReadPipeFd一个,即前面我们所创建的管道的读端,为什么还需要用到epoll呢?有点用牛刀来杀鸡的味道。其实不然,这个Looper类是非常强大的,它除了监控内部所创建的管道接口之外,还提供了addFd接口供外界面调用,外界可以通过这个接口把自己想要监控的IO事件一并加入到这个Looper对象中去,当所有这些被监控的IO接口上面有事件发生时,就会唤醒相应的线程来处理,不过这里我们只关心刚才所创建的管道的IO事件的发生。

        要使用Linux系统的epoll机制,首先要通过epoll_create来创建一个epoll专用的文件描述符:

mEpollFd = epoll_create(EPOLL_SIZE_HINT);

传入的参数EPOLL_SIZE_HINT是在这个mEpollFd上能监控的最大文件描述符数。

       接着还要通过epoll_ctl函数来告诉epoll要监控相应的文件描述符的什么事件:

struct epoll_event eventItem;memset(& eventItem, 0, sizeof(epoll_event)); // zero out unused members of data field unioneventItem.events = EPOLLIN;eventItem.data.fd = mWakeReadPipeFd;result = epoll_ctl(mEpollFd, EPOLL_CTL_ADD, mWakeReadPipeFd, & eventItem);


这里就是告诉mEpollFd,它要监控mWakeReadPipeFd文件描述符的EPOLLIN事件,即当管道中有内容可读时,就唤醒当前正在等待管道中的内容的线程。
       C++层的这个Looper对象创建好了之后,就返回到JNI层的NativeMessageQueue的构造函数,最后就返回到Java层的消息队列MessageQueue的创建过程,这样,Java层的Looper对象就准备好了。有点复杂,我们先小结一下这一步都做了些什么事情:

       A. 在Java层,创建了一个Looper对象,这个Looper对象是用来进入消息循环的,它的内部有一个消息队列MessageQueue对象mQueue;

       B. 在JNI层,创建了一个NativeMessageQueue对象,这个NativeMessageQueue对象保存在Java层的消息队列对象mQueue的成员变量mPtr中;

       C. 在C++层,创建了一个Looper对象,保存在JNI层的NativeMessageQueue对象的成员变量mLooper中,这个对象的作用是,当Java层的消息队列中没有消息时,就使Android应用程序主线程进入等待状态,而当Java层的消息队列中来了新的消息后,就唤醒Android应用程序的主线程来处理这个消息。


  回到ActivityThread类的main函数中,在上面这些工作都准备好之后,就调用Looper类的loop函数进入到消息循环中去了:


2)Looper.loop()

 public static final void loop() {        Looper me = myLooper();  //得到当前线程Looper        MessageQueue queue = me.mQueue;  //得到当前looper的MQ                 Binder.clearCallingIdentity();        final long ident = Binder.clearCallingIdentity();        // 开始循环        while (true) {            Message msg = queue.next(); // 取出message            if (msg != null) {                if (msg.target == null) {                    // message没有target为结束信号,退出循环                    return;                }                // 日志                if (me.mLogging!= null) me.mLogging.println(                        ">>>>> Dispatching to " + msg.target + " "                        + msg.callback + ": " + msg.what                        );                // 非常重要!将真正的处理工作交给message的target,即后面要讲的handler                msg.target.dispatchMessage(msg);                // 日志                if (me.mLogging!= null) me.mLogging.println(                        "<<<<< Finished to    " + msg.target + " "                        + msg.callback);                                 final long newIdent = Binder.clearCallingIdentity();                if (ident != newIdent) {                    Log.wtf("Looper", "Thread identity changed from 0x"                            + Long.toHexString(ident) + " to 0x"                            + Long.toHexString(newIdent) + " while dispatching to "                            + msg.target.getClass().getName() + " "                            + msg.callback + " what=" + msg.what);                }                // 回收message资源                msg.recycle();            }        }}

 这里就是进入到消息循环中去了,它不断地从消息队列mQueue中去获取下一个要处理的消息msg,如果消息的target成员变量为null,就表示要退出消息循环了,否则的话就要调用这个target对象的dispatchMessage成员函数来处理这个消息,这个target对象的类型为Handler,下面我们分析消息的发送时会看到这个消息对象msg是如设置的。


除了prepare()和loop()方法,Looper类还提供了一些有用的方法,比如Looper.myLooper()得到当前线程looper对象:

    public static final Looper myLooper() {        // 在任意线程调用Looper.myLooper()返回的都是那个线程的looper        return (Looper)sThreadLocal.get();    } 

  getThread()得到looper对象所属线程:


 public Thread getThread() {        return mThread; }

  quit()方法结束looper循环:

    public void quit() {        // 创建一个空的message,它的target为NULL,表示结束循环消息        Message msg = Message.obtain();        // 发出消息        mQueue.enqueueMessage(msg, 0);    }



综上,Looper有以下几个要点:

1)每个线程有且只能有一个Looper对象,它是一个ThreadLocal

2)Looper内部有一个消息队列,loop()方法调用后线程开始不断从队列中取出消息执行

3)Looper使一个线程变成Looper线程。

消息发送:

public class Handler {......public final boolean sendMessage(Message msg){return sendMessageDelayed(msg, 0);}public final boolean sendMessageDelayed(Message msg, long delayMillis){if (delayMillis < 0) {delayMillis = 0;}return sendMessageAtTime(msg, SystemClock.uptimeMillis() + delayMillis);}public boolean sendMessageAtTime(Message msg, long uptimeMillis){boolean sent = false;MessageQueue queue = mQueue;if (queue != null) {msg.target = this;sent = queue.enqueueMessage(msg, uptimeMillis);}else {......}return sent;}......}

在发送消息时,是可以指定消息的处理时间的,但是通过sendMessage函数发送的消息的处理时间默认就为当前时间,即表示要马上处理,因此,从sendMessage函数中调用sendMessageDelayed函数,传入的时间参数为0,表示这个消息不要延时处理,而在sendMessageDelayed函数中,则会先获得当前时间,然后加上消息要延时处理的时间,即得到这个处理这个消息的绝对时间,然后调用sendMessageAtTime函数来把消息加入到应用程序的消息队列中去。

        在sendMessageAtTime函数,首先得到应用程序的消息队列mQueue,这是在Handler对象构造时初始化好的,前面已经分析过了,接着设置这个消息的目标对象target,即这个消息最终是由谁来处理的

msg.target = this;

 这里将它赋值为this,即表示这个消息最终由这个Handler对象来处理,即由ActivityThread对象的mH成员变量来处理。

        函数最后调用queue.enqueueMessage来把这个消息加入到应用程序的消息队列中去

public class MessageQueue {......final boolean enqueueMessage(Message msg, long when) {......final boolean needWake;synchronized (this) {......msg.when = when;//Log.d("MessageQueue", "Enqueing: " + msg);Message p = mMessages;if (p == null || when == 0 || when < p.when) {msg.next = p;mMessages = msg;needWake = mBlocked; // new head, might need to wake up} else {Message prev = null;while (p != null && p.when <= when) {prev = p;p = p.next;}msg.next = prev.next;prev.next = msg;needWake = false; // still waiting on head, no need to wake up}}if (needWake) {nativeWake(mPtr);}return true;}......}

把消息加入到消息队列时,分两种情况,一种当前消息队列为空时,这时候应用程序的主线程一般就是处于空闲等待状态了,这时候就要唤醒它,另一种情况是应用程序的消息队列不为空,这时候就不需要唤醒应用程序的主线程了,因为这时候它一定是在忙着处于消息队列中的消息,因此不会处于空闲等待的状态。

        第一种情况比较简单,只要把消息放在消息队列头就可以了:

msg.next = p;mMessages = msg;needWake = mBlocked; // new head, might need to wake up

把消息加入到消息队列去后,如果应用程序的主线程正处于空闲等待状态,就需要调用natvieWake函数来唤醒它了,这是一个JNI方法

static void android_os_MessageQueue_nativeWake(JNIEnv* env, jobject obj, jint ptr) {    NativeMessageQueue* nativeMessageQueue = reinterpret_cast<NativeMessageQueue*>(ptr);    return nativeMessageQueue->wake();}

这个JNI层的NativeMessageQueue对象我们在前面分析消息循环的时候创建好的,保存在Java层的MessageQueue对象的mPtr成员变量中,这里把它取回来之后,就调用它的wake函数来唤醒应用程序的主线程

void NativeMessageQueue::wake() {    mLooper->wake();}

void NativeMessageQueue::wake() {    mLooper->wake();}
 这里它又通过成员变量mLooper的wake函数来执行操作,这里的mLooper成员变量是一个C++层实现的Looper对象

void Looper::wake() {......ssize_t nWrite;do {nWrite = write(mWakeWritePipeFd, "W", 1);} while (nWrite == -1 && errno == EINTR);.......}

这个wake函数很简单,只是通过打开文件描述符mWakeWritePipeFd往管道的写入一个"W"字符串。其实,往管道写入什么内容并不重要,往管道写入内容的目的是为了唤醒应用程序的主线程。前面我们在分析应用程序的消息循环时说到,当应用程序的消息队列中没有消息处理时,应用程序的主线程就会进入空闲等待状态,而这个空闲等待状态就是通过调用这个Looper类的pollInner函数来进入的,具体就是在pollInner函数中调用epoll_wait函数来等待管道中有内容可读的。

        这时候既然管道中有内容可读了,应用程序的主线程就会从这里的Looper类的pollInner函数返回到JNI层的nativePollOnce函数,最后返回到Java层中的MessageQueue.next函数中去,这里它就会发现消息队列中有新的消息需要处理了,于就会处理这个消息。

消息处理:

前面在分析消息循环时,说到应用程序的主线程是在Looper类的loop成员函数中进行消息循环过程的

public class Looper {......public static final void loop() {Looper me = myLooper();MessageQueue queue = me.mQueue;......while (true) {Message msg = queue.next(); // might block......if (msg != null) {if (msg.target == null) {// No target is a magic identifier for the quit message.return;}......msg.target.dispatchMessage(msg);......msg.recycle();}}}......}

 它从消息队列中获得消息对象msg后,就会调用它的target成员变量的dispatchMessage函数来处理这个消息。在前面分析消息的发送时说过,这个消息对象msg的成员变量target是在发送消息的时候设置好的,一般就通过哪个Handler来发送消息,就通过哪个Handler来处理消息。

public class Handler {......public void dispatchMessage(Message msg) {if (msg.callback != null) {handleCallback(msg);} else {if (mCallback != null) {if (mCallback.handleMessage(msg)) {return;}}handleMessage(msg);}}......}

总结:

    从消息循环、消息发送和消息处理三个部分分析完Android应用程序的消息处理机制了,为了更深理解,这里我们对其中的一些要点作一个总结:

         A. Android应用程序的消息处理机制由消息循环、消息发送和消息处理三个部分组成的。

         B. Android应用程序的主线程在进入消息循环过程前,会在内部创建一个Linux管道(Pipe),这个管道的作用是使得Android应用程序主线程在消息队列为空时可以进入空闲等待状态,并且使得当应用程序的消息队列有消息需要处理时唤醒应用程序的主线程。

         C. Android应用程序的主线程进入空闲等待状态的方式实际上就是在管道的读端等待管道中有新的内容可读,具体来说就是是通过Linux系统的Epoll机制中的epoll_wait函数进行的。

         D. 当往Android应用程序的消息队列中加入新的消息时,会同时往管道中的写端写入内容,通过这种方式就可以唤醒正在等待消息到来的应用程序主线程。

         E. 当应用程序主线程在进入空闲等待前,会认为当前线程处理空闲状态,于是就会调用那些已经注册了的IdleHandler接口,使得应用程序有机会在空闲的时候处理一些事情。

        F.主线程启动时会调用Looper.prepare()方法,会初始化一个Looper,放入Threadlocal中,接着调用Looper.loop()不断遍历Message Queue,

Handler的创建依赖与当前线程中的Looper,如果当前线程没有Looper则必须调用Looper.prepare()。Handler , sendMessage到MessageQueue,Looper不断

从MessageQueue中取出消息,回调handleMessage方法

参考文章:

http://blog.csdn.net/luoshengyang/article/details/6817933/

http://my.oschina.net/u/1391648/blog/282892

http://blog.csdn.net/itachi85/article/details/8035333


















0 0
原创粉丝点击