Android基础-Handler全面的分析
hi,大家好,我是爱吃香蕉的猴子,看了很多handler looper messageQuenue的文章,今天也想全面的记录一下这一系列;
开头 还是先拿出来,早年间看的郭神的文章handler的分析
handler1 = new Handler();
new Thread(new Runnable() {
@Override
public void run() {
handler2 = new Handler();
}
}).start();
这样写会报错,原因大家也都知道是handler2没有创建自己looper, 原因在下面的hander源码中
public Handler(@Nullable Callback callback, boolean async) {
.....
mLooper = Looper.myLooper();
if (mLooper == null) {
throw new RuntimeException(
"Can't create handler inside thread " + Thread.currentThread()
+ " that has not called Looper.prepare()");
}
mQueue = mLooper.mQueue;
mCallback = callback;
mAsynchronous = async;
}
在源码中可以看到Looper.myLooper(); 获取了looper的对象,如果==null就是上面的说的会报错;这样就明白为什么要创建looper;
现在可以说每个handler都对应一个looper√
那looper是如何创建和管理的呢? 看上面的那个异常信息not called Looper.prepare(), 则我们看一下Looper的prepare方法:
static final ThreadLocal<Looper> sThreadLocal = new ThreadLocal<Looper>();
private static void prepare(boolean quitAllowed) {
if (sThreadLocal.get() != null) {
throw new RuntimeException("Only one Looper may be created per thread");
}
sThreadLocal.set(new Looper(quitAllowed));
}
在这里我们还获得一个信息,每个线程只可以获取一个Looper √。
这里可以看到Looper是在threadLocal中被管理的,可以猜到Looper.myLooper();是threadlocal的get 方法;
public static @Nullable Looper myLooper() {
return sThreadLocal.get();
}
在这里补充一下:Android 开发艺术探索中ThreadLocal的解释:
ThreadLocal是一个线程内部的数据存储类,通过它可以指定的线程中存储数据,数据存储以后,只有在指定线程中可以获取到存储的数据,对于其他线程来说则无法获取到数据。在日常开发中用到ThreadLocal的地方比较少,但是在某些特殊场景下,通过ThreadLocal可以轻松的实现一些看起来很复杂的功能,这一点在Android的源码中也有所体现,比如:Looper ActivityThread以及AMS中都用到了ThreadLocal。
一般来说,当某些数据是以线程为作用域并且不同的线程需要获取当前线程的Looper,显然Looper的作用域就是线程并且不同线程具有不同的Looper, 这个时候通过ThreadLocal就可以轻松实现Looper在线程中存取。
有同学可能会有疑问,为什么handler1没有创建looper, 这个是ActivityThread中已经创建:
public static void main(String[] args) {
.....
Looper.prepareMainLooper();
.....
Now 我们开始分析消息发送的过程,这里就会设计Looper 和 MessageQuene; 先上一个例子:
class LooperThread extends Thread {
public Handler mHandler;
public void run() {
Looper.prepare();
mHandler = new Handler() {
public void handleMessage(Message msg) {
// process incoming messages here
}
};
Looper.loop();
}
//handler.sendMessage(message);
}
那就从sendMessage入手吧
这样–> MessageQueue:
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) {
....
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 {
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;
}
MessageQueue并没有使用一个集合把所有的消息都保存起来,它只使用了一个mMessages对象表示当前待处理的消息.所谓的入队其实就是将所有的消息按时间来进行排序,这个时间当然就是我们刚才介绍的uptimeMillis参数。具体的操作方法就根据时间的顺序调用msg.next,从而为每一个消息指定它的下一个消息是什么。当然如果你是通过sendMessageAtFrontOfQueue()方法来发送消息的,它也会调用enqueueMessage()来让消息入队,只不过时间为0,这时会把mMessages赋值为新入队的这条消息,然后将这条消息的next指定为刚才的mMessages,这样也就完成了添加消息到队列头部的操作.
这里就完成了消息的入队操作,那既然有入队操作 那么就有出队操作,这个也不难找,在例子中有Looper.loop,该方法中就实现了出队;这个方法的代码有点多,我这里就拿出for的代码看看:
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();
// Allow overriding a threshold with a system prop. e.g.
// adb shell 'setprop log.looper.1000.main.slow 1 && stop && start'
final int thresholdOverride =
SystemProperties.getInt("log.looper."
+ Process.myUid() + "."
+ Thread.currentThread().getName()
+ ".slow", 0);
boolean slowDeliveryDetected = false;
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
final Printer logging = me.mLogging;
if (logging != null) {
logging.println(">>>>> Dispatching to " + msg.target + " " +
msg.callback + ": " + msg.what);
}
// Make sure the observer won't change while processing a transaction.
final Observer observer = sObserver;
final long traceTag = me.mTraceTag;
long slowDispatchThresholdMs = me.mSlowDispatchThresholdMs;
long slowDeliveryThresholdMs = me.mSlowDeliveryThresholdMs;
if (thresholdOverride > 0) {
slowDispatchThresholdMs = thresholdOverride;
slowDeliveryThresholdMs = thresholdOverride;
}
final boolean logSlowDelivery = (slowDeliveryThresholdMs > 0) && (msg.when > 0);
final boolean logSlowDispatch = (slowDispatchThresholdMs > 0);
final boolean needStartTime = logSlowDelivery || logSlowDispatch;
final boolean needEndTime = logSlowDispatch;
if (traceTag != 0 && Trace.isTagEnabled(traceTag)) {
Trace.traceBegin(traceTag, msg.target.getTraceName(msg));
}
final long dispatchStart = needStartTime ? SystemClock.uptimeMillis() : 0;
final long dispatchEnd;
Object token = null;
if (observer != null) {
token = observer.messageDispatchStarting();
}
long origWorkSource = ThreadLocalWorkSource.setUid(msg.workSourceUid);
try {
msg.target.dispatchMessage(msg);//msg.target --> handler
if (observer != null) {
observer.messageDispatched(token, msg);
}
dispatchEnd = needEndTime ? SystemClock.uptimeMillis() : 0;
} catch (Exception exception) {
if (observer != null) {
observer.dispatchingThrewException(token, msg, exception);
}
throw exception;
} finally {
ThreadLocalWorkSource.restore(origWorkSource);
if (traceTag != 0) {
Trace.traceEnd(traceTag);
}
}
......
msg.recycleUnchecked();
}
}
进入了一个死循环,然后不断地调用的MessageQueue的next()方法,我想你已经猜到了,这个next()方法就是消息队列的出队方法。它的简单逻辑就是如果当前MessageQueue中存在mMessages(即待处理消息),就将这个消息出队,然后让下一条消息成为mMessages,否则就进入一个阻塞状态,一直等到有新的消息入队。每当有一个消息出队,就将它传递到msg.target的dispatchMessage()方法中.
下面我们就主要看一下这个next方法和dispatchMessage方法:
Message next() {
// 由上面代码得知prevMsg = null
if (prevMsg != null) {
prevMsg.next = msg.next;
} else {
// 因为mMessages始终是头结点,把mMessages指向头结点的下一个节点,
// 就相当于移除了头结点(即是移除了将被返回的消息)
mMessages = msg.next;
}
msg.next = null;
if (DEBUG) Log.v(TAG, "Returning message: " + msg);
// 标记正在使用
msg.markInUse();
// 返回msg
return msg;
next方法: 就是从头结点开始,无限循环消息链表,一直取消息,有消息便会返回这条消息交给Looper处理并从消息链表中移除这条消息,没有就会一直阻塞在这里。因为一般情况下msg.target不为null(即目标Handler不为null),所以会进入到if (msg != null)判断中。
再看dispatchMessage()方法:
这样就走完了这个消息发送的流程;
例如:在子线程发送消息,在UI线程进行handleMessage.
public class MainActivity extends Activity {
private Handler handler;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
handler = new Handler();
new Thread(new Runnable() {
@Override
public void run() {
handler.post(new Runnable() {//
@Override
public void run() {
// 在这里进行UI操作
}
});
}
}).start();
}
}
思考一个问题: 为什么再loop方法中,死循环 却不会出现ANR?
答: 我认为时两个方面1. loop的死循环是再不断的从MessageQueue中去消息,当没有消息时,就出现等待,这个等待的时候会释放资源,有了消息再被唤醒;2. 在等待消息的过程,并不存在用户 input事件的产生 故不会产生anr.
再思考一个问题: handler可以做到切换线程,但是如何 做到的线程切换??
答: 这个问题,我参考了这篇文章切换线程
摘抄:
简单来说Handler是用于同一个进程的线程间通信。Looper让主线程无限循环地从自己的MessageQueue拿出消息处理,所以我们就可以知道处理消息肯定是在主线程中处理的,那么是怎样在其他的线程往主线程的队列里放入消息呢?道理其实很简单,我们知道在同一进程中线程和线程之间资源是共享的,也就是对于任何变量在任何线程都是可以访问和修改的,只要考虑并发性做好同步就行了,那么只要拿到MessageQueue 的实例,就可以往主线程的MessageQueue放入消息,主线程在轮询的时候就可以在主线程处理这个消息。
那么是怎么拿到主线程 MessageQueue的实例呢,当然是可以拿到的(在主线程下mLooper = Looper.myLooper();mQueue = mLooper.mQueue;),Google 为了统一添加消息和消息的回调处理,又专门构建了Handler类,你只要在主线程构建Handler类,那么这个Handler实例就获取主线程MessageQueue实例的引用(获取方式mLooper = Looper.myLooper();mQueue = mLooper.mQueue;),Handler 在sendMessage的时候就通过这个引用往消息队列里插入新消息。
Handler 的另外一个作用,就是能统一处理消息的回调。这样一个Handler发出消息又确保消息处理也是自己来做,这样的设计非常的赞。具体做法就是在队列里面的Message持有Handler的引用(哪个handler 把它放到队列里,message就持有了这个handler的引用),然后等到主线程轮询到这个message的时候,就来回调我们经常重写的Handler的handleMessage(Message msg)方法。
疑问: 1. 进程中线程和线程之间资源是共享的 ??????? 2. looper是如何拿到主线程的数据?????
答: :在同一进程中线程和线程之间资源是共享的,也就是对于任何变量在任何线程都是可以访问和修改的(注意这是在操作系统层面,因为所以线程共用一个进程的资源,但在语言层面,会有局部变量,全局变量的约束,而原则上只要你能找到变量的地址,你就能在任何线程上使用)。
上面我们补充了一个LocalThread的知识,现在可以用上了,就是线程的本地变量,他将变量和线程联系起来,是不同线程获取不同的值。其实这个实现很简单一点也不神秘,只是做了一些封装,用起来很方便,用在looper上, 底层实现用的native.
最后, 大家有没有在面试过程中,提前笔试 总有这么一道脑残题
android 中切换线程的方式?
- Handler的post()方法
- View的post()方法
- Activity的runOnUiThread()方法
- AsyncTask
- thread runnable
其实,我也不知道到底要什么结果?往往会问post的实现逻辑,我就写个流程:
这里我们可以对比之前的sendMessage的图,最终都是进入到MessageQueue, 但是有个细节不同就是获取的message消息,getPostMessage:
private static Message getPostMessage(Runnable r) {
Message m = Message.obtain();
m.callback = r;
return m;
}
在这个方法中将消息的callback字段的值指定为传入的Runnable对象.这个callback字段在Handler的dispatchMessage()方法中原来有做一个检查,如果Message的callback等于null才会去调用handleMessage()方法,否则就调用handleCallback()方法.
private static void handleCallback(Message message) {
message.callback.run();
}
终于啰里啰唆写完了 。。。
Code的搬运工V1.0