Android Handler的应用和源码解析

Handler的应用和源码解析

Handler的作用

• send/post 发送消息(发送者）
• handleMessage/callback 处理消息（处理者）
• remove等对消息的操作

Handler的构造

Handler有下列几种构造方法（暂不讨论安全性等问题）

• Handler() 
  

• Handler(Callback callback)
  

• Handler(Looper looper)
  

• Handler(Looper looper, Callback callback)
  

• Handler(boolean async)
  

• Handler(Callback callback, boolean async)
  

• Handler(Looper looper, Callback callback, boolean async)
  

上述构造方法主要分为两大类，
第一种、第二种和第五种构造方法，本质都是通过第六种构造方法实现的

第三种和第四种构造方法，本质都是通过第七种构造方法实现的

其中第一种和第二种是被遗弃的方法，第五种构造方法是我们无法调用的。换句话说，第一大类方法全军覆没，对比第二大类的构造方法，少了唯一一个参数——Looper looper

但是这并不意味着第一大类的方法并没有获取到Looper，毕竟我们都知道Handler只有在Looper存在的情况下，才能正常使用，所以参考第六种构造方法的源码

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;
}

其中有行代码mLooper = Looper.myLooper();，第一大类的构造方法就这么隐式地获取了Looper。那么大家也就知道第一大类方法为什么被弃用了，因为隐式获取Looper可能会导致程序崩溃（隐式获取的Looper为空，也就是大家了解到的Looper.prepare() 后使用Handler)或隐式获取的looper关联的线程不符合预期等
关于这一点，如果是Java开发，extends Handler时并不能体会到，但是如果是Kotlin开发，: Handler()就会看到上面多了一条被弃用的横杠

第二大类的构造方法源码就比较简单了，就是单纯地赋值，获取Looper里地消息队列。其中国第七种构造方法也是我们无法调用的

Handler的消息处理机制

一般情况下啊，我们继承Handler，都会去重写handleMessage方法，所以可能会下意识认为消息会直接到达handleMessage方法
但是，实际上，Handler的消息处理总共分为四个部分：DispacthMessage、Message（handleCallback）、Callback、handleMeesage
下面一一分析
首先是dispacthMessage，就是消息的分发

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

我们很容易从源码中得知，消息的优先级是 msg.callback -> handler.callback -> handleMessage

msg.callback是Runnable类，handleCallback本质就是Runnable执行run方法

handler.callback是Handler中定义的接口，其中只有一个方法handleMessage（返回值为Boolean)

最后handleMessage默认是空实现，大家也一定十分熟悉了

Handler的消息发送机制

Handler的消息发送方法总共有下面几种

• post(@NonNull Runnable r)
  

• postAtTime(@NonNull Runnable r, long uptimeMillis)
  

• postAtTime(@NonNull Runnable r, @Nullable Object token, long uptimeMillis)
  

• postDelayed(@NonNull Runnable r, long delayMillis)
  

• postDelayed(Runnable r, int what, long delayMillis)
  

• postDelayed( @NonNull Runnable r, @Nullable Object token, long delayMillis)
  

• postAtFrontOfQueue(@NonNull Runnable r)
  

• sendMessage(@NonNull Message msg)
  

• sendEmptyMessage(int what)
  

• sendEmptyMessageDelayed(int what, long delayMillis)
  

• sendEmptyMessageAtTime(int what, long uptimeMillis)
  

• sendMessageDelayed(@NonNull Message msg, long delayMillis)
  

• sendMessageAtTime(@NonNull Message msg, long uptimeMillis)
  

• sendMessageAtFrontOfQueue(@NonNull Message msg)
  

• executeOrSendMessage(@NonNull Message msg)
  

简单分类，就是post/send

post

观察上面api，可以发现send和post的方法都有一一对应，唯一的区别就是，post参数为Runnable，send参数为Message

而且刚才提到了Message.callback是Runnable类

所以，真相只有一个（柯南眼睛反光脸）

post方法会将Runnable封装成Message类，然后再调用send方法

而封装过程也十分简单

    private static Message getPostMessage(Runnable r) {
        Message m = Message.obtain();
        m.callback = r;
        return m;
    }

send

先说几个结论

• send系列方法的本质都是enqueueMessage方法
• 除了sendMessageAtFrontOfQueue外的send系列方法，最终都会调用sendMessageAtTime

流程(源码本身就是一个流程调用)

sendMessage(msg) -> sendMessageDelayed(msg, 0) -> sendMessageAtTime(msg, SystemClock.uptimeMillis() )

sendMessageDelayed(msg, delayMillis) -> sendMessageAtTime(msg, SystemClock.uptimeMillis() + delayMillis)

sendMessage同理

所以，接下来看两部分源码

第一是sendMessageAtTime

public boolean sendMessageAtTime(@NonNull 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);
}

源码也比较好了解，唯一的问题就是消息队列什么时候会为空？根据前面Handler的构造方法，Handler的消息队列和Looper的消息队列是共享的，一般情况下确实不会出现为空的情况，但是因为Looper里提供了getQueue()方法，所以可能会出现误操作导致消息队列为null

第二是sendMessageAtFrontOfQueue

   public final boolean sendMessageAtFrontOfQueue(@NonNull Message msg) {
        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, 0);
    }

和sendMessageAtTime差不多

第三是非post/send的方法——executeOrSendMessage

public final boolean executeOrSendMessage(@NonNull Message msg) {
    if (mLooper == Looper.myLooper()) {
        dispatchMessage(msg);
        return true;
    }
    return sendMessage(msg);
}

这个方法就很好证明了Looper参数显性设置的重要性

最后是enqueueMessage

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);
}

这个方法放在handler里确实没有什么值得详细介绍的，queue.enqueueMessage将在后续的消息队列源码中介绍

不过，该方法值得注意的就是Message的两个参数target和workSourceUid，这也会在Message的源码中介绍

最后再提一下一开始的结论

• send系列方法的本质都是enqueueMessage方法
• 除了sendMessageAtFrontOfQueue外的send系列方法，最终都会调用sendMessageAtTime

remove

remove系列方法就是调用消息队列的remove相关方法，这同样放到消息队列源码中介绍

runWithScissors方法

这个方法大家可能没有听说过，因为它有隐患，谷歌也不让我们用，标记为了hide。

这个虽然比较冷门，但是在framework中有不少场景会用到它，所以还是稍微介绍一下它

public final boolean runWithScissors(@NonNull Runnable r, long timeout) {
    if (r == null) {
        throw new IllegalArgumentException("runnable must not be null");
    }
    if (timeout < 0) {
        throw new IllegalArgumentException("timeout must be non-negative");
    }

    if (Looper.myLooper() == mLooper) {
        r.run();
        return true;
    }

    BlockingRunnable br = new BlockingRunnable(r);
    return br.postAndWait(this, timeout);
}

两个参数——Runnable任务和超时事件

大致流程是

1. 对参数进行检验
2. 对Handler的处理线程和当前线程进行判断（通过looper）
3. 线程不一致，执行BlockingRunnable

从这里暂时看不出什么名堂，所以再看BlockingRunnable这个类（Handler的内部类）

private static final class BlockingRunnable implements Runnable {
    private final Runnable mTask;
    private boolean mDone;

    public BlockingRunnable(Runnable task) {
        mTask = task;
    }

    @Override
    public void run() {
        try {
            mTask.run();
        } finally {
            synchronized (this) {
                mDone = true;
                notifyAll();
            }
        }
    }

    public boolean postAndWait(Handler handler, long timeout) {
        if (!handler.post(this)) {
            return false;
        }

        synchronized (this) {
            if (timeout > 0) {
                final long expirationTime = SystemClock.uptimeMillis() + timeout;
                while (!mDone) {
                    long delay = expirationTime - SystemClock.uptimeMillis();
                    if (delay <= 0) {
                        return false; // timeout
                    }
                    try {
                        wait(delay);
                    } catch (InterruptedException ex) {
                    }
                }
            } else {
                while (!mDone) {
                    try {
                        wait();
                    } catch (InterruptedException ex) {
                    }
                }
            }
        }
        return true;
    }
}

这个源码也比较好理解，最重要的方法就是postAndWait，大致流程为

• 先尝试post操作，如果失败了（Looper或者MessageQueue出了问题）就返回
• 如果post成功，就进入临界区等待
• 如果一直未被处理且等待超时，返回false
• 如果post成功了，则调用runWithScissors中的runnable，并唤醒线程

因为当前接触的fragmework层不是很多，所以只能举出其在WMS启动流程中的应用。

至于其造成的隐患，从上面的源码中就能窥探出一二

第一个隐患——没有remove

如果是post失败了，消息自然不用remove

但是如果是等待超时了，handler不会执行remove操作，这也就意味着后续该runnable会被执行，这和预期并不符合

第二个隐患——死锁

先前提到了BlockingRunnable如果执行了，会调用notifyAll()去唤醒线程，这一步其实时为了唤醒发送线程。

而此时如果去调用Looper中的quit方法（该方法会调用消息队列的quit方法，清空所有的消息），这也就意味着post成功的消息被清掉了，那么发送线程就有可能一直处于wait状态（timeout <= 0 时)，从而造成发送线程阻塞。

众所周知，wait不会放弃所有的锁，如果出现这样的形式就会产生死锁

synchronized(obj2){
    ......
    synchronized(obj1){
         ......
         runWithScissors()
         ......
    }
}

ObtainMessage

本质是调用Message.obtain（在后续Message源码中给出）

handler.obtainMessage或Message.obtain的性能会比直接new Message()高

因为Message里维护了循环利用Message的Pool（具体实现也在后续Message源码中给出）

内存泄漏

弱引用持有Activity

在Activity的onDestroy调用时清空消息队列