从源码角度理解Android的Handler机制

发表于 分类于

说起Handler，我们一般用的最多的就是在子线程通过Handler发Message进行UI更新。当你发了一个Message后到底发生了什么就进入了Handler的handleMessage方法了？接下来我们从源码的角度对Handler一探究竟。

开局一张图

image-20210709205619320

源码探秘Message流转过程

当我们使用Handler时：

1
2
3
4
5
6
7
private Handler mHandler = new Handler(){
    @Override
    public void handleMessage(Message msg) {
        super.handleMessage(msg);
        
    }
};

首先进行的是初始化Handler对象，那么我们就先看看Handler在进行初始化时都做了什么：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
public Handler(Callback callback, boolean async) {
    if (FIND_POTENTIAL_LEAKS) {
        final Class<? extends Handler> klass = getClass();
        if ((klass.isAnonymousClass() || klass.isMemberClass() || klass.isLocalClass()) &&
                (klass.getModifiers() & Modifier.STATIC) == 0) {
            Log.w(TAG, "The following Handler class should be static or leaks might occur: " +
                klass.getCanonicalName());
        }
    }

    mLooper = Looper.myLooper();
    if (mLooper == null) {
        throw new RuntimeException(
            "Can't create handler inside thread that has not called Looper.prepare()");
    }
    mQueue = mLooper.mQueue;
    mCallback = callback;
    mAsynchronous = async;
}

看代码第11行：

1
mLooper = Looper.myLooper();

此处对mLooper成员变量进行了赋值，突然冒出来个Looper，什么鬼呢？我们顺藤摸瓜，进入Looper内看看。

1
2
3
4
5
6
7
8
9
10
11
12
13
/**
 * Return the Looper object associated with the current thread.  Returns
 * null if the calling thread is not associated with a Looper.
 */
public static @Nullable Looper myLooper() {
    return sThreadLocal.get();
}
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));
}

通过源码我们发现sThreadLocal是在prepare(boolean quitAllowed)中进行设置值操作的。
那就有点郁闷了，一般我们使用Handler时，我们没有调用这个方法啊。其实啊，是系统帮我们调用过了。看下面这段代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
/**
 * Initialize the current thread as a looper, marking it as an
 * application's main looper. The main looper for your application
 * is created by the Android environment, so you should never need
 * to call this function yourself.  See also: {@link #prepare()}
 */
public static void prepareMainLooper() {
    prepare(false);
    synchronized (Looper.class) {
        if (sMainLooper != null) {
            throw new IllegalStateException("The main Looper has already been prepared.");
        }
        sMainLooper = myLooper();
    }
}

看第8行，调用了prepare(false),然后我们再看看代码的注释，大致意思就是这个方法是在application初始化时系统调用的，用户不需要自己去调用这个方法。

然后我们继续看Handler的初始化，看Handler代码块的第15行：

1
mQueue = mLooper.mQueue;

通过源码我们了解到mQueue是MessageQueue类型的，又引入了一个新角色，其实这货就是我们口口相传的消息队列(其实内部是维护了一个Message的链表)。此处是由mLooper中的变量赋值的，进入Looper查看：

1
2
3
4
private Looper(boolean quitAllowed) {
    mQueue = new MessageQueue(quitAllowed);
    mThread = Thread.currentThread();
}

mQueue在Looper构造时进行了初始化。Handler的初始化完成。接下来我们继续沿着Handler的使用进行讲解。

我们使用Handler发消息时调用mHandler.sendMessage(msg),通过层层调用，最终进入了下面的这个方法：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
/**
 * Enqueue a message into the message queue after all pending messages
 * before the absolute time (in milliseconds) <var>uptimeMillis</var>.
 * <b>The time-base is {@link android.os.SystemClock#uptimeMillis}.</b>
 * Time spent in deep sleep will add an additional delay to execution.
 * You will receive it in {@link #handleMessage}, in the thread attached
 * to this handler.
 * 
 * @param uptimeMillis The absolute time at which the message should be
 *         delivered, using the
 *         {@link android.os.SystemClock#uptimeMillis} time-base.
 *         
 * @return Returns true if the message was successfully placed in to the 
 *         message queue.  Returns false on failure, usually because the
 *         looper processing the message queue is exiting.  Note that a
 *         result of true does not mean the message will be processed -- if
 *         the looper is quit before the delivery time of the message
 *         occurs then the message will be dropped.
 */
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);
}

private boolean enqueueMessage(MessageQueue queue, Message msg, long uptimeMillis) {
    msg.target = this;
    if (mAsynchronous) {
        msg.setAsynchronous(true);
    }
    return queue.enqueueMessage(msg, uptimeMillis);
}

看第32行的msg.target = this;既然是在Handler中的this赋值给了msg.target，也就是说target的Handler类型的，别急，下面讲消息的轮询时会用到。
最终进入到了MessageQueue的enqueueMessage方法

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
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(TAG, 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，也就是我们称之为消息的对象类，该类包含了what、obj、callback等属性，比如我们区分不同的消息时通常是通过msg.what来进行分别处理。通过msg.obj来取出消息中包含的数据。

看上面20-43行，是对msg对象加入了链表序列的操作。

上面讲了这么多，似乎还是没有讲到最终消息是如何回调到handleMessage方法执行的。接下来我们继续看上文中提到的Looper类,看Looper中如下方法：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
/**
 * Run the message queue in this thread. Be sure to call
 * {@link #quit()} to end the 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
        final Printer logging = me.mLogging;
        if (logging != null) {
            logging.println(">>>>> Dispatching to " + msg.target + " " +
                    msg.callback + ": " + msg.what);
        }
        final long traceTag = me.mTraceTag;
        if (traceTag != 0 && Trace.isTagEnabled(traceTag)) {
            Trace.traceBegin(traceTag, msg.target.getTraceName(msg));
        }
        try {
            msg.target.dispatchMessage(msg);
        } finally {
            if (traceTag != 0) {
                Trace.traceEnd(traceTag);
            }
        }
        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();
    }
}

篇幅有点长，我们只看关键部分，看第15行，一个无限制的for循环，这就是传说中的不断轮训消息队列。通过queue.next();不断的取消息。

看第32行，msg.target.dispatchMessage(msg);还记得上文中提到的msg.target吗？target即是该消息所属的Handler。也就是说dispatchMessage()是在Handler类中执行的。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
/**
 * Handle system messages here.
 */
public void dispatchMessage(Message msg) {
    if (msg.callback != null) {
        handleCallback(msg);
    } else {
        if (mCallback != null) {
            if (mCallback.handleMessage(msg)) {
                return;
            }
        }
        handleMessage(msg);
    }
}

找到了吧，最终调用了handleMessage方法。

等等……这个**loop()**方法谁调用的呢？什么时候开始执行轮询的呢？

记得上文中提到的prepareMainLooper()是系统调用的吧，其实loop方法也是由系统调用prepareMainLooper()之后又顺手把loop给调用了。我也找到了这段代码的出处，在ActivityThread中。

ActivityThread其实就是我们经常说的UI thread，也就是主线程。应用启动时由系统创建。我们都知道主线程可以使用Handler进行异步通信，因为主线程中已经创建了Looper，而这个Looper就是在这里创建的。这些其实我们的上文分析即可得出。如果其他线程需要使用Handler通信，就要自己去创建Looper。

对于主线程的Looper的初始化我们看下ActivityThread的main函数：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
public final class ActivityThread {
	 //......some code
    public static void main(String[] args) {
    	 //......some code
        // 在这儿调用 Looper.prepareMainLooper, 为应用的主线程创建Looper
        Looper.prepareMainLooper();
        ActivityThread thread = new ActivityThread();
        if (sMainThreadHandler == null) {
            sMainThreadHandler = thread.getHandler();
        }
        Looper.loop();
        //......some code
    }
    //......some code
}

看到了吧，在执行完Looper.prepareMainLooper();后，ActivityThread帮我们调用了loop轮询。所以我们一般在使用Handler时直接初始化一个Handler，然后发消息，之后等着在handleMessage中等待回调就OK了，其实是系统帮我们做了一部分工作了。

对于ActivityThread此处不做过多讲解，有时间在后面的博文中给大家掰扯掰扯应用启动的那些事儿。

以上讲解的都是在应用主线程下使用Handler的，如果我们想在子线程中使用，咋办呢？
不如我们直接按原来的写法试试：

1
2
3
4
5
6
7
8
9
10
11
12
new Thread(){
    @Override
    public void run() {
        Handler handler = new Handler(){
            @Override
            public void handleMessage(Message msg) {
                super.handleMessage(msg);
                
            }
        };
    }
}.start();

一运行，挂了。。。。抛了个异常

1
java.lang.RuntimeException: Can't create handler inside thread that has not called Looper.prepare()

咋回事儿呢？看本文上面的那段Handler初始化代码的第11行就明白了。当检测到mLooper为空时就会抛出这段异常。而上文中我们也说到了，mLooper的赋值是在prepare方法中进行的，所以正确的使用方案就有了，就如同应用主线程ActivityThread一样，我们需要先prepare一下，只不过主线程调用的是prepareMainLooper()，我们要调用prepare()，同样我们也需要调用loop()方法开始消息的轮询。

所以在子线程中，正确的使用如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
new Thread(){
    @Override
    public void run() {
        Looper.prepare();
        Handler handler = new Handler(){
            @Override
            public void handleMessage(Message msg) {
                super.handleMessage(msg);

            }
        };
        Looper.loop();
    }
}.start();

总结

来张图（图片来自网络）
[img

我们重新捋一捋：首先由这么几个重要的角色，Handler、Looper、MessageQueue、Message。在主线程下，应用启动时系统帮我们初始化了主线程的MainLooper，并开启了loop循环，我们在UI线程初始化完Handler时，可以直接使用sendMessage方法发各种Message消息，然后我们的Message进入了MessageQueue，loop不断轮询，当从MessageQueue中取到消息时就通过Message的target（即所属的Handler对象）回调到Handler的handleMessage方法，最终我们就可以快乐的在handleMessage方法里面根据不同的msg.what进行消息的区分进行不同的操作。

同步屏障

原理

同步屏障的概念，在Android开发中非常容易被人忽略，因为这个概念在我们普通的开发中太少见了，很容易被忽略。

大家经过上面的学习应该知道，线程的消息都是放到同一个MessageQueue里面，取消息的时候是互斥取消息，而 且 ，而添加消息是按照消息的执行的先后顺序进行的排序，那么问题来了，同一个时间范围内的消 息，如果它是需要立刻执行的，那我们怎么办，按照常规的办法，我们需要等到队列轮询到我自己的时候才能执行 哦，那岂不是黄花菜都凉了。所以，我们需要给紧急需要执行的消息一个绿色通道，这个绿色通道就是同步屏障的概 念。

同步屏障是什么?

屏障的意思即为阻碍，顾名思义，同步屏障就是阻碍同步消息，只让异步消息通过。如何开启同步屏障呢?如下而
已:

1
MessageQueue#postSyncBarrier()
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
@UnsupportedAppUsage
@TestApi
public int postSyncBarrier() {
  	return postSyncBarrier(SystemClock.uptimeMillis());
}

private int postSyncBarrier(long when) {
    // Enqueue a new sync barrier token.
    // We don't need to wake the queue because the purpose of a barrier is to stall it.
    synchronized (this) {
        final int token = mNextBarrierToken++;
        final Message msg = Message.obtain();
        msg.markInUse();
      	//就是这里!!!初始化Message对象的时候，并没有给target赋值，因此 target==null
        msg.when = when;
        msg.arg1 = token;

        Message prev = null;
        Message p = mMessages;
        if (when != 0) {
          	//如果开启同步屏障的时间(假设记为T)T不为0，且当前的同步消息里有时间小于T，则prev也不为null
            while (p != null && p.when <= when) {
                prev = p;
                p = p.next;
            }
        }
      	//根据prev是不是为null，将 msg 按照时间顺序插入到 消息队列(链表)的合适位置
        if (prev != null) { // invariant: p == prev.next
            msg.next = p;
            prev.next = msg;
        } else {
            msg.next = p;
            mMessages = msg;
        }
        return token;
    }
}

可以看到，Message 对象初始化的时候并没有给target赋值，因此， target == null 的 来源就找到了。上面消 息的插入也做了相应的注释。这样，一条target == null 的消息就进入了消息队列。

那么，开启同步屏障后，所谓的异步消息又是如何被处理的呢? 如果对消息机制有所了解的话，应该知道消息的最终处理是在消息轮询器 Looper#loop() 中，而loop()循环中会

调用 MessageQueue#next() 从消息队列中进行取消息。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
Message next() {
    // Return here if the message loop has already quit and been disposed.
    // This can happen if the application tries to restart a looper after quit
    // which is not supported.
    final long ptr = mPtr;
    if (ptr == 0) {
      	return null;
    }

    int pendingIdleHandlerCount = -1; // -1 only during first iteration
    int nextPollTimeoutMillis = 0;
    for (;;) {
        if (nextPollTimeoutMillis != 0) {
          Binder.flushPendingCommands();
        }

        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;
          //关键!!! //如果target==null，那么它就是屏障，需要循环遍历，一直往后找到第一个异步的消息
          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) {
            //如果有消息需要处理，先判断时间有没有到，如果没到的话设置一下阻塞时间， //场景如常用的postDelay
            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;
              //链表操作，获取msg并且删除该节点
              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;
          }

          //....
        }

        //...
    }
}

从上面可以看出，当消息队列开启同步屏障的时候(即标识为msg.target == null)，消息机制在处理消息的时 候，优先处理异步消息。这样，同步屏障就起到了一种过滤和优先级的作用。

image-20210709211503392

如上图所示，在消息队列中有同步消息和异步消息(黄色部分)以及一道墙—-同步屏障(红色部分)。有了同步屏 障的存在，msg_2 和 msg_M 这两个异步消息可以被优先处理，而后面的 msg_3 等同步消息则不会被处理。那么这 些同步消息什么时候可以被处理呢?那就需要先移除这个同步屏障，即调用 removeSyncBarrier() 。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
@TestApi
public void removeSyncBarrier(int token) {
    // Remove a sync barrier token from the queue.
    // If the queue is no longer stalled by a barrier then wake it.
    synchronized (this) {
        Message prev = null;
        Message p = mMessages;
        while (p != null && (p.target != null || p.arg1 != token)) {
            prev = p;
            p = p.next;
        }
        if (p == null) {
            throw new IllegalStateException("The specified message queue synchronization "
                    + " barrier token has not been posted or has already been removed.");
        }
        final boolean needWake;
        if (prev != null) {
            prev.next = p.next;
            needWake = false;
        } else {
            mMessages = p.next;
            needWake = mMessages == null || mMessages.target != null;
        }
        p.recycleUnchecked();

        // If the loop is quitting then it is already awake.
        // We can assume mPtr != 0 when mQuitting is false.
        if (needWake && !mQuitting) {
            nativeWake(mPtr);
        }
    }
}

同步屏障的应用场景

似乎在日常的应用开发中，很少会用到同步屏障。那么，同步屏障在系统源码中有哪些使用场景呢?Android 系统中

的 UI 更新相关的消息即为异步消息，需要优先处理。
比如，在 View 更新时，draw、requestLayout、invalidate 等很多地方都调用了

ViewRootImpl#scheduleTraversals() ，如下:

1
2
3
4
5
6
7
8
9
10
11
12
void scheduleTraversals() {
    if (!mTraversalScheduled) {
        mTraversalScheduled = true;
      	//开启同步屏障
        mTraversalBarrier = mHandler.getLooper().getQueue().postSyncBarrier();
      	//发送异步消息
        mChoreographer.postCallback(
          Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null);
        notifyRendererOfFramePending();
        pokeDrawLockIfNeeded();
    }
}

postCallback() 最终走到了 ChoreographerpostCallbackDelayedInternal() :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
private void postCallbackDelayedInternal(int callbackType,
            Object action, Object token, long delayMillis) {
    if (DEBUG_FRAMES) {
        Log.d(TAG, "PostCallback: type=" + callbackType
              + ", action=" + action + ", token=" + token
              + ", delayMillis=" + delayMillis);
    }

    synchronized (mLock) {
        final long now = SystemClock.uptimeMillis();
        final long dueTime = now + delayMillis;
        mCallbackQueues[callbackType].addCallbackLocked(dueTime, action, token);

        if (dueTime <= now) {
          	scheduleFrameLocked(now);
        } else {
            Message msg = mHandler.obtainMessage(MSG_DO_SCHEDULE_CALLBACK, action);
            msg.arg1 = callbackType;
          	//异步消息
            msg.setAsynchronous(true);
            mHandler.sendMessageAtTime(msg, dueTime);
        }
    }
}

这里就开启了同步屏障，并发送异步消息，由于 UI 更新相关的消息是优先级最高的，这样系统就会优先处理这些异 步消息。

最后，当要移除同步屏障的时候需要调用 ViewRootImpl#unscheduleTraversals() 。

1
2
3
4
5
6
7
8
9
void unscheduleTraversals() {
    if (mTraversalScheduled) {
        mTraversalScheduled = false;
      	//移除同步屏障
        mHandler.getLooper().getQueue().removeSyncBarrier(mTraversalBarrier);
        mChoreographer.removeCallbacks(
          Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null);
    }
}

同步屏障的设置可以方便地处理那些优先级较高的异步消息。当我们调用
Handler.getLooper().getQueue().postSyncBarrier() 并设置消息的 setAsynchronous(true) 时，target 即 为 null ，也就开启了同步屏障。当在消息轮询器 Looper 在 loop() 中循环处理消息时，如若开启了同步屏障，会优 先处理其中的异步消息，而阻碍同步消息。

IdleHandler

Idlehandler源码

1
2
3
4
5
6
7
8
9
10
public static interface IdleHandler {
    /**
     * Called when the message queue has run out of messages and will now
     * wait for more.  Return true to keep your idle handler active, false
     * to have it removed.  This may be called if there are still messages
     * pending in the queue, but they are all scheduled to be dispatched
     * after the current time.
     */
    boolean queueIdle();
}

源码分析：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
Message next() {
    //.....
	//记录IdleHandler数量
    int pendingIdleHandlerCount = -1; // -1 only during first iteration
    int nextPollTimeoutMillis = 0;
    for (;;) {
        //......

            // If first time idle, then get the number of idlers to run.
            // Idle handles only run if the queue is empty or if the first message
            // in the queue (possibly a barrier) is due to be handled in the future.
            if (pendingIdleHandlerCount < 0
                && (mMessages == null || now < mMessages.when)) {
                pendingIdleHandlerCount = mIdleHandlers.size();
            }
            if (pendingIdleHandlerCount <= 0) {
                // No idle handlers to run.  Loop and wait some more.
                mBlocked = true;
                continue;
            }

            if (mPendingIdleHandlers == null) {
                mPendingIdleHandlers = new IdleHandler[Math.max(pendingIdleHandlerCount, 4)];
            }
            mPendingIdleHandlers = mIdleHandlers.toArray(mPendingIdleHandlers);
        }

        // Run the idle handlers.
        // We only ever reach this code block during the first iteration.
    	//循环执行IdleHandler的queueIdle方法
        for (int i = 0; i < pendingIdleHandlerCount; i++) {
            final IdleHandler idler = mPendingIdleHandlers[i];
            mPendingIdleHandlers[i] = null; // release the reference to the handler

            boolean keep = false;
            try {
                keep = idler.queueIdle();
            } catch (Throwable t) {
                Log.wtf(TAG, "IdleHandler threw exception", t);
            }

            if (!keep) {
                synchronized (this) {
                    mIdleHandlers.remove(idler);
                }
            }
        }

        // Reset the idle handler count to 0 so we do not run them again.
        pendingIdleHandlerCount = 0;

        // While calling an idle handler, a new message could have been delivered
        // so go back and look again for a pending message without waiting.
        nextPollTimeoutMillis = 0;
    }
}

结论: Android应用的运行都是靠着一条条Message入队、出队、执行实现，当应用主线程的消息队列空闲的时候（消息队列没有消息或下一次消息执行的时间还未到），就会尝试去执行IdleHandler集合。

其中：IdleHandler的queueIdle方法的返回值如果为false，那么IdleHandler执行完之后就会被移除，也就是说只会被执行一次；如果返回值为true，不会被移除且可以被执行多次。

案例1-执行GC

大家都知道，不能随便在主线程执行GC，否则很容易造成卡顿，但是我们可以在主线程空闲的时候去执行GC，这个时候就可以利用IdleHandler，Android源码ActivityThread中就有如下使用：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
void scheduleGcIdler() {
    if (!mGcIdlerScheduled) {
        mGcIdlerScheduled = true;
        Looper.myQueue().addIdleHandler(mGcIdler);
    }
    mH.removeMessages(H.GC_WHEN_IDLE);
}

final class GcIdler implements MessageQueue.IdleHandler {
    @Override
    public final boolean queueIdle() {
        doGcIfNeeded();
        purgePendingResources();
        return false;
    }
}

void doGcIfNeeded() {
    doGcIfNeeded("bg");
}
void doGcIfNeeded(String reason) {
    mGcIdlerScheduled = false;
    final long now = SystemClock.uptimeMillis();
    //Slog.i(TAG, "**** WE MIGHT WANT TO GC: then=" + Binder.getLastGcTime()
    //        + "m now=" + now);
    if ((BinderInternal.getLastGcTime()+MIN_TIME_BETWEEN_GCS) < now) {
        //Slog.i(TAG, "**** WE DO, WE DO WANT TO GC!");
        BinderInternal.forceGc(reason);
    }
}

这样既可以满足gc回收对象的需要，又不会影响主线程中其他任务的执行。

案例2-粗估Activity界面渲染时间

我们首先要明确界面渲染流程是发生在Activity的onResume生命周期，往主线程消息队列添加消息屏障（之后添加的Message只能执行异步类型的），然后发送界面渲染异步Message，等到界面渲染完成后才会从消息队列移除屏障消息，这个时候才能正常执行其他Message。

参考下滴滴的DoKit开源库：

1
2
3
4
5
6
7
8
9
10
11
12
@Override
protected void onResume(){
    super.onResume();
    final long start = System.currentTimeMillis(); 
    Looper.myQueue().addIdleHandler(new MessageQueue.IdleHandler(){
        @Override
        public boolean queueIdel(){
            Log.d(TAG, "onRender const:" + (System.currentTimeMillis() - start))
            return false;
        }
    })
}

我们现在onResume方法中记录界面开始渲染时间，添加一个IdleHandler，这个会在界面渲染相关Message执行完毕后再执行它，所以就可以简单的估算出界面渲染时长。

案例3-APP大图监测

常见的大图监控方法都是将ImageView替换成自定义ImageView，然后重写设置图片的方法，比如setImageBitmap()等等，在方法中计算下图片的宽高是否超过ImageView的宽高，是就弹出一个弹窗提醒开发者，一般在Debug环境下执行这种检测。

Debug环境下开启大图检测，一般为了避免影响主线程其他任务执行，都会添加一个IdleHandler等主线程空闲了再去执行大图检测：

案例4-延迟启动初始化任务

一般我们都在Application的onCreate方法中执行任务（比如第三方SDK）的初始化，可是如果执行的初始化任务过多就会增加启动耗时，给用户带来较差体验。

而且有的任务并不是一定就需要在Application的onCreate就必须要执行，可以延迟初始化，减少应用启动耗时，这个时候就可以把相关延迟任务添加到一个Idlehandler中去执行。

HandlerThread

HandlerThread是Thread的子类，严格意义上来说就是一个线程，只是它在自己的线程里面帮我们创建了Looper HandlerThread 存在的意义如下:

  1. 方便使用:a. 方便初始化，b，方便获取线程looper

2)保证了线程安全

我们一般在Thread里面 线程Looper进行初始化的代码里面，必须要对Looper.prepare(),同时要调用Loop。 loop();

1
2
3
4
5
@Override
public void run() {
    Looper.prepare();
    Looper.loop();
}

而我们要使用子线程中的Looper的方式是怎样的呢?看下面的代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Thread thread = new Thread(new Runnable() {
    Looper looper;
		@Override
    public void run() {
      	//  Log.d(TAG, "click2: " + Thread.currentThread().getName());
        Looper.prepare();
        looper =Looper.myLooper();
        Looper.loop();
		}
    public Looper getLooper() {
        return looper;
		} 
});
thread.start();
//这样获取looper有问题
Handler handler = new Handler(thread.getLooper());

1)在初始化子线程的handler的时候，我们无法将子线程的looper传值给Handler,解决办法有如下办法:

a. 可以将Handler的初始化放到 Thread里面进行

b. 可以创建一个独立的类继承Thread，然后，通过类的对象获取。

这两种办法都可以，但是，这个工作 HandlerThread帮我们完成了

2)依据多线程的工作原理，我们在上面的代码中，调用 thread.getLooper()的时候，此时的looper可能还没有初 始化，此时是不是可能会挂掉呢?

以上问题
HandlerThread 已经帮我们完美的解决了，这就是 handlerThread存在的必要性了。

我们再看 HandlerThread源码

1
2
3
4
5
6
7
8
9
10
11
public void run() {
    mTid = Process.myTid();
    Looper.prepare();
    synchronized (this) {
        mLooper = Looper.myLooper();
		notifyAll(); //此时唤醒其他等待的锁，但是 }
    Process.setThreadPriority(mPriority);
    onLooperPrepared();
    Looper.loop();
    mTid = -1;
}

它的优点就在于它的多线程操作，可以帮我们保证使用Thread的handler时一定是安全的。

IntentService

IntentService是Android中提供的后台服务类，我们在外部组件中通过Intent向IntentService发送请求命令，之后IntentService逐个执行命令队列里的命令，接收到首个命令时，IntentService就开始启动并开始一条后台线程执行首个命令，接着队列里的命令将会被顺序执行，最后执行完队列的所有命令后，服务也随即停止并被销毁。

与Service的不同

  1. Service中的程序仍然运行于主线程中，而在IntentService中的程序运行在我们的异步后台线程中。在接触到IntentService之前，我在项目中大多是自己写一个Service，在Service中自己写一个后台线程去处理相关事务，而这些工作Android其实早已经帮我们封装的很好。
  2. 在Service中当我的后台服务执行完毕之后需要在外部组件中调用stopService方法销毁服务，而IntentService并不需要，它会在工作执行完毕后自动销毁。

IntentService的用法

1.编写自己的Service类继承IntentService，并重写其中的onHandleIntent(Intent)方法，该方法是IntentService的一个抽象方法，用来处理我们通过startService方法开启的服务，传入参数Intent就是开启服务的Intent。在这里我重写了一个MyService类去处理后台事务，每一次调用对count加1，并打印log。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
package com.example.intentservicetest;

import android.app.IntentService;
import android.content.Intent;
import android.util.Log;

public class MyService extends IntentService {

    private static final String TAG = MyService.class.getSimpleName();

    private int count = 0;

    public MyService() {
        super(TAG);
        // TODO Auto-generated constructor stub
    }

    @Override
    protected void onHandleIntent(Intent intent) {
        // TODO Auto-generated method stub
        //在这里添加我们要执行的代码，Intent中可以保存我们所需的数据，
        //每一次通过Intent发送的命令将被顺序执行
        count ++;
        Log.w(TAG, "count::" + count);
    }
}

2.注册我们的服务：接下来在AndroidManifest文件中的Application标签下添加我们的服务。

1
<service android:name="com.example.intentservicetest.MyService" />

3.在外部组件中开启服务：在这里我们在Activity中利用Intent循环10次开启服务。

1
2
3
4
for (int i = 0; i < 10; i++) {
        Intent intent = new Intent(MainActivity.this, MyService.class);
        startService(intent);
}

4.结果输出：

img

可以看到在MyService中是按照顺序执行我们的请求命令的。

原理分析

1.生命周期函数：
IntentService同样是继承于Service的，它也拥有相同的生命周期函数;

  • onCreate：服务创建时调用；
  • onStartCommand(Intent, int, int)方法:在Service源码可以看到onStart方法是在该方法中被调用的。每次组件通过startService方法启动服务时调用一次，两个int型参数，一个是组标识符，一个是启动ID，组标识符用来表示当前Intent发送是一次重新发送还是一次从没成功过的发送。每次调用onStartCommand方法时启动ID都不同，启动ID也用来区分不同的命令;
  • onDestroy方法：在服务停止时调用。

2.onCreate方法：首先让我们看看IntentService源码中的onCreate方法，

1
2
3
4
5
6
7
8
9
10
@Override
public void onCreate() {
    super.onCreate();

    HandlerThread thread = new HandlerThread("IntentService[" + mName + "]");
    thread.start();

    mServiceLooper = thread.getLooper();
    mServiceHandler = new ServiceHandler(mServiceLooper);
}

可以看到：在IntentService的onCreate方法中开启了一个异步线程HandlerThread来处理我们的请求，并利用Looper和Handler来管理我们的请求命令队列。

3.如何停止服务
看到了onCreate方法我们就可以明白了，IntentService是如何开启异步线程以及如何管理命令队列的，那么我们之前曾提到：当后台服务处理结束后，我们并不需要再调用stopService方法销毁服务，IntentService会自动销毁，它是如何做到的呢？然我们看看ServiceHandler：

1
2
3
4
5
6
7
8
9
10
11
private final class ServiceHandler extends Handler {
    public ServiceHandler(Looper looper) {
      	super(looper);
    }

    @Override
    public void handleMessage(Message msg) {
        onHandleIntent((Intent)msg.obj);
        stopSelf(msg.arg1);
    }
}

在Handler中我们处理完每一个命令都会调用stopSelf(int)方法来停止服务：该方法需要来自onStartCommand方法中的启动ID，只有在接收到最新的启动ID时才会停止服务，就是说，我们的IntentService直到命令队列中的所有命令被执行完后才会停止服务。

setIntentRedelivery方法

在源码中我们可以发现，该方法改变了boolean变量mRedelivery的值，而mRedelivery得值关系到onStartCommand的返回变量

1
2
3
4
5
@Override
public int onStartCommand(Intent intent, int flags, int startId) {
    onStart(intent, startId);
    return mRedelivery ? START_REDELIVER_INTENT : START_NOT_STICKY;
}

可以看到，mRedelivery不同，会返回两个不同的标志START_REDELIVER_INTENT 和START_NOT_STICKY，那么他们有什么不同呢？
区别就在于如果系统在服务完成之前关闭它，则两种类型就表现出不同了：

  • START_NOT_STICKY型服务会直接被关闭，而START_REDELIVER_INTENT 型服务会在可用资源不再吃紧的时候尝试再次启动服务。
  • 由此我们可以发现，当我们的操作不是十分重要的时候，我们可以选择START_NOT_STICKY，这也是IntentService的默认选项，当我们认为操作十分重要时，则应该选择START_REDELIVER_INTENT 型服务。

non-sticky服务和sticky服务

non-sticky服务会在自己认为任务完成时停止，若一个Service为non-sticky服务则应该在onStartCommand方法中返回START_REDELIVER_INTENT或START_NOT_STICKY标志。
sticky服务会持续存在，直到外部组件调用Context.stopService方法。sticky服务返回标志位START_STICKY。

注意：IntentService不应该处理长时间运行的服务（如音乐播放），长时间运行的服务应该由sticky服务完成。

疑点解惑

主线程的Looper中的loop()循环为什么不会卡死主线程？

我们先看一段ActivityThread的代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
public static void main(String[] args) {

    //...
    
    Looper.prepareMainLooper();

    ActivityThread thread = new ActivityThread();
    thread.attach(false);

    if (sMainThreadHandler == null) {
        sMainThreadHandler = thread.getHandler();
    }

    if (false) {
        Looper.myLooper().setMessageLogging(new
                LogPrinter(Log.DEBUG, "ActivityThread"));
    }

    // End of event ActivityThreadMain.
    Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
    Looper.loop();

    throw new RuntimeException("Main thread loop unexpectedly exited");
}

看最后一行代码，抛出一个运行时异常“Main thread loop unexpectedly exited”(主线程异常退出)，也就是说如果loop循环执行完的话系统就判定为应用异常退出了。其实这里涉及到了线程/进程问题。

以下转载自知乎：https://www.zhihu.com/question/34652589

进程：每个app运行时前首先创建一个进程，该进程是由Zygote fork出来的，用于承载App上运行的各种Activity/Service等组件。进程对于上层应用来说是完全透明的，这也是google有意为之，让App程序都是运行在Android Runtime。大多数情况一个App就运行在一个进程中，除非在AndroidManifest.xml中配置Android:process属性，或通过native代码fork进程。

线程：线程对应用来说非常常见，比如每次new Thread().start都会创建一个新的线程。该线程与App所在进程之间资源共享，从Linux角度来说进程与线程除了是否共享资源外，并没有本质的区别，都是一个task_struct结构体，在CPU看来进程或线程无非就是一段可执行的代码，CPU采用CFS调度算法，保证每个task都尽可能公平的享有CPU时间片。
有了这么准备，再说说死循环问题：对于线程既然是一段可执行的代码，当可执行代码执行完成后，线程生命周期便该终止了，线程退出。而对于主线程，我们是绝不希望会被运行一段时间，自己就退出，那么如何保证能一直存活呢？简单做法就是可执行代码是能一直执行下去的，死循环便能保证不会被退出，例如，binder线程也是采用死循环的方法，通过循环方式不同与Binder驱动进行读写操作，当然并非简单地死循环，无消息时会休眠。但这里可能又引发了另一个问题，既然是死循环又如何去处理其他事务呢？通过创建新线程的方式。真正会卡死主线程的操作是在回调方法onCreate/onStart/onResume等操作时间过长，会导致掉帧，甚至发生ANR，looper.loop本身不会导致应用卡死。

另外，ActivityThread实际上并非线程，不像HandlerThread类，ActivityThread并没有真正继承Thread类，只是往往运行在主线程，给人以线程的感觉，其实承载ActivityThread的主线程就是由Zygote fork而创建的进程。主线程的死循环一直运行是不是特别消耗CPU资源呢？ 其实不然，这里就涉及到Linux pipe/epoll机制，简单说就是在主线程的MessageQueue没有消息时，便阻塞在loop的queue.next()中的nativePollOnce()方法里，此时主线程会释放CPU资源进入休眠状态，直到下个消息到达或者有事务发生，通过往pipe管道写端写入数据来唤醒主线程工作。这里采用的epoll机制，是一种IO多路复用机制，可以同时监控多个描述符，当某个描述符就绪(读或写就绪)，则立刻通知相应程序进行读或写操作，本质同步I/O，即读写是阻塞的。 所以说，主线程大多数时候都是处于休眠状态，并不会消耗大量CPU资源。

Activity的生命周期是怎么实现在死循环体外能够执行起来的？
ActivityThread的内部类H继承于Handler，通过handler消息机制，简单说Handler机制用于同一个进程的线程间通信。Activity的生命周期都是依靠主线程的Looper.loop，当收到不同Message时则采用相应措施：在H.handleMessage(msg)方法中，根据接收到不同的msg，执行相应的生命周期。 比如收到msg=H.LAUNCH_ACTIVITY，则调用ActivityThread.handleLaunchActivity()方法，最终会通过反射机制，创建Activity实例，然后再执行Activity.onCreate()等方法； 再比如收到msg=H.PAUSE_ACTIVITY，则调用ActivityThread.handlePauseActivity()方法，最终会执行Activity.onPause()等方法。 上述过程，我只挑核心逻辑讲，真正该过程远比这复杂。

归结如下：

A. Android应用程序的消息处理机制由消息循环、消息发送和消息处理三个部分组成的。
B. Android应用程序的主线程在进入消息循环过程前，会在内部创建一个Linux管道（Pipe），这个管道的作用是使得Android应用程序主线程在消息队列为空时可以进入空闲等待状态，并且使得当应用程序的消息队列有消息需要处理时唤醒应用程序的主线程。
C. Android应用程序的主线程进入空闲等待状态的方式实际上就是在管道的读端等待管道中有新的内容可读，具体来说就是是通过Linux系统的Epoll机制中的epoll_wait函数进行的。
D. 当往Android应用程序的消息队列中加入新的消息时，会同时往管道中的写端写入内容，通过这种方式就可以唤醒正在等待消息到来的应用程序主线程。
E. 当应用程序主线程在进入空闲等待前，会认为当前线程处理空闲状态，于是就会调用那些已经注册了的IdleHandler接口，使得应用程序有机会在空闲的时候处理一些事情。

结论：阻塞是有的，但是不会卡住主要原因有2个

1，epoll模型当没有消息的时候会epoll.wait，等待句柄写的时候再唤醒，这个时候其实是阻塞的。
2，所有的ui操作都通过handler来发消息操作。比如屏幕刷新16ms一个消息，你的各种点击事件，所以就会有句柄写操作，唤醒上文的wait操作，所以不会被卡死了。

所以当loop真的执行完了说明应用异常退出了。