Android消息机制
Posted Porsche520
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Android消息机制相关的知识,希望对你有一定的参考价值。
每一个android应用在启动的时候都会创建一个线程,这个线程被称为主线程或者U
I线程,Android应用的所有操作默认都会运行在这个线程中。
但是当我们想要进行数据请求,图片下载,或者其他耗时操作时,是不可能在这个UI
线程做的,因为Android在3.0以后的版本已经禁止了这件事情,直接抛出一个异常。所以我们需要一个子线程来处理那些除UI
操作的事情。
但是这个又会有一个问题,我们只能在UI
线程进程UI
操作,只能在子线程进行耗时操作,如果我们需要在耗时操作结束后在Android界面上显示一个View,我们应该怎么做?我们是不可能在子线程直接刷新UI
的。这时我们需要用到Android的消息机制,来实现主线程和子线程的通信。简单来说,就是子线程获取到数据之后,不直接进行UI
更新,而是把数据装到消息中发送到主线程,主线程中有一个循环轮询会立即收到子线程发过来的信息,然后拿到消息数据后在主线程更新UI
。说起来比较简单,我们来仔细的看一下具体是怎么说的。
处理消息的手段——Handler, Looper, MessageQueue
Handler
我们先讲解一下Handler,Handler顾名思义就是处理者,通常对他的用法是在UI
线程中新建一个Handler
,并覆写他的handleMessage
,
然后再耗时的线程中将消息post
给UI
线程,例子如下:
class MyHandler extends Handler{
@Override
public void handleMessage(Message msg){
//更新UI
}
}
MyHandler mHandler = new MyHandler();
new Thread(){
public void run(){
mHandler.sendEmptyMessage(123);
};
}.start();
这里规定了Handler
必须在主线程创建,因为只有在UI
线程创建才会让Handler
关联到已有的MessageQueue
。而MessageQueue
被封装到Looper
中,而Looper
又通过ThreadLocal
封装到一个线程中,最后相当于MessageQueue
关联了一个线程。所以简单来说就是Handler将消息投递到一个关联了线程的MessageQueue
中,然后Handler
在从MessageQueue
中取出消息,并且处理它。
我们看一下Handler的2个常用的方法
void handleMessage(Message msg) :
处理消息的方法
final boolean sendMessage(Message msg) :
立即发送消息
第一个方法 我们通常在UI
线程中执行,一般用来刷新UI
,至于如果创建了一个非静态内部类产生对内存泄漏,建议参考这篇博客Handler引发的内存泄漏.第二个方法我们通常在子线程中执行,需要一个Handler的实例化对象,通常是由主线程去去传递给子线程。并且需要一个Message对象,指定他的msg.what
作为消息的标示,但是如果我们只是用Handler去处理一个消息的时候,选择post方法是个更好的选择,例子如下:
private Handler mHandler = new Handler();
new Thread(new Runnable() {
@Override
public void run() {
mHandler.post(new Runnable() {
@Override
public void run() {
//UI操作
...
}
});
}
}).start();
下面我们接着讨论下消息的循环队列MessageQueue
与包装他的Looper
循环
Looper和MessageQueue
上面提到了在UI
线程中创建并实例化Handler对象不需要Looper
和MessageQueue
,因为我们的应用在启动的时候先执行了ActivityThreadMain
,在这个方法就是Java语言运行的入口public
static void main(String [] args)
在这里面创建了一个MainLooper
,创建的过程如下:
public static void main(string[] args){
//初始化
Looper.prepareMainLooper();
ActivityThread thread = new ActivityThread();
thread.attach(false);
if(sMainThreadHandler == null){
sMainThreadHandler = thread.getHandler();
}
AsyncTask.init();
//动起来
Looper.loop();
}
这里面并没有MessageQueue的出现,我们可以看一看Looper类的源码,来了解在初始化的时候发生了什么有趣的事情。
public class Looper {
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());
}
// 其他方法
}
我们一行行的看这段代码,首先是实例化一个ThreadLocal对象,这个用来实现Looper
循环的本地化存储,关于ThreadLocal
可以看这篇文章为什么用ThreadLocal,简而言之就是当多个线程同时访问Looper
对象的时候,我们不用synchronized
同步机制来处理他,而是为每个线程创建一个自己的Looper
副本,A线程改变了A的looper
副本,不影响B线程的Looper
,从而比较高效的实现线程安全。后面几句依次定义了MessageQueue
,并对Looper进行了私有化构造,在prepare
方法中将Looper对象设置给了sThreadLocal
这样MessageQueue
包装在了Looper对象中,同时通过ThreadLocal
使得线程和Looper关联上,从而消息队列与线程关联上,并且不同的线程就不能访问对方的消息队列。
如下图所示:
接着就是Looper.loop
循环执行起来,我们看一下,在loop
方法里面执行了发生了什么事情
public static final void loop() {
Looper me = myLooper(); //得到当前线程Looper
MessageQueue queue = me.mQueue; //得到当前looper的MQ
while (true) {
Message msg = queue.next(); // 取出message
if (msg != null) {
if (msg.target == null) {
return;
}
msg.target.dispatchMessage(msg);
msg.recycle();
}
}
}
这是省略版的代码,我们从这里看出无限循环执行,首先从消息队列中不断取出消息,然后不断msg
是否为空,msg.target
是否为空,不空的话,执行dispatchMessage
方法,这个方法是handler的一个方法,由此我们可以看出msg.target
是handler
的类型,至此,通过Looper.prepare
和Loop.loop
实现了MessageQueue,Looper,Handler
三者之间的关联。而Handler
与Looper
,和MessageQueue
关联则是在Handler的默认构造器中,通过Looper.getLooper
获取loop对象,从而获取MessageQueue
,其源码如下:
public Handler(){
//直接把关联looper的MQ作为自己的MQ,因此它的消息将发送到关联looper的MQ上
mLooper = Looper.myLooper();
mQueue = mLooper.mQueue;
mCallback = null;
}
然后我们的流程图可以多些内容,如下所示:
我们接下来看一下dispatchMessage()
方法,在该方法中实际上只是一个分发方法,如果Runable
类型的callback
为空,则执行handlerMessage
来处理消息,该方法为空,需要覆写。如果不为空,则执行handleCallback
。实际上,如果我们用handle
的post
方法,则就执行了callback
,如果用sendMessage
,则就执行了handleMessage
这里无论是post(Runnable
callback)
还是handlerMessage
实际上都是在调用一个方法sendMessageDelayed(Message
msg)
只不过handlerMessage
是直接接受一个参数,而Runable
callback
实际上是将这个Runable
对象赋给了Message
对象的callback
成员变量,最后将Message
对象插入消息队列里面。最后Looper不断从MessageQueue中读取消息,并且调用Handler的dispatchMessage消息,在根据callback是否为空,来采用不同的方法执行。Android消息机制分析到此结束。
回到最开始
我们这次知道了为什么要在主线程中实例化Handler
对象才能更新UI
刷新,因为只有发送到UI
线程的消息,才能被UI
线程的handler
处理,如果我们要在非UI
线程中,实例化Handler,则必须先将线程变成LooperThread
,在实例化。也就是说执行如下的代码:
Loop.prepare();
hander = new Handler;
Loop.loop
至于原因相信读完上面的讲解,应该知道。
现在我们看一下我们最开始的代码,最后脑补一下Handler的工作流程。
class MyHandler extends Handler{
@Override
public void handleMessage(Message msg){
//更新UI
}
}
MyHandler mHandler = new MyHandler();
new Thread(){
public void run(){
mHandler.sendEmptyMessage(123);
};
}.start();
在Handler
实例化成mHandler
的时候,系统通过Handler
默认的构造函数完成了Handler
与Looper
的关联,并通过Looper
关联到了MessageQueue
。而主线程的Looper
则早在系统启动的时候通过Loop.prepare
就已经构造完成了,并与UI
线程通过ThreadLocal
关联起来,然后在新的线程中执行mHandler.sendEmptyMessage
,将Message
发送给了MessageQueue
,Looper.loop在循环的时候,不断取出message,交给Handler处理,在我们覆写的HandleMessage中,识别出我们发送的消息,将消息处理。当然这里只是一个Empty消息,所以在handleMessage中没有去执行msg.what的判断。
以上是关于Android消息机制的主要内容,如果未能解决你的问题,请参考以下文章
Android HandlerThread 消息循环机制之源代码解析
从Handler+Message+Looper源代码带你分析Android系统的消息处理机制
Win32窗口消息机制 x Android消息机制 x 异步执行
[Android源代码分析]Android消息机制,Handler,Message,Looper,MessageQueue