HandlerThread解析以及相关问题分析

HandlerThread 相信大家都比较熟悉了，从名字上看是一个带有Handler消息循环机制的一个线程，比一般的线程多了消息循环的机制，可以说是Handler+Thread的结合，从源码上看也是如此的设计，一般情况下如果需要子线程和主线程之间相互交互，可以用HandlerThread来设计，这比单纯的Thread要方便，而且更容易管理，因为大家都知道Thread的生命周期在一些情况下是不可控制的，比如直接new Thread().start(),这种方式在项目中是不推荐使用的，实际上Android的源码中也有很多地方用到了HandlerThread,下面我将分析一下HandlerThread以及涉及到的一些其他相关的问题。

HandlerThread的源码简单分析

int mPriority;
    int mTid = -1;
    Looper mLooper;
    private @Nullable Handler mHandler;

    public HandlerThread(String name) {
        super(name);
        mPriority = Process.THREAD_PRIORITY_DEFAULT;
    }

首先字段有优先级，可以看到HandlerThread里面的优先级是默认的，当然了，你也可以修改，调用有二个参数的构造函数就可以了，在构造函数里面有个String类型，代表HandlerThread名字的，这个一般情况下可以取线程的名称。

/**
     * Call back method that can be explicitly overridden if needed to execute some
     * setup before Looper loops.
     */
    protected void onLooperPrepared() {
    }

    @Override
    public void run() {
        mTid = Process.myTid();
        Looper.prepare();
        synchronized (this) {
            mLooper = Looper.myLooper();
            notifyAll();
        }
        Process.setThreadPriority(mPriority);
        onLooperPrepared();
        Looper.loop();
        mTid = -1;
    }

这里面有一个方法onLooperPrepared()，在实际中，我们可以重写这个方法做一些初始化的操作，这个run()是重点，可以看到Looper进行了初始化并且开始循环接收消息了，并且唤醒了当前所有等待的线程，由于run方法是在start之后才会启动的，因此在用HandlertThread的时候，在初始化了实例之后就必须调用start方法开启消息循环了。

public Looper getLooper() {
        if (!isAlive()) {
            return null;
        }
        
        // If the thread has been started, wait until the looper has been created.
        synchronized (this) {
            while (isAlive() && mLooper == null) {
                try {
                    wait();
                } catch (InterruptedException e) {
                }
            }
        }
        return mLooper;
    }

这个方法是获取当前的looper，可以看到如果没有获取的时候就一直等待直到获取，而前面也提到了获取到了就唤醒了所有的线程，看来这是线程的等待-唤醒机制应用。

public Handler getThreadHandler() {
        if (mHandler == null) {
            mHandler = new Handler(getLooper());
        }
        return mHandler;
    }

这个是获取HandlerThread绑定的Looper线程的Handler

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

可以看到这两个方法去退出线程的Looper循环，那么这两个方法有什么区别呢,实际上都是调用了MessageQueue的quit()方法，源码如下:

void quit(boolean safe) {
        if (!mQuitAllowed) {
            throw new IllegalStateException("Main thread not allowed to quit.");
        }

        synchronized (this) {
            if (mQuitting) {
                return;
            }
            mQuitting = true;

            if (safe) {
                removeAllFutureMessagesLocked();
            } else {
                removeAllMessagesLocked();
            }

            // We can assume mPtr != 0 because mQuitting was previously false.
            nativeWake(mPtr);
        }
}

可以看到:当我们调用quit方法的时候，实际上执行了MessageQueue中的removeAllMessagesLocked方法，该方法的作用是把MessageQueue消息池中所有的消息全部清空，无论是延迟消息（延迟消息是指通过sendMessageDelayed或通过postDelayed等方法发送的需要延迟执行的消息,只要不是立即执行的消息都是延迟消息）还是非延迟消息。

而quitSafely方法时，实际上执行了MessageQueue中的removeAllFutureMessagesLocked方法，通过名字就可以看出，该方法只会清空MessageQueue消息池中所有的延迟消息，并将消息池中所有的非延迟消息派发出去让Handler去处理，quitSafely相比于quit方法安全之处在于清空消息之前会派发所有的非延迟消息,一句话，就是清除未来需要执行的消息。

这两个方法有一个共同的特点就是:Looper不再接收新的消息了,消息循环就此结束，此时通过Handler发送的消息也不会在放入消息杜队列了，因为消息队列已经退出了。应用这2个方法的时候需要注意的是:quit方法从API 1就开始存在了，比较早，而quitSafely直到API 18才添加进来.

到此源码分析结束，下面看一个实际的简单的例子:

private static class UserHandlerThread extends HandlerThread implements Handler.Callback {
        private Handler mHandler;
        public UserHandlerThread(String name) {
            super(name);
            start();
            mHandler = new Handler(getLooper(), this);
        }

        @Override
        protected void onLooperPrepared() {
            super.onLooperPrepared();
        }

        @Override
        public boolean handleMessage(Message msg) {
            if (msg.what==0x123){
                Log.d("[app]","收到消息了");
            }
            return false;
        }

        public Handler getHandler() {
            return mHandler;
        }
    }
    
    
    private UserHandlerThread handlerThread;
    handlerThread = new UserHandlerThread("handlerThread");
    handlerThread.getHandler().sendEmptyMessage(0x123);

OK，大家都知道结果了吧，一般情况下，在OnDestroy方法中需要退出循环，比如下面代码:

@Override
    protected void onDestroy() {
        super.onDestroy();
        if (handlerThread != null) {
            handlerThread.getHandler().removeCallbacksAndMessages(null);
            handlerThread.quit();
            handlerThread = null;
        }
    }
    //Looper.getMainLooper().quit();

大家先忽略注释的那句代码,好了，下面分析2个涉及到相关的问题:

● 既然子线程可以退出消息循环队列，那么UI线程，也就是主线程是否也一样可以在onDestroy方法退出消息循环呢,就是取消刚才代码的注释.

先说答案:不能退出主线程的消息队列，不然会抛出Main thread not allowed to quit.错误，是不是很熟悉，没错，上面的代码中已经贴出来了，为什么呢，MessageQueue有一个字段:mQuitAllowed

// True if the message queue can be quit.
    private final boolean mQuitAllowed;

这个字段代表：是否可以退出消息队列的意思，那么主线程的这个字段是什么呢，是false，就是不能退出当前消息的消息队列的意思，来看主线程的消息初始化代码:Looper.prepareMainLooper();

public static void prepareMainLooper() {
        prepare(false);
        synchronized (Looper.class) {
            if (sMainLooper != null) {
                throw new IllegalStateException("The main Looper has already been prepared.");
            }
            sMainLooper = myLooper();
        }
    }
    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));
    }
    
     private Looper(boolean quitAllowed) {
        mQueue = new MessageQueue(quitAllowed);
        mThread = Thread.currentThread();
    }

可以看到prepare参数中，主线程传入的是false，而在Looper的构造函数里面被赋值了，也就是主线程的是false，所以这就决定了主线程是不能退出消息队列，那为什么子线程就可以退出消息队列呢，因为子线程传入的是true，代码如下:

Looper.prepare();
 public static void prepare() {
        prepare(true);
    }

看到没，子线程传入的是true，这说明子线程是可以退出消息队列的，实际上真正退出主线程的消息队列是FrameWork层做的事情，下面的第三个问题会提到。

● Handler里面发出去的消息，究竟是在哪个线程执行的呢?

我们知道，handler的构造函数中有一个参数，就是设置当前Looper的，代码如下:

/**
     * Use the provided {@link Looper} instead of the default one.
     *
     * @param looper The looper, must not be null.
     */
    public Handler(Looper looper) {
        this(looper, null, false);
    }
     public Handler(Looper looper, Callback callback, boolean async) {
        mLooper = looper;
        mQueue = looper.mQueue;
        mCallback = callback;
        mAsynchronous = async;
    }
    mLooper = Looper.myLooper();
        if (mLooper == null) {
            throw new RuntimeException(
                "Can't create handler inside thread that has not called Looper.prepare()");
        }
    mQueue = mLooper.mQueue;

可以看到传入的Looper最终会被赋值到mLooper字段,如果没有调用这个构造函数，那么mLooper由当前线程获取，而消息队列MessageQueue是由Looper得到的,换句话说:Handler的消息在哪个Looper循环，那意味着所有的消息将会被哪个Looper的消息队列所存储和处理，而一个线程只能绑定一个Looper,因此一个Handler只能绑定一个Looper，也就意味着，Handler绑定了哪个线程的Looper，那么所有的消息都会在哪个线程执行，当然了有同学说我在Handler里面开线程就另外说了，但Handler操作的本身一定是在对应的Looper所在的线程的,就是如果Handler绑定了主线程的Looper,那么所有的消息都会在主线程处理，如果绑定的是子线程，那么所有的消息都会在子线程处理。

●在Android一个应用程序"退出"的真正含义是什么呢？

对于这个问题，有同学可能说我杀掉进程，应用程序挂了，也就相当于退出了。实际上这个说法是不正确的，因为这里的杀掉进程，不仅仅是程序本身，而且连程序的内存空间也一并被处理，我们前面说了，子线程可以退出消息队列，意味着子线程就再也无法接收到任何消息了，这就是子线程的退出含义，实际上，主线程也是一样的，只是这个过程对我们开发者不可见而已，在主线程中，如果退出了消息队列，那么意味着主线程也无法接收到任何消息，下面是代码,在ActivityThread.java里面:

public final void scheduleExit() {
            sendMessage(H.EXIT_APPLICATION, null);
        }
 case EXIT_APPLICATION:
                    if (mInitialApplication != null) {
                        mInitialApplication.onTerminate();
                    }
                    Looper.myLooper().quit();
                    break;

看到这里，我想熟悉IPC过程的同学应该都知道了，没错，scheduleExit()不是本地进程调用的，而是由服务端进程ActivityAManagerService服务进行调用的，这也是我为什么说退出主线程是由FrameWork调用的原因，在AMS里面有2处地方调用了退出的代码，分别是绑定本地进程和内存回收工作的时候调用的，下面是代码(在ActivityManagerService.Java里面):

在APP本地进程绑定到AMS进程的时候调用
 private final boolean attachApplicationLocked(IApplicationThread thread,
            int pid) {

        // Find the application record that is being attached...  either via
        // the pid if we are running in multiple processes, or just pull the
        // next app record if we are emulating process with anonymous threads.
        ProcessRecord app;
        if (pid != MY_PID && pid >= 0) {
            synchronized (mPidsSelfLocked) {
                app = mPidsSelfLocked.get(pid);
            }
        } else {
            app = null;
        }

        if (app == null) {
            Slog.w(TAG, "No pending application record for pid " + pid
                    + " (IApplicationThread " + thread + "); dropping process");
            EventLog.writeEvent(EventLogTags.AM_DROP_PROCESS, pid);
            if (pid > 0 && pid != MY_PID) {
                Process.killProcessQuiet(pid);
                //TODO: killProcessGroup(app.info.uid, pid);
            } else {
                try {
                //这里也调用了
                    thread.scheduleExit();
                } catch (Exception e) {
                    // Ignore exceptions.
                }
            }
            return false;
        }
        //省略一些非必要代码
    }


//i清理内存的时候调用
final void trimApplications() {
        synchronized (this) {
            int i;

            // First remove any unused application processes whose package
            // has been removed.
            for (i=mRemovedProcesses.size()-1; i>=0; i--) {
                final ProcessRecord app = mRemovedProcesses.get(i);
                if (app.activities.size() == 0
                        && app.curReceiver == null && app.services.size() == 0) {
                    Slog.i(
                        TAG, "Exiting empty application process "
                        + app.toShortString() + " ("
                        + (app.thread != null ? app.thread.asBinder() : null)
                        + ")\n");
                    if (app.pid > 0 && app.pid != MY_PID) {
                        //杀进程
                        app.kill("empty", false);
                    } else {
                        try {
                        //这里调用了退出主线程消息队列代码
                            app.thread.scheduleExit();
                        } catch (Exception e) {
                            // Ignore exceptions.
                        }
                    }
                    cleanUpApplicationRecordLocked(app, false, true, -1, false /*replacingPid*/);
                    mRemovedProcesses.remove(i);

                    if (app.persistent) {
                        addAppLocked(app.info, false, null /* ABI override */);
                    }
                }
            }

            // Now update the oom adj for all processes.
            updateOomAdjLocked();
        }
    }

看到了吧，在首次App绑定进程的时候，如果发生app==null这个错误的时候就调用了退出主线程消息队列，另一个就是在清理内存的时候调用，这两个过程对我们开发者不可见，我们了解就好,在源码面前，并没有什么是神奇的地方。

感谢大家阅读，如果有什么错误的地方，请欢迎指出，谢谢。