android handle 阻塞,Android中handler机制原理详解
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中。
参考文章