http://blog.csdn.net/code__man/article/details/79108191
Android消息机制
这一定是一个被写烂了的专题吧。那本媛也来凑一个热闹吧。哈哈
这篇博客将会涉及以下内容:
- 消息机制概述
- UML图解消息机制相关类
- 从在主线程更新UI的方法带你畅游消息机制的源码,更加方便自己理解
- Handler
- Looper
- MessageQueue和Message
- 消息机制的应用
消息机制概述
Android系统在设计的初期就已经考虑到了UI的更新问题,由于Android中的View是线程不安全的,然而程序中异步处理任务结束后更新UI元素也是必须的。这就造成了一个矛盾,最简单的解决方法肯定是给View加同步锁使其变成线程安全的。这样做不是不可以,只是会有两点坏处:
- 加锁会有导致效率底下
- 由于可以在多个地方更新UI,开发就必须很小心操作,开发起来就很麻烦,一不小心就出错了。
基于以上两个缺点,这种方式被抛弃。于是机智如我谷歌爸爸。。。设置一个线程专门处理UI控件的更新,如果其他线程也需要对UI进行更新,不好意思,您把您想做的告诉那个专门处理UI线程的家伙,让它帮你做。大家各有各的任务,井水不犯河水,各司其职,效率才会高,不仅仅对于软件如此,人也是如此,我只管写我的代码,有农民伯伯帮我种吃的、有电脑公司卖给我电脑、有建筑公司给我盖房子(当然了,房子我是万万买不起的… 哼!),这些事儿好像自己也能干,但是都自己干好像就回到了远古时代,人类的进步和发展和社会分工的明确也是离不开的,而且关系很大!
好像扯的有点远了。
那么您也看出来了,消息机制其实可以很简单的用一句话概括,就是:其他线程通过给特定线程发送消息,将某项专职的工作,交给这个特定的线程去做。比如说其他线程都把处理UI显示的工作通过发送消息交给UI线程去做。
实现的原理呢,我是这么理解的,现在要做的主要工作就是切换线程去操作,怎么切换呢?把两条线程看作是两条并行的公路,如果要从一条公路转到另一条公路上,要怎么做呢?是不是只要找到两条公路交叉或者共用某个资源的地方,如果说交叉路口,比如说加油站。当然了,线程是不存在交叉的地方的,那么可以考虑他们公用资源的地方,不同的进程享用不同的内存空间,但是同一个进程的不同线程享用的是同一片内存空间,那让其他线程把要处理的消息放到这个特定的内存空间上,处理消息的线程来这个内存空间上来取消息去处理不就可以了吗。事实正是如此,在Android的消息机制中,扮演这个特定内存空间的对象就是MessageQueue对象,发送和处理的消息就是Message对象。其他的Handler和Looper都是为了配合线程切换用的。
其实不仅仅是线程之间,不同进程之间进行消息传递(IPC机制),也是这个思路,找到公用的一个资源点,文件系统啊,共享内存啊等等,这个以后再讲吧。
这样理解起来是不是就是so easy了呢?
UML图解消息机制相关类
不知道上面的说法您是否可以对消息机制有了一个基本的认知呢?我曾经在想,怎么通过很简洁直观的方式去把消息机制讲明白(讲给自己,也讲给你)呢,后来我就在想,当初设计者的思路是什么样的呢?我想到了UML图,用类图来对消息机制中涉及到的几个类有一个概括的认识;通过时序图,可以很清晰的观察到整个消息机制的处理过程。
消息主要设计到下面几个类:
- Handler:这是消息的发出的地方,也是消息处理的地方。
- Looper:这是检测消息的地方。
- MessageQueue:这是存放消息的地方,Handler把消息发到了这里,Looper从这里取出消息交给Handler进行处理
- Message:呜呜呜…他们发的是我,处理的也是我。
- Thread:我在这里专门指代的是,处理消息的线程。消息的发送是在别的线程。
话不多说,先来看一张图(UML忘的差不多了,刚补的,如果有错误,麻烦大家指出)
畅游源码
图在这里了,怎么看呢,整个消息机制相关的类密密麻麻支撑了一张网,咋个看嘛,,,不急不急,咱们先来思考一下咱们常用的更新UI是怎么一个操作步骤。
- 在主线程新建一个Handler对象,在构造方法中传入一个实现Handler.Callback接口的匿名类的对象,实现接口中的handleMessage方法
- 在非UI线程使用Handler的sendMessage或者post方法发送一个消息
- 然后handleMessage方法会在不久的将来马上执行,实现更新UI的操作。
那咱们就跟着这个思路来看一看这张图,先看Handler类,你会发现,Handler真的是个相当关键的核心(当然,其他部分也是不可或缺的),他几乎拥有所有其他相关对象的引用。
- Handler拥有Looper的引用,通过得到Looper对象获得Looper中保存的MessageQueue对象
- Handler拥有MessageQueue的引用,使Handler得以拥有发送消息(将Message放入MessageQueue)的能力
- Handler拥有Handler.Callback的引用,使得Handler可以方便的进行消息的处理。
来思考一个问题:为什么Handler在其他线程发送消息之后,就跑到了主线程的handleMessage方法中去更新UI?
这个问题暂时先放着,等下回过头再来看。
我们现在先跟着第1,2,3步看看系统都帮我们做了什么操作呢?这就是在看源码,不要觉得很高深
下面是鲜活的代码,为了方便您查看,我帮您摘出来了。如果有兴趣,您也可以在AS里点开看看
//这是在主线程中
Handler handler = new Handler(new Handler.Callback() {
@Override
public boolean handleMessage(Message msg) {
switch (msg.what) {
case 1:
Toast.makeText(mContext, "你真漂亮", Toast.LENGTH_SHORT).show();
break;
case 2:
Toast.makeText(mContext, "你也很帅呢", Toast.LENGTH_SHORT).show();
break;
default:
break;
}
return false;
}
});
//这是我们在主线程中创建Handler时会使用的构造方法
public Handler(Callback callback) {
this(callback, false);//调用了下面的这个构造方法↓
}
//先不要管第二个参数。跟紧主线,别跟丢了
public Handler(Callback callback, boolean async) {
if (FIND_POTENTIAL_LEAKS) {
final Class<? extends Handler> klass = getClass();
if ((klass.isAnonymousClass() || klass.isMemberClass() || klass.isLocalClass()) &&
(klass.getModifiers() & Modifier.STATIC) == 0) {
Log.w(TAG, "The following Handler class should be static or leaks might occur: " +
klass.getCanonicalName());
}
}
//在这里获取到Looper对象,怎么获取的,稍后再看
mLooper = Looper.myLooper();
//如果获取的mLooper为空,直接抛出异常,说你不能在一个没有调用Looper.prepare()方法
//的线程里创建Handler
//如此看来,Looper.prepare()方法重要的嘞
if (mLooper == null) {
throw new RuntimeException(
"Can't create handler inside thread that has not called Looper.prepare()");
}
//通过mLooper对象获取MessageQueue这个消息队列(单链表)
mQueue = mLooper.mQueue;
mCallback = callback;
mAsynchronous = async;
}
到此为止,一个Handler就创建好了,(还有一个问题是Looper.prepare方法很重要,但是我们还没有去考虑他是干嘛的,不急不急,先顺着一条线看,不然看源代码的过程会把你搞死翘翘的)先面就该进行第二步,看看Handler.sendMessage干了啥.代码段又来喽
//在一个新建的线程里使用创建好的Handler发送一个消息
new Thread(new Runnable() {
@Override
public void run() {
//在这儿干点你想干的吧,一些耗时的计算或者网络操作啥的
Message message = new Message();
message.what = 1;
handler.sendMessage(message);
}
}).start();
//直接调用的是这个函数
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) {
MessageQueue queue = mQueue;
if (queue == null) {
RuntimeException e = new RuntimeException(
this + " sendMessageAtTime() called with no mQueue");
Log.w("Looper", e.getMessage(), e);
return false;
}
return enqueueMessage(queue, msg, uptimeMillis);
}
//最后的最后来到了这里
private boolean enqueueMessage(MessageQueue queue, Message msg, long uptimeMillis) {
//target就是Message绑定的Handler,看看类图,上面有这个细节
msg.target = this;
if (mAsynchronous) {
msg.setAsynchronous(true);
}
//最后的最后,调用了MessageQueue的enqueueMessage方法
return queue.enqueueMessage(msg, uptimeMillis);
}
//再看一下MessageQueue的enqueueMessage方法,
//我把其他一些无关的细节给删掉了,只为了更加容易阅读
boolean enqueueMessage(Message msg, long when) {
synchronized (this) {
Message p = mMessages;
if (p == null) {
// New head, wake up the event queue if blocked.
msg.next = p;
mMessages = msg;
} else {
//下面的错误就是遍历单链表,找到链表的尾部,这个没有难度的吧?
Message prev;
for (;;) {
prev = p;
p = p.next;
if (p == null || when < p.when) {
//找到了尾部,现在的结构是这样的。
//A->B->C...->pre(p)->null
break;
}
}
msg.next = p; // invariant: p == prev.next
prev.next = msg;//把next插入链表的尾部
}
}
return true;
}
到此为止,第二步就结束了,成功把一个消息插入到了MessageQueue的尾部。可是你很快就会发现,第三步好像从这条路探寻不下去了。接下来就等着别人来调用Handler中的方法了,可是是谁调用的,在哪儿调用的?我们现在好像毫无头绪了?怎么办?怎么办?我们刚才不是看到一个Looper.myLooper(),和Looper.prepare()方法,说是很重要但是一直没看吗,既然现在搜寻不下去了,是不是可以回头看看了?还有一点,Looper,看起来是在循环,循环什么玩意儿呢?我们去好好看看Looper类吧。
一共就三百来行代码,仔细看看,你会发现有一个核心方法:Looper.loop();
同样的,我把影响阅读的非主线代码剔除了,发现Looper.loop方法就长这样:
/**
* Run the message queue in this thread. Be sure to call
* {@link #quit()} to end the loop.
*/
public static void loop() {
final Looper me = myLooper();
if (me == null) {
throw new RuntimeException("No Looper; Looper.prepare() wasn't called on this thread.");
}
final MessageQueue queue = me.mQueue;
for (;;) {
Message msg = queue.next(); // might block
if (msg == null) {
// No message indicates that the message queue is quitting.
return;
}
try {
msg.target.dispatchMessage(msg);
} finally {
}
}
}
- 清晰可见的是,Looper.loop()方法一直遍历MessqgeQueue,阻塞线程,直到获取到一个Message,然后调用了Message的一个成员变量target(其实就是Handler)的dispatchMessage(msg)方法,嗨,还真的又跟Handler扯上关系了,既然这里扯上关系了,而且还是一个分发消息的方法,可以大胆猜测就是让Handler去处理这个消息的。
那么我们来看看这个方法:
/**
* Handle system messages here.
* 如果Message中callback对象不为空(这是调用handler.post(Runnable)方法发送的消息),
* 就调用callback的run方法
* 否则如果创建Handler的时候如果设置了Callback就调用创建时候的传入的
* 实现Handler.Callback接口的类的对象的handleMessage方法,看这就是回调方法被调用的地方。
* 再如果没有mCallback对象,就调用自身的handleMessage方法,为了Handler的子类复写了该方法的时候,方便调用,如,IntentService里的ServiceHandler就是继承自Handler的,并且重写了handleMessage方法。
*/
public void dispatchMessage(Message msg) {
if (msg.callback != null) {
handleCallback(msg);
} else {
if (mCallback != null) {
if (mCallback.handleMessage(msg)) {
return;
}
}
handleMessage(msg);
}
}
private static void handleCallback(Message message) {
message.callback.run();
}
//ServiceHandler继承自Service并且重写了handleMessage方法
private final class ServiceHandler extends Handler {
public ServiceHandler(Looper looper) {
super(looper);
}
@Override
public void handleMessage(Message msg) {
onHandleIntent((Intent)msg.obj);
stopSelf(msg.arg1);
}
}
到了这里,三步走已经看完了,我想消息机制在我们心里已经又清晰了一层,但是不用急,咱们前边提的一个问题不是还没有解决吗,先把他解决掉吧,一起继续来看源码。
咱们现在已知的是这样的,在主线程创建的Handler发送了一个消息,发送消息的代码运行在其他线程,将代码加入消息队列也是在其他线程(加了线程同步锁)。然后handleMessage发生在主线程,那么调用该方法的dispatchMessage方法也是运行在主线程的,dispatchMessage是在Looper.loop方法中调用的,也就是说loop方法也运行在主线程,那么问题就明朗了,可是loop方法是谁调用的,在哪里调用的呢?当然是系统启动的时候创建主线程之后再主线程的run方法中调用了Looper.prepare和Looper.loop方法,但是这点我还没看,留着以后再看吧。
然后通过上面的分析,我们是不是可以自己来试着建立这样一个模型:
- 创建一个线程A
- 在这个线程的run方法中调用Looper.prepare和Looper.loop方法使该线程阻塞,等待消息发过来,然后处理
- 在该线程中创建一个Hanlder,用来处理looper发送来的待处理的消息
- 创建一些其他的线程a、b、c,做一点操作之后,通过Handler把消息传递出去,让线程A去处理。
public class MyThread extends Thread {
private static final String TAG = "MyThread";
Handler handler = new Handler(new Handler.Callback() {
@Override
public boolean handleMessage(Message msg) {
switch (msg.what) {
case 1:
Log.i(TAG,"你真漂亮");
break;
case 2:
Log.i(TAG,"你也很帅呢");
break;
default:
break;
}
return false;
}
});
public Handler getHandler() {
return handler;
}
@Override
public void run() {
super.run();
Looper.prepare();
Looper.loop();
}
@Override
public void destroy() {
super.destroy();
Looper.myLooper().quit();
}
}
//
private void testMyThread() {
MyThread thread = new MyThread();
thread.start();
final Handler handler = thread.getHandler();
Message message = new Message();
message.what = 1;
handler.sendMessage(message);
new Thread(new Runnable() {
@Override
public void run() {
try {
sleep(400);
Message message = new Message();
message.what = 2;
handler.sendMessage(message);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}).start();
}
试着想一想,如果把线程A看成主线程,在回调方法更新UI,那这不就是Android系统中更新UI使用的套路吗?不错,事实本就如此,工具是工具,用它来更新UI是可以的,那你当然也可以用来做一些其他的工作啊。
在这里,通过以上的分析,不难得到下面的这个整个消息机制运行过程的时序图:
ok啦,源码阅读到此为止。其他的细节,有兴趣的可以再细细研究一下。
下面我们来对涉及到的类进行一下总结。
先来说一下我的个人理解,
Handler
handler在消息机制中,扮演的是消息的发送方和处理方(通过回调函数)。消息在一个线程通过Handler发送到MessageQueue中。Looper获取到Message之后,根据Message中保存的handler对象调用handler对象的dispatch方法,进行消息的处理。
Looper
Looper在这里扮演的是一个轮询消息队列的角色,以为不停地去问MessageQueue要消息,得到消息之后,根据Message中保存的handler对象调用handler对象的dispatch方法,进行消息的处理。
MessageQueue和Message
MessageQueue实质上是一个单链表的结构,里面以链表的形式保存着Handler发送过来的消息,当有新消息发来时放在链表的尾部,Looper要取消息的时候从链表的头部取出消息返回给Looper处理。Message对象中保存在要处理的信息,同时也持有消息发送方(Handler)的引用,Looper在得到该Message的时候,可以从Message中拿到消息的发送方,调用发送方的回调方法将消息传递过去交给Handler进行处理。
消息机制的应用
在Android中有很多消息机制的应用,如:
- UI的更新
- HandlerThread
- IntentService
UI的更新
UI线程持有一个Looper对象,Looper对象的loop方法在UI线程中一直不停的进行死循环,直到有新的消息发来的时候,交给特定的组件进行处理,当然了这个处理也是在主线程运行的(如我们设置的点击事件也是等着被UI线程调用的),正是由于这个原因,我们不能在主线程处理耗时操作。如果我们一个View的点击事件里做了大量耗时的操作,由于这个操作也在主线程中运行,主线程必须等着这个操作操作结束才能去处理其他的消息,这个时候表现的就是系统卡顿甚至报ANR的错误。
HandlerThread
HandlerThread继承自Thread,内部保存一个Looper对象。
这是一个系统帮我们包装好的Thread,这个线程的run方法已经调用了Looper.prepare和Looper.loop(即已经绑定了一个Looper对象,并且可以开始轮询消息),创建该对象之后可以通过获得对象获取到一个Looper对象,将Looper对象传递给Handler,完成Handler和Looper以及MessageQueue的绑定。最后再其他的线程中调用Handler的sendMessage或者post(Runable)方法发送消息,handler中的callback.handleMessage方法会在HandlerThread中运行。即,将消息发送到了特定的线程(此处是HandlerThread)处理。
IntentService
IntentService继承自Service,运行时优先级更高,内部使用了HandlerThread作为处理消息的线程。内部有一个私有内部类ServiceHandler继承自Handler,并且会创建一个ServiceHandler对象。
使用startService()方法启动IntentService时,不会重新创建一个服务,会调用ServiceHandler对象发送包含该Intent的Message对象,该对象通过HandlerThread处理后交给ServiceHandler重写的handleMessage方法进行处理,处理的方式是调用IntentService的onHandleIntent(Intent)方法,所以使用的方式就是创建一个继承自IntentService类的子类,并重写onHandleIntent方法,在该方法中处理startService时传递的Intent。Intent中包含有要交给Service处理的信息。