Android全面解析之Handler机制（四）：内部关键类

一只修仙的猿
2,084 阅读8分钟
“

文章相关内容已授权『郭霖』公众号发布

”

前言

很高兴遇见你~ 欢迎阅读我的文章。

本文是系列文章的第四部分，主要内容是介绍Handler的内部关键类：Handler，以及HandlerThread。

“

Handler系列文章共分为6个部分：

  1. 第一部分：系列开篇，从0开始认识Handler；
  2. 第二部分：介绍Handler内部模式，详解关键类ThreadLocal；
  3. 第三部分：解析Handler内部关键类：Message、MessageQueue、Looper；
  4. 第四部分：解析Handler内部关键类：Handler,同时介绍HandlerThread；
  5. 第五部分：总结Handler，从源码设计角度思考Handler；
  6. 第六部分：Handler常见问题解答；

本文为系列文章的第四部分。读者可前往笔者主页选择感兴趣的部分阅读。

”

那么，我们开始吧。

正文

Handler

概述

我们整个消息机制称为Handler机制就可以知道Handler我们的使用频率之高，一般情况下我们的使用也是围绕着Handler来展开。Handler是作为整个消息机制的消息发起者与处理者，消息在不同的线程通过Handler发送到目标线程的MessageQueue中，然后目标线程的Looper再调用Handler的dispatchMessage方法来处理消息。

创建Handler

一般情况下我们使用Handler有两种方式： 继承Handler并重写handleMessage方法，直接创建Handler对象并传入callBack，这在前面使用Handler部分讲过就不再赘述。

需要注意的一点是：创建Handler必须显示指明Looper参数，而不能直接使用无参构造函数，如：

Handler handler = new Handler(); //1
Handler handler = new Handler(Looper.myLooper())//2

1是错的，2是对的。避免在Handler创建过程中Looper已经退出的情况。

发送消息

Handler发送消息有两种系列方法 ： postxx 和 sendxx。如下：

public final boolean post(@NonNull Runnable r);
public final boolean postDelayed(@NonNull Runnable r, long delayMillis);
public final boolean postAtTime(@NonNull Runnable r, long uptimeMillis);
public final boolean postAtFrontOfQueue(@NonNull Runnable r);

public final boolean sendMessage(@NonNull Message msg);
public final boolean sendMessageDelayed(@NonNull Message msg, long delayMillis);
public boolean sendMessageAtTime(@NonNull Message msg, long uptimeMillis);
public final boolean sendMessageAtFrontOfQueue(@NonNull Message msg)

这里我只列出了比较常用的两类方法。除了插在队列头的两个方法，其他方法最终都调用到了sendMessageAtTime。我们从post方法跟源码分析一下：

public final boolean post(@NonNull Runnable r) {
    return  sendMessageDelayed(getPostMessage(r), 0);
}

post方法把runnable对象封装成一个Message，再调用sendMessageDelayed方法，我们看看他是如何封装的：

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

可以看到逻辑很简单，把runnable对象直接赋值给callBack属性。接下来回去继续看sendMessageDelayed：

public final boolean sendMessageDelayed(@NonNull Message msg, long delayMillis) {
    if (delayMillis < 0) {
        delayMillis = 0;
    }
    return sendMessageAtTime(msg, SystemClock.uptimeMillis() + delayMillis);
}

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

sendMessageDelayed把小于0的延迟时间改成0，然后调用sendMessageAtTime。这个方法主要是判断MessageQueue是否已经初始化了，然后再调用enqueueMessage方法进行入队操作：

private boolean enqueueMessage(@NonNull MessageQueue queue, @NonNull Message msg,
        long uptimeMillis) {
    // 这里把target设置成自己
    msg.target = this;
    msg.workSourceUid = ThreadLocalWorkSource.getUid();
 // 异步handler设置标志位true，后面会讲到同步屏障
    if (mAsynchronous) {
        msg.setAsynchronous(true);
    }
    // 最后调用MessageQueue的方法入队
    return queue.enqueueMessage(msg, uptimeMillis);
}

可以看到Handler的入队操作也是很简单，把Message的target设置成本身，这样这个Message最后就是由自己来处理。最后调用MessageQueue的入队方法来入队，这在前面讲过就不再赘述。

其他的发送消息方法都是大同小异，读者感兴趣可以自己去跟踪一下源码。

处理消息

上面讲Looper处理消息的时候，最后就是调用handler的dispatchMessage方法来处理。我们来看一下这个方法：

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

private static void handleCallback(Message message) {
    message.callback.run();
}

他的逻辑也不复杂。首先判断Message是否有callBack，有的话就直接执行callBack的逻辑，这个callBack就是我们调用handler的post系列方法传进去的Runnable对象。否则判断Handler是否有callBack，有的话执行他的方法，如果返回true则结束，如果返回false则直接Handler本身的handleMessage方法。这个过程可以用下面的图表示一下：

dispatchMessage逻辑

内存泄露问题

当我们使用继承Handler方法来使用Handler的时候，要注意使用静态内部类，而不要用非静态内部类。因为非静态内部类会持有外部类的引用，而从上面的分析我们知道Message在被入队之后他的target属性是指向了Handler，如果这个Message是一个延迟的消息，那么这一条引用链的对象就迟迟无法被释放，造成内存泄露。

一般这种泄露现象在于：我们在Activity中发送了一个延迟消息，然后退出了activity，但是由于无法释放，这样activity就无法被回收，造成内存泄露。

Handler总结

Handler作为消息的处理和发送者，是整个消息机制的起点和终点，也是我们接触最多的一个类，因为我们称此消息机制为Handler机制。Handler最重要的就是发送和处理消息，只要熟练掌握这两方面的内容就可以了。同时注意内存泄露问题，不要使用非静态内部类去继承Handler。

HandlerThread

概述

有时候我们需要开辟一个线程来执行一些耗时的任务。一般情况下可以通过新建一个Thread，然后再在他的run方法里初始化该线程的Looper，这样就可以用他的Looper来切线程处理消息了。如下（这里是kotlin代码，和java差不多相信可以看得懂的）：

val thread = object : Thread(){
    lateinit var mHandler: Handler
    override fun run() {
        super.run()
        Looper.prepare()
        mHandler = Handler(Looper.myLooper()!!)
        Looper.loop()
    }
}
thread.start()
thread.mHandler.sendMessage(Message.obtain())

但是，运行一下，炸了：

Handler还未初始化。线程的启动需要一定的时间，如果在Thread的run方法还没被调用之间获取Handler，就会出现Handler未初始化的问题。那简单，等待一下就可以了，上代码：

val thread = object : Thread(){
    lateinit var mHandler: Handler
    override fun run() {
        super.run()
        Looper.prepare()
        mHandler = Handler(Looper.myLooper()!!)
        Looper.loop()
    }
}
thread.start()
Thread(){
    Thread.sleep(10000)
    thread.mHandler.sendMessage(Message.obtain())
}.start()

执行一下，诶，没有报错了果然可以。但是！！！ ，这样的代码显得特别的难堪和臃肿，还要再开启一个线程来延迟处理。那有没有更好的解决方案？有，HandlerThread。

HandlerThread本身是一个Thread，他继承自Thread，他的代码并不复杂，看一下（代码还是有点多，可以选择看或者不看，我下面会讲重点方法）：

public class HandlerThread extends Thread {
    // 依次是：线程优先级、线程id、线程looper、以及内部handler
    int mPriority;
    int mTid = -1;
    Looper mLooper;
    private @Nullable Handler mHandler;

    // 两个构造器。name是线程名字，priority是线程优先级
    public HandlerThread(String name) {
        super(name);
        mPriority = Process.THREAD_PRIORITY_DEFAULT;
    }
    public HandlerThread(String name, int priority) {
        super(name);
        mPriority = priority;
    }
    
    // 在Looper开始运行前的方法
    protected void onLooperPrepared() {
    }

    // 初始化Looper
    @Override
    public void run() {
        mTid = Process.myTid();
        Looper.prepare();
        synchronized (this) {
            mLooper = Looper.myLooper();
            // 通知初始化完成
            notifyAll();
        }
        Process.setThreadPriority(mPriority);
        onLooperPrepared();
        Looper.loop();
        mTid = -1;
    }
    
    // 获取当前线程的Looper
    public Looper getLooper() {
        if (!isAlive()) {
            return null;
        }
        // 如果尚未初始化则会一直阻塞知道初始化完成
        synchronized (this) {
            while (isAlive() && mLooper == null) {
                try {
                    // 利用Object对象的wait方法
                    wait();
                } catch (InterruptedException e) {
                }
            }
        }
        return mLooper;
    }

    // 获取handler，该方法被标记为hide，用户无法获取
    @NonNull
    public Handler getThreadHandler() {
        if (mHandler == null) {
            mHandler = new Handler(getLooper());
        }
        return mHandler;
    }

    // 两种不同类型的退出，前面讲过不再赘述
    public boolean quit() {
        Looper looper = getLooper();
        if (looper != null) {
            looper.quit();
            return true;
        }
        return false;
    }
    public boolean quitSafely() {
        Looper looper = getLooper();
        if (looper != null) {
            looper.quitSafely();
            return true;
        }
        return false;
    }

    // 获取线程id
    public int getThreadId() {
        return mTid;
    }
}

整个类的代码不是很多，重点在run()和getLooper()方法。首先看到getLooper方法：

public Looper getLooper() {
    if (!isAlive()) {
        return null;
    }
    // 如果尚未初始化则会一直阻塞知道初始化完成
    synchronized (this) {
        while (isAlive() && mLooper == null) {
            try {
                // 利用Object对象的wait方法
                wait();
            } catch (InterruptedException e) {
            }
        }
    }
    return mLooper;
}

和我们前面自己写的不同，他有一个wait()，这个是Java中Object类提供的一个方法，类似于我们前面讲的MessageQueue阻塞。等到Looper初始化完成之后就会唤醒他，就可以顺利返回了，不会造成Looper尚未初始化完成的情况。然后再看到run方法：

// 初始化Looper
@Override
public void run() {
    mTid = Process.myTid();
    Looper.prepare();
    synchronized (this) {
        mLooper = Looper.myLooper();
        // 通知初始化完成
        notifyAll();
    }
    Process.setThreadPriority(mPriority);
    onLooperPrepared();
    Looper.loop();
    mTid = -1;
}

常规的Looper初始化，完成之后调用了notifyAll()方法进行唤醒，对应了上面的getLooper方法。

HandlerThread的使用

HandlerThread的使用范围很有限，开个子线程不断接受消息处理耗时任务。所以他的使用方法也是比较固定：

HandlerThread ht = new HandlerThread("handler");
ht.start();
Handler handler = new Hander(ht.getLooper());
handler.sendMessage(msg);

获取到他的Looper，外部自定义Handler来使用即可。

最后

Handler，MessageQueue，Looper三者共同构成了android消息机制，各司其职。其中Handler主要负责发送和处理消息，MessageQueue主要负责消息的排序以及在没有需要处理的消息的时候阻塞代码，Looper负责从MessageQueue中取出消息给Handler处理，同时达到切换线程的目的。通过源码分析，希望读者可以对这些概念有更加清晰的认知。

希望文章对你有帮助。

“

全文到此，原创不易，觉得有帮助可以点赞收藏评论转发。
笔者才疏学浅，有任何想法欢迎评论区交流指正。
如需转载请私信或评论区交流。
另外欢迎光临笔者的个人博客：传送门

”
avatar
文章
阅读
粉丝