在开发的时候都用过Handler，今天发现了一个HandlerThread，本着好奇的心里点进去看了一下源码，发现原来这货就是一个Thread的封装。本着存在即是合理的想法，探寻了一下它存在的道理。源码也就100来行不多。
我们都知道，通过
Loop.prepare()和Loop.loop()方法可以把这两行代码之前的代码加入Loop消息队列，若想加入主线程消息队列，则需要使用Looper.prepareMainLooper()进而在主线程中运行。因此，这两个方法经常被用在一个异步线程中。
需要注意的是Loop.loop()方法本质上是一个死循环，不停的从消息队列中获取一个事件去执行。因此在线程中调用此方法后，其后面的所有代码将得不到执行，必须调用loop.quit()或者loop.quitSafely()方可结束Loop循环。
而HandlerThread其实就是Thread的封装只不过帮你内部建立了Looper.只不过这里并不是用来做UI处理的，HandlerThread 所做的就是在新开的子线程中创建了 Looper，并结合Handler做处理，执行耗时的操作。
下面有一个测试例子：
public class MainActivity extends AppCompatActivity {
TextView tv;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
tv=findViewById(R.id.tv);
HandlerThread handlerThread=new HandlerThread("handlerThread");
//创建完HandlerThread记得要先start()去启动这个线程，才可以获取线程中的Looper();
handlerThread.start();
Handler handler=new Handler(handlerThread.getLooper()){
@Override
public void handleMessage(Message msg) {
super.handleMessage(msg);
//模拟耗时操作
SystemClock.sleep(5000);
System.out.println(msg.what);
//下面更新UI会异常因为当前的并不在UI线程里
//tv.setText(String.valueOf(msg.what));不可以这么做。
}
};
findViewById(R.id.btn).setOnClickListener(v->{
Random r=new Random();
handler.sendEmptyMessage(r.nextInt(10));
});
}
}
在上面的例子中，我们定义了一个HandlerThread，并给它起了个名字叫做handlerThread,又定义了一个Handler依附于ThreadHandler中的Loop，用来处理消息。因此在其handleMessage中是不能做UI相关的操作，因为它存在于一个名字叫做handlerThread的子线程中。该线程内部维护了一个自己的消息队列，因此可以一个一个的执行耗时任务，而不会堵塞UI线程。所以要想在处理完任务后做相关的UI操作，还需要创建一个依附在主线程上的Handler，在其中处理即可。
如果要结束HandlerThread必须调用里面的quit()或者quitSafely()方法。这两个方法区别仅在于前者会情况消息队列中的所有待执行消息。而后者则只会清空消息队列中所有待执行的延迟消息，非延迟消息任然会执行。相比之下后者更加和善一点，当然具体使用还得看业务场合。
下面有这两个方法的签名描述：
/**
* Quits the handler thread's looper.
* <p>
* Causes the handler thread's looper to terminate without processing any
* more messages in the message queue.
* </p><p>
* Any attempt to post messages to the queue after the looper is asked to quit will fail.
* For example, the {@link Handler#sendMessage(Message)} method will return false.
* </p><p class="note">
* Using this method may be unsafe because some messages may not be delivered
* before the looper terminates. Consider using {@link #quitSafely} instead to ensure
* that all pending work is completed in an orderly manner.
* </p>
*
* @return True if the looper looper has been asked to quit or false if the
* thread had not yet started running.
*
* @see #quitSafely
*/
public boolean quit() {
Looper looper = getLooper();
if (looper != null) {
looper.quit();
return true;
}
return false;
}
/**
* Quits the handler thread's looper safely.
* <p>
* Causes the handler thread's looper to terminate as soon as all remaining messages
* in the message queue that are already due to be delivered have been handled.
* Pending delayed messages with due times in the future will not be delivered.
* </p><p>
* Any attempt to post messages to the queue after the looper is asked to quit will fail.
* For example, the {@link Handler#sendMessage(Message)} method will return false.
* </p><p>
* If the thread has not been started or has finished (that is if
* {@link #getLooper} returns null), then false is returned.
* Otherwise the looper is asked to quit and true is returned.
* </p>
*
* @return True if the looper looper has been asked to quit or false if the
* thread had not yet started running.
*/
public boolean quitSafely() {
Looper looper = getLooper();
if (looper != null) {
looper.quitSafely();
return true;
}
return false;
}