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();
大家先疏忽正文的那句代码, 好了，上面剖析3个波及到相干的问题:
● 既然子线程能够退出音讯循环队列，那么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的源码，只简略探讨跟Handler线程相干的问题，实际上，对于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这个谬误的时候就调用了退出主线程音讯队列，另一个就是在清理内存的时候调用，这两个过程对咱们开发者不可见，咱们理解就好,在源码背后，并没有什么是神奇的中央。
感激大家浏览，如果有什么谬误的中央，请欢送指出，谢谢。
相干视频举荐：
【安卓面试合集】5-FrameWork源码之handler源码解析(一)-01
【安卓面试合集】6-FrameWork源码之handler源码解析(一)-02
本文转自 https://juejin.cn/post/6844903526468943886，如有侵权，请分割删除。
发表回复