Handler原理与使用,以及Android中异步更新的UI的方式
好长时间都没有发布新的博客了,今天来写一篇关于Android中使用频率极高,但是也经常让大家感觉摸不着头脑的handler.
下面呢 主要从以下几个方面来讲.
1. 为什么禁止在非UI线程更新UI
2. Handler概述
3. Handler的几种使用方式
4. Handler的原理,以及handler与message queue, looper之间的关系
5. HandlerThread是什么?
6. 异步更新UI 的几种方式
7. 非UI线程真的不能更新UI吗?
为什么禁止在非UI线程更新UI?
Handler翻译成中文就是”处理者”的意思,实际上也确实如此.当我们在处理Android中多线程问题的时候,有需要处理的事情就可以去找Handler了.那么为什么会产生多线程问题呢?
Google在设计的framework的时候禁止开发者在非UI线程去更新界面UI.那么Google为什么要这么做呢?查看源码之后可以发现更新UI 的相关方法为了保证效率都是没有加上同步锁的.而更新UI绘制图形会调用底层硬件相关方法,如果不加以限制可能会产生意想不到的后果.所以为了兼顾效率与安全,就设计成只能在主线程更新UI.另外不只是Google,iOS系统也是禁止在主线程更新UI的,足以证明这样的设计是一种通用做法.
Handler概述
但是如果只是简简单单设计成只能在主线程更新UI的话,那么对开发者的素质要求势必会提高,java中的多线程问题想必大家学习的时候也是一大难点吧.开发者为了保证线程间通信的代码不会乱掉势必要自己设计一套线程间通信的框架.这样的要求未免太高,不利于Android平台的初期拓展.于是Google就在framework中封装好了这么一套线程间通信的框架.这套框架在Google的代码中也是应用相当广泛,我们常用的Activity的生命周期回调,事件传递等framework层中的代码中,Handler机制也是随处可见.下面就让我们来学习一下Handler的基本使用吧.
Handler的基本使用
Handler的使用主要和下面几个方法相关:
sendMessage()
sendMessageDelayed()
post()
postDelayed()
带delayed后缀的方法都是在原方法上延迟几秒的方法.下面只演示sendMessage()方法和post()方法.
废话不多说上代码:首先是sendMessage()方法
public class MainActivity extends ActionBarActivity {
private Handler handler = new Handler(){
@Override
public void handleMessage(Message msg) {
textView.setText("文字被改变啦");
}
};
private TextView textView;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
textView = (TextView) findViewById(R.id.test);
new Thread(new Runnable() {
@Override
public void run() {
try {
Thread.sleep(2000);
handler.sendEmptyMessage(1);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
}).start();
}
}
运行结果:
这段代码里我们使用handler在子线程向主线程里发送了一条空消息.这样handlemessage方法就可以在主线程执行了
Message也可以指定并传递数据,message共有几个主要的属性.what,object,arg1,arg2.
使用示例:
public class MainActivity extends ActionBarActivity {
private Handler handler = new Handler(){
@Override
public void handleMessage(Message msg) {
String string = "";
for (String temp : (ArrayList)msg.obj)
string += temp;
textView.setText("what:" + msg.what + "arg1" + msg.arg1 + "arg2" + msg.arg2 + "objString:"+string);
}
};
private TextView textView;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
textView = (TextView) findViewById(R.id.test);
new Thread(new Runnable() {
@Override
public void run() {
try {
Thread.sleep(2000);
Message message = Message.obtain();
message.what = 1;
message.arg1 = 100;
message.arg2 = 200;
ArrayList strings = new ArrayList();
strings.add("这是第一条");
strings.add("这个第二条");
message.obj = strings;
handler.sendMessage(message);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}).start();
}
}
可以注意到上面这段代码使用Message.obtain()方法获取message对象.这样就可以复用系统提供给我们的message对象了.当然,你不在乎内存的话也可以直接new,但是不推荐那么写.
运行结果:
下面是post()方法的使用.
代码示例
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
textView = (TextView) findViewById(R.id.test);
new Thread(new Runnable() {
@Override
public void run() {
try {
Thread.sleep(2000);
handler.post(new Runnable() {
@Override
public void run() {
textView.setText("post被执行了");
}
});
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}).start();
}
执行结果:
这样的话post里面的代码就可以运行在主线程了.需要注意的是如果使用post方法执行,那么handlemessage方法就不会再执行了.
此外message处理方式还允许使用者指定一个callback(),在handlemessage之前执行,如果该callback()返回true,则该message会被拦截.返回false就可以继续向handler传递.
具体示例如下:
public class MainActivity extends Activity {
private Handler handler = new Handler(new Handler.Callback() {
@Override
public boolean handleMessage(Message msg) {
textView.setText("消息被callback拦截");
return true;
}
}){
@Override
public void handleMessage(Message msg) {
textView.setText("handler接收到消息,hanlemessage执行");
}
};
private TextView textView;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
textView = (TextView) findViewById(R.id.test);
new Thread(new Runnable() {
@Override
public void run() {
try {
Thread.sleep(2000);
handler.sendEmptyMessage(1);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}).start();
}
}
执行结果:
看到这里有的哥们可能就迷糊了,完全可以直接在handlemessage()方法根据message.what判断,为什么还要多此一举设计一个callback出来呢.其实我个人猜想,这样的设计可能都是为了扩展性考虑的.如果有大牛写了第三方框架,但是又希望给使用框架的程序员控制框架的一些行为,就可以对外把callback提供出去.让使用者程序员自行拦截message.但是笔者还没有使用过这样的框架.
Handler的原理
好的,说完了handler的基本使用,下面就轮到handler的原理了.说到handler的原理,就不得不提到message queue和looper.
下面让我们来追踪一下源码,看看调用sendmessage()方法之后,到底发生了什么.
查看源码可知,不论是post(),postDelayed(),sendmessage()还是sendmessageDelayed()最终都会辗转调用到sendMessageAtTime().
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);
}
经过一些健壮性判断之后,调用了enqueueMessage()方法.
继续追踪,
private boolean enqueueMessage(MessageQueue queue, Message msg, long uptimeMillis) {
msg.target = this;
if (mAsynchronous) {
msg.setAsynchronous(true);
}
return queue.enqueueMessage(msg, uptimeMillis);
}
继续追踪
boolean enqueueMessage(Message msg, long when) {
if (msg.target == null) {
throw new IllegalArgumentException("Message must have a target.");
}
if (msg.isInUse()) {
throw new IllegalStateException(msg + " This message is already in use.");
}
synchronized (this) {
if (mQuitting) {
IllegalStateException e = new IllegalStateException(
msg.target + " sending message to a Handler on a dead thread");
Log.w("MessageQueue", e.getMessage(), e);
msg.recycle();
return false;
}
msg.markInUse();
msg.when = when;
Message p = mMessages;
boolean needWake;
if (p == null || when == 0 || when < p.when) {
// New head, wake up the event queue if blocked.
msg.next = p;
mMessages = msg;
needWake = mBlocked;
} else {
// Inserted within the middle of the queue. Usually we don't have to wake
// up the event queue unless there is a barrier at the head of the queue
// and the message is the earliest asynchronous message in the queue.
needWake = mBlocked && p.target == null && msg.isAsynchronous();
Message prev;
for (;;) {
prev = p;
p = p.next;
if (p == null || when < p.when) {
break;
}
if (needWake && p.isAsynchronous()) {
needWake = false;
}
}
msg.next = p; // invariant: p == prev.next
prev.next = msg;
}
// We can assume mPtr != 0 because mQuitting is false.
if (needWake) {
nativeWake(mPtr);
}
}
return true;
}
可以发现,message被放入messagequeue管理的一个线性结构中.到这里handler的使命就完成了.那么message是如何被主线程使用的呢,handlemessage()怎么样在主线程执行的呢?这里就要请出我们的第三个主角looper了.顾名思义,looper是一个和旋转和圆有关的东西.事实也确实如此,looper中有个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;
// Make sure the identity of this thread is that of the local process,
// and keep track of what that identity token actually is.
Binder.clearCallingIdentity();
final long ident = Binder.clearCallingIdentity();
for (;;) {
Message msg = queue.next(); // might block
if (msg == null) {
// No message indicates that the message queue is quitting.
return;
}
// This must be in a local variable, in case a UI event sets the logger
Printer logging = me.mLogging;
if (logging != null) {
logging.println(">>>>> Dispatching to " + msg.target + " " +
msg.callback + ": " + msg.what);
}
msg.target.dispatchMessage(msg);
if (logging != null) {
logging.println("<<<<< Finished to " + msg.target + " " + msg.callback);
}
// Make sure that during the course of dispatching the
// identity of the thread wasn't corrupted.
final long newIdent = Binder.clearCallingIdentity();
if (ident != newIdent) {
Log.wtf(TAG, "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);
}
msg.recycleUnchecked();
}
}
可以看到,loop()方法的任务就是在loop关联的queue中遍历,如果取到了message,就调用该message的target属性的dispatchMessage()方法.那么message的target属性又是在哪里被赋值的呢.
大家还记得上面追踪到的handler.enqueueMessage()方法吗,这个方法里有这么一句msg.target =this;所以message的target对象就是发送它的handler对象.所以所有使用handler.sendMessage()发送的消息,最终都会发送给handler自己.
那么如果我们不希望发送给默认的target对象该怎么办呢.除了直接调用目标handler的sendMessage()方法,这里补充一个发送消息的方法.
Message message = Message.obtain();
message.setTarget(handler);
message.sendToTarget();
好的补充完毕,我们继续追踪dispatchMessage()方法.
public void dispatchMessage(Message msg) {
if (msg.callback != null) {
handleCallback(msg);
} else {
if (mCallback != null) {
if (mCallback.handleMessage(msg)) {
return;
}
}
handleMessage(msg);
}
}
这里需要注意的是,出现了两个callback,一个是message对象的callback,另一个是mCallback.其中如果使用post()相关的方法发送消息.那么message.callback属性就会被赋值传进来的runnable对象.而mCallback则是创建handler时传进去的拦截消息的方法.
到了这里,逻辑应该很清楚了,handlecallback()方法就是调用了message.callback的run()方法.
那么我们该如何,让looper工作起来呢.如果希望代码是在主线程工作的,那么只需要初始化handler的代码是在主线程执行的.其余的不用管,一股脑的发就行.
但是如果代码的目的地不是主线程.那么就必须在Handler初始化之前调用looper.Prepare().并在最后调用looper.loop()方法让looper工作起来.总而言之,Handler是在那个线程中初始化的(未指定looper参数),那么handlemessage方法就会在哪个线程中执行.但本质上handler的handlemessage方法在哪个线程中执行最主要决定权还是在looper.如果未传递,那么looper就会与当前线程关联,从而在当前线程执行该方法.
HandlerThread是什么?
首先,看下面代码:
public class MainActivity extends Activity {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
MyRunnable myRunnable = new MyRunnable();
new Thread(myRunnable).start();
myRunnable.handler.sendEmptyMessage(1);
}
private class MyRunnable implements Runnable {
private Handler handler;
@Override
public void run() {
Looper.prepare();
handler = new Handler(){
@Override
public void handleMessage(Message msg) {
Log.e("tag", "currentThread:" + Thread.currentThread());
}
};
Looper.loop();
}
}
}
这段代码并没有如预期般打出log,而是报出了空指针异常.那么是什么原因呢?主要的问题就在于多线程的安全问题.
当使用Handler发送消息时,此时的handler对象在另一条线程中还未初始化.所以就报出了空指针异常.
解决这个问题,系统已经给我们封装好了一个handlerThread类,使用方法如下:
public class MainActivity extends Activity {
@Override
protected void onCreate(BundlesavedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
HandlerThread handlerThread = newHandlerThread("handler thread");
handlerThread.start();
Handler handler = newHandler(handlerThread.getLooper()){
@Override
public void handleMessage(Messagemsg) {
Log.e("TAG",Thread.currentThread().toString());
}
};
handler.sendEmptyMessage(1);
}
}这样就可以实现主线程向子线程发送消息了.
那么HandlerThread为什么可以解决这一问题呢,查看源码可以发现,内部采用了wait()和notify()机制来保证getLooper()每次都可以获得非空的值.
更新UI 的几种方式
下面来总结一些Android中更新UI 的几种方式:下面列举的几种方式其实本质都是用Handler实现.
1. Activity runOnUiThread();
2. Handler post()
3. Handler sendMessage()
4. View post()
非UI线程真的不能更新UI吗
实际上这种说法是不严谨的.下面这段代码实现了在非UI线程更新UI.
@Override
protected voidonCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
textView = (TextView)findViewById(R.id.test);
new Thread(newRunnable() {
@Override
public void run(){
textView.setText("子线程中执行");
}
}).start();
}
运行效果:
看到这里可能大家的世界观都崩塌了.一直查看各种资料都是说子线程中无法更新UI,而这里为什么又可以用子线程更新UI呢.要弄明白这个问题,我们就来查看一下更新UI的调用步骤.
->android.widget.TextView.setText
-> android.widget.TextView.checkForRelayout
-> android.view.View.invalidate
-> android.view.ViewGroup.invalidateChild
-> android.view.ViewRoot.invalidateChildInParent
-> android.view.ViewRoot.invalidateChild
-> android.view.ViewRoot.checkThread
由调用栈可以看到,经过各种调用最后调用了ViewRoot的checkThread()方法.奥秘就在这里,因为ViewRoot的创建时机是在OnResume()方法内.所以在oncreate()时,是不会调用到ViewRoot的checkThread()方法的.也就不会报出异常了.
可是如果我们让子线程睡眠2秒再去执行settext方法,那么就又会报出无法执行在origin线程执行更新UI的操作.
实际上,如果我们让子线程也拥有自己的ViewRoot的话,那么子线程也是可以更新UI的.具体实践步骤可以参见参考资料的这篇文章,这里就不详细展开了.
参考资料: http://blog.csdn.net/imyfriend/article/details/6877959