1、handler的作用
handler是android线程之间的消息机制,主要的作用是将一个任务切换到指定的线程中去执行,(准确的说是切换到构成handler的looper所在的线程中去出处理)android系统中的一个例子就是主线程中的所有操作都是通过主线程中的handler去处理的。
2、handler的架构
Handler的运行需要底层的 messagequeue和 looper做支撑。
3、handler原理
3 .1 、首先说messagequeue,messagequeue 是 一 个 消 息 队 列 , 它是采用单链表的数据结构来存储消息的,因为单链表在插入删除上 的效率非常高。(Meaasgequeue主要包含一个是插入消 息的 enqueuemessage方法,和一个取出一条消息的next方法。)
3.2、然后说 looper,looper在安卓的消息机制中是扮演着消息调度的角色,具体来说就是他会不停的从 messagequeue中查看 是否有新消息,如果有,并且这个消息需要执行,就从队列中取出这个消息进行执行,(死循环遍历消息:取消息的线程会先阻塞一段时间(队头消息的执行时间减去当前时间),然后从队列中取出队头消息),否则会一直阻塞在messagequeue的next那里。(构成 一个 looper是需要一个 messagequeue,而构成一个 handler则需 要一个 looper,)另外looper一般是调用Looper.prepare()方法使用 threadlocal在线程的ThreadLocalMap中存储一个looper的,线程中有了looper之后就可以在这个线程中创建一个 handler了。
3.2、然后说 looper,looper在安卓的消息机制中是扮演着消息调度的角色。
Looper取消息的过程是这样的:
如果队列中有消息:
1、判断队头消息的执行时间是否大于当前时间,如果大于,就调用nativePollOnce阻塞一段时间(队头消息的执行时间-当前时间)然后取出队头消息进行执行。
2、否则就立即取出队头消息进行执行。
3、如果队列中没有消息,就一直阻塞,直到下一个消息来到,才唤醒取消息的线程继续上述循环。
Message next() {
final long ptr = mPtr;
if (ptr == 0) {
return null;
}
int pendingIdleHandlerCount = -1; // -1 only during first iteration
int nextPollTimeoutMillis = 0;
for (;;) {
nativePollOnce(ptr, nextPollTimeoutMillis);
synchronized (this) {
// Try to retrieve the next message. Return if found.
final long now = SystemClock.uptimeMillis();
Message prevMsg = null;
Message msg = mMessages;
if (msg != null && msg.target == null) {
// Stalled by a barrier. Find the next asynchronous message in the queue.
do {
prevMsg = msg;
msg = msg.next;
} while (msg != null && !msg.isAsynchronous());
}
if (msg != null) {
if (now < msg.when) {
// Next message is not ready. Set a timeout to wake up when it is ready.
nextPollTimeoutMillis = (int) Math.min(msg.when - now, Integer.MAX_VALUE);
} else {
// Got a message.
mBlocked = false;
if (prevMsg != null) {
prevMsg.next = msg.next;
} else {
mMessages = msg.next;
}
msg.next = null;
if (DEBUG) Log.v(TAG, "Returning message: " + msg);
msg.markInUse();
return msg;
}
} else {
// No more messages.
nextPollTimeoutMillis = -1;
}
// Process the quit message now that all pending messages have been handled.
if (mQuitting) {
dispose();
return null;
}
}
pendingIdleHandlerCount = 0;
nextPollTimeoutMillis = 0;
}
}
nativePollOnce(ptr, nextPollTimeoutMillis),这是一个native方法,实际作用就是通过Native层的MessageQueue阻塞nextPollTimeoutMillis毫秒的时间。
1.如果nextPollTimeoutMillis=-1,一直阻塞不会超时。
2.如果nextPollTimeoutMillis=0,不会阻塞,立即返回。
3.如果nextPollTimeoutMillis>0,最长阻塞nextPollTimeoutMillis毫秒(超时),如果期间有程序唤醒会立即返回。
3.3、最后说 handler
handler通过handler.send (message)发送消息,实际上是往构成他的 looper的 messagequeue中 插入了一条消息,在将这条消息插入 messagequeue中之前,他需 要将此消息的 target变量指向当前发它的 handler,然后looper在适当的时机取出这个消息,(looper发现构成它的 messagequeue中有消息时, looper的 loop方法就会从 messagequeue中取出这条消息),然后调 用这个消息对应的handler的dispatchmessage方法来处理这个消息(即msg.target.dispatchmessage),注意,dispatchmessage 方法是在构成 handler的 looper中的loop方法中调用的,所以处理消息的逻辑就切换到了构成handler的looper所在的线程之中了。
messagequeue加入一条消息唤醒取消息线程的三种情况
if (p == null || when == 0 || when < p.when) {
// New head, wake up the event queue if blocked.
msg.next = p;
mMessages = msg;
needWake = mBlocked;
}
1、messagequeue为空
2、当前消息不是延时消息
3、当前消息执行时间小于队头消息执行时间
(hanlder的构成是需要一个 looper,主线程 之中,在activitythread的main方法中(程序入口)通过 looper.preparemainlooper在主线 程中存储一个 looper,而在子线程之中,我们则需要手动的通过 looper的 prepare在子线程中存储一个 looper,然后通过 looper.loop 开启一个消息循环)。
4、主线程中的handler
android系统中的一个例子就是主线程中的所有操作都是通过主线程中的handler去处理的。例如activity的生命周期方法调用就是通过主线程中的handler去处理的。
在app的主线程中有一个类是activitythread,这个类中有一个main方法是app程序的入口,在main方法中使用Looper.prepareMainLooper(),在主线程中设置了一个looper,然后创建了一个applicationthread的线程用于和server进程中applicationthreadproxy进行进程通信,最后调用了Looper.loop()开启消息循环。
在activity的生命中期中,比如说系统服务ActivityManagerService调用applicationthreadproxy通过Binder给当前app进程中的applicationthread发送了一个暂停activity的操作。app进程中的applicationthread便会通过在主线程中的handler将这个暂停activity的消息插入到主线程的messagequeue中去处理。
5、主线程的死循环一直运行是不是特别消耗CPU资源呢?
这里就涉及到Linux pipe/epoll机制,在主线程的MessageQueue没有消息时,主线程便阻塞在loop的queue.next()中的nativePollOnce()方法里,相当于java层的线程waite机制,此时主线程会释放CPU资源进入休眠状态,直到下个消息到达时调用nativewake,通过往pipe管道写端写入数据来唤醒主线程工作。相当于java层的notify机制,去唤醒主线程,然后处理消息,所以主线程大多数时候都是处于休眠状态,并不会消耗大量CPU资源。
从looper取消息的过程,可以看出取消息的线程大部分时候处于阻塞状态,不会消耗cpu资源。
6、 Android中为什么主线程不会因为Looper.loop()里的死循环导致(anr)卡死?
理解1:looper死循环是不断的往构成它的消息队列中取消息,如果当前队列中没有消息,或者队列中的消息不需要现在立即处理,looper所在的线程就进入wait状态,释放cpu资源,其他的线程仍可处理事件。比如说applicationthread仍可接收服务进程中的消息来处理,如果这个消息需要在主线程中处理,它就会调用主线程中的handler,将这个消息加到主线程的消息队列中去处理。
理解2:looper取消息的过程是先wait一段时间(这段时间是messagequeue队首消息的执行时间减去当前时间),然后醒来从messagequeue中取出队首消息进行执行,wait过程中主线程是释放cpu资源的,其他的线程(applicationthread)仍可处理事件。
理解3:(首先主线程中的死循环不会导致app anr,它会使得主线程阻塞在messagequeue的next中的nativePollOnce()方法里,当有消息来时就会唤醒主线程进行消息处理,即使主线程在休眠的时候也有其他的线程(applicationthread)在处理事件。)
1、首先Anr和死循环不是一个概念。
2、另外从looper取消息的过程来看,取消息的线程大部分时候处于阻塞状态,其他线程以及进程仍可利用cpu给主线程发消息,主线程被唤醒后,处理消息。
为什么主线程中会采用死循环呢?
线程是一段可执行的代码,当可执行代码执行完成后,线程生命周期便该终止了。而对于主线程,我们是绝不希望会被运行一段时间就退出,所以采用死循环保证它不会被退出。
而anr原因是,主线程中messagequeue中一个message的处理时间过长,导致接下来的消息无法处理,比如说一个消息的处理时间超过了5秒,导致用户的输入无法响应,才会出现anr。
7、handler.postDelayed(Runnable r, long delayMillis)
handler.postDelayed在message加入到messagequeue中之前,会计算出这个消息的执行时间SystemClock.uptimeMillis() + delayMillis,(SystemClock.uptimeMillis()是开机到现在的时间(毫秒)),然后通过enqueueMessage 将message和其执行的时间一起添加进messagequeue,在enqueueMessage方法中会根据这个消息的执行时间去将这个消息插入到适当的位置,简单的说,messagequeue是按消息的执行时间message.when排序的。如果插在队列中间,说明该消息不需要马上处理,不需要由这个消息来唤醒队列。 如果插在队列头部(或者when=0),则表明可能要马上处理这个消息。如果当前队列正在堵塞,则需要唤醒它进行处理。 通过nativeWake方法唤醒队列。
8、如何保证延时消息精确执行?
1、从looper取消息过程来看,
2、从加入一条新的消息过程来看。
这两个过程都不存在任何延迟
8、ThreadLocal
ThreadLocal 可以在多个线程内存储数据,使用ThreadLocal存储的数据在多个线程之间是隔离的,因为它是将数据存储在每个线程内的ThreadLocalMap中。
参考文章