Android Framework 面试集合——Handler篇（下）

5.分发消息

消息分发是在loop()中完成的，来看看loop()这个重要的方法

Looper.loop()：精简了巨量源码，详细的可以点击左侧方法名
- Message msg = queue.next()：遍历消息
- msg.target.dispatchMessage(msg)：分发消息
- msg.recycleUnchecked()：消息回收，进入消息池

Looper.java
...
public static void loop() {
    final Looper me = myLooper();
    ...
    final MessageQueue queue = me.mQueue;
    ...
    for (;;) {
        //遍历消息池,获取下一可用消息
        Message msg = queue.next(); // might block
        ...
        try {
            //分发消息
            msg.target.dispatchMessage(msg);
            ...
        } catch (Exception exception) {
            ...
        } finally {
            ...
        }
        ....
        //回收消息,进图消息池
        msg.recycleUnchecked();
    }
}
...

5.1.遍历消息

遍历消息的关键方法肯定是下面这个

Message msg = queue.next()：Message类中的next()方法；当然这必须要配合外层for（无限循环）来使用，才能遍历消息队列

来看看这个Message中的next()方法吧

next()：精简了一些源码，完整的点击左侧方法名

MessageQueue.java
...
Message next() {
    final long ptr = mPtr;
    ...
 
    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;
            // 这是关于同步屏障（SyncBarrier）的知识，放在同步屏障栏目讲
            if (msg != null && msg.target == null) {
                do {
                    prevMsg = msg;
                    msg = msg.next;
                } while (msg != null && !msg.isAsynchronous());
            }
             
            if (msg != null) {
                if (now < msg.when) {
                    //每个消息处理有耗时时间，之间存在一个时间间隔（when是将要执行的时间点）。
                    //如果当前时刻还没到执行时刻（when），计算时间差值，传入nativePollOnce定义唤醒阻塞的时间
                    nextPollTimeoutMillis = (int) Math.min(msg.when - now, Integer.MAX_VALUE);
                } else {
                    mBlocked = false;
                    //该操作是把异步消息单独从消息队列里面提出来,然后返回,返回之后,该异步消息就从消息队列里面剔除了
                    //mMessage仍处于未分发的同步消息位置
                    if (prevMsg != null) {
                        prevMsg.next = msg.next;
                    } else {
                        mMessages = msg.next;
                    }
                    msg.next = null;
                    if (DEBUG) Log.v(TAG, "Returning message: " + msg);
                    msg.markInUse();
                    //返回符合条件的Message
                    return msg;
                }
            } else {
                // No more messages.
                nextPollTimeoutMillis = -1;
            }
 
            //这是处理调用IdleHandler的操作,有几个条件
            //1、当前消息队列为空(mMessages == null)
            //2、已经到了可以分发下一消息的时刻（now < mMessages.when）
            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);
        }
 
        
        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;
    }
}

总结下源码里面表达的意思

1.next()内部是个死循环，你可能会疑惑，只是拿下一节点的消息，为啥要死循环？

为了执行延时消息以及同步屏障等等，这个死循环是必要的

2.nativePollOnce阻塞方法：到了超时时间(nextPollTimeoutMillis)或者通过唤醒方式(nativeWake)，会解除阻塞状态

nextPollTimeoutMillis大于等于零，会规定在此段时间内休眠，然后唤醒
消息队列为空时，nextPollTimeoutMillis为-1，进入阻塞；重新有消息进入队列，插入头结点的时候会触发nativeWake唤醒方法

3.如果 msg.target == null为零，会进入同步屏障状态

会将msg消息死循环到末尾节点，除非碰到异步方法
如果碰到同步屏障消息，理论上会一直死循环上面操作，并不会返回消息，除非，同步屏障消息被移除消息队列

4.当前时刻和返回消息的when判定

消息when代表的时刻：一般都是发送消息的时刻，如果是延时消息，就是发送时刻+延时时间
当前时刻小于返回消息的when：进入阻塞，计算时间差，给nativePollOnce设置超时时间，超时时间一到，解除阻塞，重新循环取消息
当前时刻大于返回消息的when：获取可用消息返回

5.消息返回后，会将mMessage赋值为返回消息的下一节点（只针对不涉及同步屏障的同步消息）

5.2.分发消息

分发消息主要的代码是： msg.target.dispatchMessage(msg);

也就是说这是Handler类中的dispatchMessage(msg)方法

dispatchMessage(msg)

public void dispatchMessage(@NonNull Message msg) {
    if (msg.callback != null) {
        handleCallback(msg);
    } else {
        if (mCallback != null) {
            if (mCallback.handleMessage(msg)) {
                return;
            }
        }
        handleMessage(msg);
    }
}

可以看到，这里的代码，在收发消息栏目的接受消息那块已经说明过了，这里就无须重复了

5.3.消息池

msg.recycleUnchecked()是处理完成分发的消息，完成分发的消息并不会被回收掉，而是会进入消息池，等待被复用

recycleUnchecked()：回收消息的代码还是蛮简单的，来分析下
- 首先会将当前已经分发处理的消息，相关属性全部重置，flags也标志可用
- 消息池的头结点会赋值为当前回收消息的下一节点，当前消息成为消息池头结点
- 简言之：回收消息插入消息池，当做头结点
- 需要注意的是：消息池有最大的容量，如果消息池大于等于默认设置的最大容量，将不再接受回收消息入池
  - 默认最大容量为50： MAX_POOL_SIZE = 50

Message.java
...
void recycleUnchecked() {
    // Mark the message as in use while it remains in the recycled object pool.
    // Clear out all other details.
    flags = FLAG_IN_USE;
    what = 0;
    arg1 = 0;
    arg2 = 0;
    obj = null;
    replyTo = null;
    sendingUid = UID_NONE;
    workSourceUid = UID_NONE;
    when = 0;
    target = null;
    callback = null;
    data = null;
 
    synchronized (sPoolSync) {
        if (sPoolSize < MAX_POOL_SIZE) {
            next = sPool;
            sPool = this;
            sPoolSize++;
        }
    }
}

来看下消息池回收消息图示

既然有将已使用的消息回收到消息池的操作，那肯定有获取消息池里面消息的方法了

obtain()：代码很少，来看看
- 如果消息池不为空：直接取消息池的头结点，被取走头结点的下一节点成为消息池的头结点
- 如果消息池为空：直接返回新的Message实例

Message.java
...
public static Message obtain() {
    synchronized (sPoolSync) {
        if (sPool != null) {
            Message m = sPool;
            sPool = m.next;
            m.next = null;
            m.flags = 0; // clear in-use flag
            sPoolSize--;
            return m;
        }
    }
    return new Message();
}

来看下从消息池取一个消息的图示

6.IdIeHandler

在MessageQueue类中的next方法里，可以发现有关于对IdleHandler的处理，大家可千万别以为它是什么Handler特殊形式之类，这玩意就是一个interface，里面抽象了一个方法，结构非常的简单

next()：精简了大量源码，只保留IdleHandler处理的相关逻辑；完整的点击左侧方法名

MessageQueue.java
...
Message next() {
    final long ptr = mPtr;
    ...
 
    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;
            ...
            //这是处理调用IdleHandler的操作,有几个条件
            //1、当前消息队列为空(mMessages == null)
            //2、未到到了可以分发下一消息的时刻（now < mMessages.when）
            //3、pendingIdleHandlerCount < 0表明：只会在此for循环里执行一次处理IdleHandler操作
            if (pendingIdleHandlerCount < 0
                && (mMessages == null || now < mMessages.when)) {
                pendingIdleHandlerCount = mIdleHandlers.size();
            }
            if (pendingIdleHandlerCount <= 0) {
                mBlocked = true;
                continue;
            }
 
            if (mPendingIdleHandlers == null) {
                mPendingIdleHandlers = new IdleHandler[Math.max(pendingIdleHandlerCount, 4)];
            }
            mPendingIdleHandlers = mIdleHandlers.toArray(mPendingIdleHandlers);
        }
 
        
        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);
                }
            }
        }
 
        pendingIdleHandlerCount = 0;
        nextPollTimeoutMillis = 0;
    }
}

实际上从上面的代码里面，可以分析出很多信息

IdleHandler相关信息

调用条件

当前消息队列为空(mMessages == null) 或未到分发返回消息的时刻
在每次获取可用消息的死循环中，IdleHandler只会被处理一次：处理一次pendingIdleHandlerCount为0，其循环不可再被执行

实现了IdleHandler中的queueIdle方法

返回false，执行后，IdleHandler将会从IdleHandler列表中移除，只能执行一次：默认false
返回true，每次分发返回消息的时候，都有机会被执行：处于保活状态

IdleHandler代码

MessageQueue.java
...
/**
 * Callback interface for discovering when a thread is going to block
 * waiting for more messages.
 */
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();
}
 
public void addIdleHandler(@NonNull IdleHandler handler) {
    if (handler == null) {
        throw new NullPointerException("Can't add a null IdleHandler");
    }
    synchronized (this) {
        mIdleHandlers.add(handler);
    }
}
 
public void removeIdleHandler(@NonNull IdleHandler handler) {
    synchronized (this) {
        mIdleHandlers.remove(handler);
    }
}

怎么使用IdleHandler呢？

这里简单写下用法，可以看看，留个印象

public class MainActivity extends AppCompatActivity {
    private TextView msgTv;
    private Handler mHandler = new Handler();
 
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        msgTv = findViewById(R.id.tv_msg);
        //添加IdleHandler实现类
        mHandler.getLooper().getQueue().addIdleHandler(new InfoIdleHandler("我是IdleHandler"));
        mHandler.getLooper().getQueue().addIdleHandler(new InfoIdleHandler("我是大帅比"));
 
        //消息收发一体
        new Thread(new Runnable() {
            @Override public void run() {
                String info = "第一种方式";
                mHandler.post(new Runnable() {
                    @Override public void run() {
                        msgTv.setText(info);
                    }
                });
            }
        }).start();
    }
 
    //实现IdleHandler类
    class InfoIdleHandler implements MessageQueue.IdleHandler {
        private String msg;
 
        InfoIdleHandler(String msg) {
            this.msg = msg;
        }
 
        @Override
        public boolean queueIdle() {
            msgTv.setText(msg);
            return false;
        }
    }
}

总结

通俗的讲：当所有消息处理完了或者你发送了延迟消息，在这俩种空闲时间里，都满足执行IdleHandler的条件

这地方需要说明下，如果延迟消息时间设置过短的；IdleHandler可能会在发送消息后执行，毕竟运行到next这步也需要一点时间，延迟时间设置长点，你就可以很明显得发现，IdleHandler在延迟的空隙间执行了！

从其源码上，可以看出来，IdlerHandler是在消息分发的空闲时刻，专门用来处理相关事物的

7.同步屏障

来到最复杂的模块了
在理解同步屏障的概念前，我们需要先搞懂几个前置知识

7.1.前置知识

7.1.1.同步和异步消息

什么是同步消息？什么是异步消息？

讲真的，异步消息和同步消息界定，完成是通过一个方法去界定的
isAsynchronous()：来分析下
- FLAG_ASYNCHRONOUS = 1 << 1：所以FLAG_ASYNCHRONOUS为2
- 同步消息：flags为0或者1的时候，isAsynchronous返回false，此时该消息标定为同步消息
  - flags为0，1：同步消息
- 异步消息：理论上只要按照位操作，右往左，第二位为1的数，isAsynchronous返回true；但是，Message里面基本只使用了：0，1，2，可得出结论
  - flags为2：异步消息

public boolean isAsynchronous() {
    return (flags & FLAG_ASYNCHRONOUS) != 0;
}

setAsynchronous(boo;eam asumc)：这个影响flags的值

因为flags是int类型，没有赋初值，故其初始值为0
setAsynchronous传入true的话，或等于操作，会将flags数值改成2

msg.setAsynchronous(true);
 
public void setAsynchronous(boolean async) {
    if (async) {
        flags |= FLAG_ASYNCHRONOUS;
    } else {
        flags &= ~FLAG_ASYNCHRONOUS;
    }
}

怎么生成异步消息？so easy

Message msg = Message.obtain();
//设置异步消息标记
msg.setAsynchronous(true);

一般来说：默认消息不做设置，flags都为0，故默认为同步消息，下面栏目将分析下setAsynchronous在何处使用了

7.1.2.默认消息类型

我们正常情况下，很少会使用setAsynchronous方法的，那么在不使用该方法的时候，消息的默认类型是什么呢？

在生成消息，然后发送消息的时候，都会经过下述方法
enqueueMessage：正常发送消息（post、延迟和非延迟之类），都会经过此方法
- 因为发送的所有消息都会经过enqueueMessage方法，然后加入消息队列，可以看见所有的消息都被处理过
- msg.target = this
  - 这地方给Message类的target赋值了！
  - 说明：只要使用post或sendMessage之类发送消息，其消息就绝不可能是同步屏障消息！
- 关于同步异步，可以看见和mAsynchronous息息相关
  - 只要mAsynchronous为true的话，我们的消息都会异步消息
  - 只要mAsynchronous为false的话，我们的消息都会同步消息

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

mAsynchronous在哪设置的呢？这是在构造方法里面给mAsynchronous赋值了

public Handler(@Nullable 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 " + Thread.currentThread()
            + " that has not called Looper.prepare()");
    }
    mQueue = mLooper.mQueue;
    mCallback = callback;
    mAsynchronous = async;
}
 
public Handler(@NonNull Looper looper, @Nullable Callback callback, boolean async) {
    mLooper = looper;
    mQueue = looper.mQueue;
    mCallback = callback;
    mAsynchronous = async;
}

看看一些通用的构造方法

public Handler() {
    this(null, false);
}
 
public Handler(@NonNull Looper looper) {
    this(looper, null, false);
}
 
public Handler(@NonNull Looper looper, @Nullable Callback callback) {
    this(looper, callback, false);
}

总结下

这下清楚了！如果不做特殊设置的话：默认消息都是同步消息
默认消息都会给其target变量赋值：默认消息都不是同步屏障消息

7.1.3.生成同步屏障消息

在next方法中发现，target为null的消息被称为同步屏障消息，那他为啥叫同步屏障消息呢？

postSyncBarrier(long when)
- sync：同步 barrier：屏障，障碍物 ---> 同步屏障
- 同步屏障实际挺能代表其含义的，它能屏蔽消息队列中后续所有的同步方法分发

MessageQueue.java
...
@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();
        msg.when = when;
        msg.arg1 = token;
 
        Message prev = null;
        Message p = mMessages;
        if (when != 0) {
            while (p != null && p.when <= when) {
                prev = p;
                p = p.next;
            }
        }
        if (prev != null) { // invariant: p == prev.next
            msg.next = p;
            prev.next = msg;
        } else {
            msg.next = p;
            mMessages = msg;
        }
        return token;
    }
}

mMessage这个变量，表明是将要被处理的消息，将要被返回的消息，也可以认为，他是未处理消息队列的头结点消息

关于同步屏障消息

从消息池取一个可用消息
这地方有个很有意思的循环操作，这while操作的，会将mMessages头结点赋值给p变量，将p节点移到当前时刻消息的下一节点
头结点（mMessage）是否为空
- 不为空：因为上面的循环操作，会让p节点的消息，肯定是刚好大于当前时间刻，p节点的上一节点消息为当前时刻过去时刻的消息，此时！咱们的同步屏障消息msg，就插在这俩者之间！
- 为空：成为头结点
  同步屏障消息是直接插到消息队列，他没有设置target属性且不经过enqueueMessage方法，故其target属性为null

总结下：

同步屏障消息插入消息队列的规律，和上面正常发送消息插入基本是一致的；如果消息队列有延时消息，延时消息的时刻大于目前的时刻，同步消息会在这些延时消息之前。

OK，同步屏障消息插入，基本可以理解为：正常的非延时消息插入消息队列！

同步屏障消息插入消息队列流程图 \

7.2.同步屏障流程

next()：精简了大量源码码，只保留和同步屏障有关的代码；完整的点击左侧方法名

MessageQueue.java
...
Message next() {
    final long ptr = mPtr;
    ...
 
    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;
            // 这是关于同步屏障（SyncBarrier）的逻辑块
            if (msg != null && msg.target == null) {
                do {
                    prevMsg = msg;
                    msg = msg.next;
                } while (msg != null && !msg.isAsynchronous());
            }
             
            if (msg != null) {
                if (now < msg.when) {
                    //每个消息处理有耗时时间，之间存在一个时间间隔（when是将要执行的时间点）。
                    //如果当前时刻还没到执行时刻（when），计算时间差值，传入nativePollOnce定义唤醒阻塞的时间
                    nextPollTimeoutMillis = (int) Math.min(msg.when - now, Integer.MAX_VALUE);
                } else {
                    mBlocked = false;
                    //该操作是把异步消息单独从消息队列里面提出来,然后返回,返回之后,该异步消息就从消息队列里面剔除了
                    //mMessage仍处于未分发的同步消息位置
                    if (prevMsg != null) {
                        prevMsg.next = msg.next;
                    } else {
                        mMessages = msg.next;
                    }
                    msg.next = null;
                    if (DEBUG) Log.v(TAG, "Returning message: " + msg);
                    msg.markInUse();
                    //返回符合条件的Message
                    return msg;
                }
            } else {
                // No more messages.
                nextPollTimeoutMillis = -1;
            }
            ...
        }
        ...
    }
}

去掉大量我们无需关注的代码，发现这也没啥嘛，就是一堆if eles for之类的，来分析分析

1.Message msg = mMessages：这步赋值是非常重要的，表示即使我们对msg一顿操作，mMessage还是保留消息队列头结点消息的位置 2.msg.target == null：遇到同步屏障消息

首先是一个while循环，内部逻辑，不断将msg节点的位置后移
结束while的俩个条件
- msg移到尾结点，也就是移到了消息队列尾结点，将自身赋值为null（尾结点的next）
- 遇上标记为异步的消息，放行该消息进行后续分发

3.分析下，俩个放行条件产生的不同影响

消息队列不含异步消息
- 当我们在同步屏障逻辑里面，将msg自身移到尾结点，并赋值为null（尾结点的next）
- msg为null，是无法进行后续分发操作，会重新进行循环流程
- mMessage头结点重新将自身位置赋值给msg，继续上述的重复过程
- 可以发现，上述逻辑确实起到了同步屏障的作用，屏蔽了其所有后续同步消息的分发；只有移除消息队列中的该条同步屏障消息，才能继续进行同步消息的分发
消息队列含有异步消息
- 消息队列中如果有异步消息，同步屏障的逻辑会放行异步消息
- 同步屏障里面堆prevMsg赋值了！请记住在整个方法里面，只有同步屏障逻辑里面堆prevMsg赋值了！这个参数为null与否，对消息队列节点影响很大
- prevMsg为空：会直接将msg的next赋值给mMessage；说明分发完消息后，会直接移除头结点，将头结点的下一节点赋值为头结点
- prevMsg不为空：不会对mMessage投节点操作；会将分发消息的上一节点的下一节点位置，换成分发节点的下一节点，有点绕
- 通过上面分析，可知；异步消息分发完后，会将其直接从消息队列中移除，头结点位置不变

文字写了一大堆，我也是尽可能详细描述，同步屏障逻辑代码块会产生的影响，整个图，加深下印象！

8.同步屏障作用

那么这个同步屏障有什么作用呢？

有个急需的问题，就是什么地方用到了postSyncBarrier(long when)方法，这个方法对外是不暴露的，只有内部包能够调用

搜索了整个源码包，发现只有几个地方使用了它，剔除测试类，MessageQueue类，有作用的就是：ViewRootImpl类和Device类

8.1.Device类

pauseEvents()：Device内部涉及的是打开设备的时候，会添加一个同步屏障消息，屏蔽后续所有的同步消息处理
- pauseEvents()是Device类中私有内部类DeviceHandler的方法
  - 这说明，我们无法调用这个方法；事实上，我们连Device类都无法调用，Device属于被隐藏的类，和他同一目录的还有Event和Hid，这些类系统都不想对外暴露
  - 这就很鸡贼了，说明插入同步屏障的消息的方法，系统确实不想对外暴露；当然不包括非常规方法：反射
同步屏障添加：开机时，添加同步屏障

Device.java
...
private class DeviceHandler extends Handler {
    ...
    @Override
    public void handleMessage(Message msg) {
        switch (msg.what) {
            case MSG_OPEN_DEVICE:
                ...
                pauseEvents();
                break;
            ...
        }
    }
 
    public void pauseEvents() {
        mBarrierToken = getLooper().myQueue().postSyncBarrier();
    }
 
    public void resumeEvents() {
        getLooper().myQueue().removeSyncBarrier(mBarrierToken);
        mBarrierToken = 0;
    }
}

同步屏障移除：完成开机后，移除同步屏障

Device.java
...
private class DeviceHandler extends Handler {
    ...
    public void pauseEvents() {
        mBarrierToken = getLooper().myQueue().postSyncBarrier();
    }
 
    public void resumeEvents() {
        getLooper().myQueue().removeSyncBarrier(mBarrierToken);
        mBarrierToken = 0;
    }
}
 
private class DeviceCallback {
    public void onDeviceOpen() {
        mHandler.resumeEvents();
    }
    ....
}

Device中使用同步屏障整体过程比较简单，这里简单描述下

打开设备时，会发送一个同步屏障消息，屏蔽后续所有同步消息
完成开机后，移除同步屏障消息
总结：很明显，这是尽量的提升打开设备速度，不被其它次等重要的事件干扰

8.2.ViewRootImpl类

scheduleTraversals()：非常重要的方法

ViewRootImpl.java
...
void scheduleTraversals() {
    if (!mTraversalScheduled) {
        mTraversalScheduled = true;
        mTraversalBarrier = mHandler.getLooper().getQueue().postSyncBarrier();
        mChoreographer.postCallback(
            Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null);
        notifyRendererOfFramePending();
        pokeDrawLockIfNeeded();
    }
}

关于上面的方法的分析，整体流程比较麻烦，涉及到整个刷新过程的分析,给出了一个非常重要的结论.

我们调用View的requestLayout或者invalidate时，最终都会触发ViewRootImp执行scheduleTraversals()方法。这个方法中ViewRootImp会通过Choreographer来注册个接收Vsync的监听，当接收到系统体层发送来的Vsync后我们就执行doTraversal()来重新绘制界面。通过上面的分析我们调用invalidate等刷新操作时，系统并不会立即刷新界面，而是等到Vsync消息后才会刷新页面。

我们知道了界面刷新（requestLayout或者invalidate）的过程一定会触发scheduleTraversals()方法，这说明会添加同步屏障消息，那肯定有移除同步屏障消息的步骤，这个步骤很有可能存在doTraversal()方法中，来看下这个方法

doTraversal()：removeSyncBarrier！我giao！果然在这地方！
- 这地方做了俩件事：移除同步屏障（removeSyncBarrier）、绘制界面（performTraversals）

void doTraversal() {
    if (mTraversalScheduled) {
        mTraversalScheduled = false;
        mHandler.getLooper().getQueue().removeSyncBarrier(mTraversalBarrier);
 
        if (mProfile) {
            Debug.startMethodTracing("ViewAncestor");
        }
 
        performTraversals();
 
        if (mProfile) {
            Debug.stopMethodTracing();
            mProfile = false;
        }
    }
}

doTraversal()是怎么被调用呢？调用：mTraversalRunnable在scheduleTraversals()中使用了

final TraversalRunnable mTraversalRunnable = new TraversalRunnable();
 
void scheduleTraversals() {
    if (!mTraversalScheduled) {
        ...
        mChoreographer.postCallback(
            Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null);
      ...
    }
}
 
final class TraversalRunnable implements Runnable {
    @Override
    public void run() {
        doTraversal();
    }
}

postCallback是Choreographer类中方法，该类涉及巨多的消息传递，而且都是使用了异步消息setAsynchronous(true)，这些都是和界面刷新相关，所以都是优先处理，完整的流程可以看上面贴的文章

postCallback的核心就是让DisplayEventReceiver注册了个Vsync的通知，后期收到送来的Vsync后，我们就执行doTraversal()来重新绘制界面

8.3.总结

通过上面的对ViewRootImpl说明，需要来总结下同步屏障对界面绘制过程的影响

详细版总结

调用View的requestLayout或者invalidate时，最终都会执行scheduleTraversals()，此时会在主线程消息队列中插入一个同步屏障消息（停止所有同步消息分发），会将mTraversalRunnable添加到mCallbackQueues中，并注册接收Vsync的监听，当接受到Vsync通知后，会发送一个异步消息，触发遍历执行mCallbackQueues的方法，这会执行我们添加的回调mTraversalRunnable，从而执行doTraversal()，此时会移除主线程消息队列中同步屏障消息，最后执行绘制操作

通俗版总结

调用requestLayout或者invalidate时，会在主线程消息队列中插入一个同步屏障消息，同时注册接收Vsync的监听；当接受到Vsync通知，会发送一个异步消息，执行真正的绘制事件：此时会移除消息队列中的同步屏障消息，然后才会执行绘制操作

下面画了个流转图示

9.总结

9.1.消息插入对比

有个很重要的事情，我们再来看下：正常发送消息和同步屏障消息插入消息队列直接的区别，见下图

取消息：关于取消息，都是取的mMessage，可以理解为，取消息队列的头结点
非延时消息在同步屏障消息之前发送，都会排在同步屏障消息之前
延时消息，如果时刻大于发送同步屏障消息的时刻，会排在同步屏障消息之后

9.2.Vsync

关于Vsync

Vsync 信号一般是由硬件产生的，现在手机一般为60hz~120hz，每秒刷新60到120次，一个时间片算一帧
每个 Vsync 信号之间的时间就是一帧的时间段

来看下执行同步消息时间片：这图真吉儿不好画，吐血

由上图可知：某种极端情况，你所发送的消息，在分发的时候，可能存在一帧的延时

9.3.总结

相关总结

同步屏障能确保消息队列中的异步消息，会被优先执行
鉴于正常消息和同步屏障消息插入消息队列的区别：同步屏障能够及时的屏障队列中的同步消息
某些极端场景：发送的消息，在分发的时候，可能会存一帧延时
- 极端场景：Vsync信号到来之后，立马执行了RequestLayout等操作
同步屏障能确保在UI刷新中：Vsync信号到来后，能够立马执行真正的绘制页面操作

同步消息和异步消息使用建议

在正常的情况，肯定不建议使用异步消息，此处假设一个场景：因为某种需求，你发送了大量的异步消息，由于消息进入消息队列的特殊性，系统发送的异步消息，也只能乖乖的排在你的异步消息后面，假设你的异步消息占据了大量的时间片，甚至占用了几帧，导致系统UI刷新的异步消息无法被及时执行，此时很有可能发生掉帧

当然，如果你能看明白这个同步屏障栏目所写的东西，相信什么时候设置消息为异步，心中肯定有数

正常情况，请继续使用同步消息
特殊情况，需要自己发送的消息被优先处理：可以使用异步消息

Handler、Message、MessageQueue、Looper;

以下为零散的记录，最后有总结； 内存泄露的本质：

长生命周期对象持有短生命周期对象，导致短生命周期对象销毁不掉；

持有链：

线程>>Looper>>MessageQueue>>Message>>Handler>>Activity;

Message对象的变量target为发送消息的Handler; MessageQueue 队列里放Message； Looper对象里实例化MessageQueue； 一个线程绑定一个Looper；

为什么要有handler？主要目的是要解决线程切换问题，handler里的Message机制解决了线程间通信;

为什么有队列MessageQueue？ MessageQueue是一个单向链表，next()调用nativePollOnce->lunx的epoll_wait()等待实现阻塞时队列；

在单线程中一次只能执行一句代码
假如发送了一个大消息A
处理这个大的消息A
但是处理的太慢了
从而导致其他后续要发送的消息发不出去
因为单线程阻塞到了第3步处理那个消息A的地方

队列的出现解决了"处理消息"阻塞到"发送消息"的问题；

队列是生产者消费者模式；

而要使用队列需要至少两个线程、和一个死循环；

一个线程负责生产消息；
一个线程消费消息；
死循环需要取出放入队列里的消息；

为什么有Looper？

为了循环取出队列里的消息；

一个线程有几个Looper,为什么不会有多个?

一个线程一个Looper,放在ThreadLocalMap中；

假如Looper对象由Handler创建，每创建一个Handler就有一个Looper,那么调用Looper.loop()时开启死循环；在外边调用Looper的地方就会阻塞；

主线程中Looper的死循环为什么没有导致系统卡死？

我们的UI线程主线程其实是ActivityThread线程，而一个线程只会有一个Looper;
ActivityThread.java的main函数是一个APP进程的入口，如果不卡死，main函数执行完则整个应用进程就会退出；
android是以事件为驱动的操作系统，当有事件来时，就去做对应的处理，没有时就显示静态界面；

获取当前线程：Thread.currentThread();

ThreadLocalMap:类似于HashMap;

每个Thread对象都有一个对应的ThreadLocalMap；

在Looper.prepare()时，存入Looper，存Looper时ThreadLocalMap的key为ThreadLocal，value为Looper；

内存抖动根本的解决方式是复用；

handler.obtainMessage()；

从Looper的回收池中取Message；
Message是一个单向链表，Message不是一个单纯的对象，而是一个链表集合
最大长度固定50个

Linux函数: epoll_create:App注册进红黑树中，拿到一个事件fd的值； epoll_ctl：注册事件类型，监听fd是否改变（Linux中事件都会被写入文件中，如触摸屏幕事件会写入到：dev/input/event0文件中），fd有改变时唤醒epoll_wait； epoll_wait：有事件时就分发，没事件就阻塞

总结： handler如何做的线程切换的？ 首先Handler的使用步骤：

调用Looper.prepare();
创建Handler对象；
调用Looper.Loop()方法。
线程中发送消息。

在第一步时，创建一个Looper，并放到当前线程的变量threadLocals中；threadLocals是一个map，key为ThreadLocal对象本身，value为Looper;在Looper.loop()时取出；

image.png

第二步,用户在当前线程（可能是子线程）创建Handler对象；

第三步，Looper.loop()一直在死循环，Looper.loop()这句代码下面的代码是不会被调用的，调用Looper.loop()函数时，先从当前线程的map变量中取出Looper,再从Looper中拿到队列MessageQueue，for循环中不断从队列中取出消息；

image.png

第四步，在其他线程调用handelr发送消息时，Message里有个target,就是发送消息的handler;

在Looper.loop()时，队列中取到消息时，调用msg.target.dispatchMessage(msg)；其实就是handler对象.dispatchMessage(msg);

所以不论在哪个线程调用发送消息，都会调用到handler自己分发消息；而handler所处的线程是创建时的“当前线程”，所以处理时也就回到了“当前线程”；实现了线程切换，和线程通信；

Looper的死循环为什么不会让主线程卡死（或ANR）？ 简单版：

我们的UI线程主线程其实是ActivityThread所在的线程，而一个线程只会有一个Looper;
ActivityThread.java的main函数是一个APP进程的入口，如果不一直循环，则在main函数执行完最后一行代码后整个应用进程就会退出；
android是以事件为驱动的操作系统，当有事件来时，就去做对应的处理，没有时就显示静态界面；
ANR发生条件是： Activity：5 秒。应用在 5 秒内未响应用户的输入事件（如按键或者触摸） BroadCastReceiver ：10 秒。BroadcastReceiver 未在 10 秒内完成相关的处理 Service：20 秒（均为前台）。Service 在20 秒内无法处理完成
如果Handler收到以上三个相应事件在规定时间内完成了，则移除消息，不会ANR；若没完成则会超时处理，弹出ANR对话框；

详细：

App进程的入口为ActivityThread.java的main()函数，注意ActivityThread不是一个线程；
应用的ui主线程实际是调用ActivityThread.java的main()函数执行时所在的线程,而这个线程对我们不可见，但是这就是主线程；参考：
在ActivityThread.java的main()函数中，会调用Looper.prepareMainLooper();
Looper.prepareMainLooper()会创建一个Looper并放到当前线程（主线程）的变量threadLocals中进行绑定，threadLocals是一个ThreadLocal.ThreadLocalMap；
在ActivityThread.java的main()函数结尾，开启Looper.loop()进行死循环，不让main函数结束，从而让App进程不会结束；
Android系统是以事件作为驱动的操作系统，当有事件来时，就去做对应处理，没有事件时，就显示当前界面，不做其他多余操作（浪费资源）；
在Looper.loop()的死循环中，不仅要取用户发的事件，还要取系统内核发的事件（如屏幕亮度改变等等）；
在调用Looper.loop()时，从MessageQueue.next()中获取事件，若没有则阻塞，有则分发；
MessageQueue其实不是一个队列，用epoll机制实现了阻塞；
在Looper.prepareMainLooper()时，调用c++函数epoll_create()会将App注册进epoll机制的红黑树中得到fd的值，epoll_ctl()给每个App注册事件类型并监听fd值是否改变，fd有改变时唤醒epoll_wait；
epoll_wait()有事件时就分发，没事件就阻塞

子线程的Looper和子线程Looper有什么不同？

子线程Looper是可以退出的，主线程不行；

Android Framework 面试集合——Handler篇（下）