Handler消息机制：面试初级、中级，Android开发者

@Override
protected void onCreate(@Nullable Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_three);
new Thread(new Runnable() {
@Override
public void run() {
//创建Looper，MessageQueue
Looper.prepare();
new Handler().post(new Runnable() {
@Override
public void run() {
Toast.makeText(HandlerActivity.this,“toast”,Toast.LENGTH_LONG).show();
}
});
//开始处理消息
Looper.loop();
}
}).start();
}

这里需要注意在所有事情处理完成后应该调用quit方法来终止消息循环，否则这个子线程就会一直处于循环等待的状态，因此不需要的时候终止Looper，调用Looper.myLooper().quit()。

看完上面的代码可能你会有一个疑问，在子线程中更新UI（进行Toast）不会有问题吗，我们Android不是不允许在子线程更新UI吗，实际上并不是这样的，在ViewRootImpl中的checkThread方法会校验mThread != Thread.currentThread(),mThread的初始化是在ViewRootImpl的的构造器中，也就是说一个创建ViewRootImpl线程必须和调用checkThread所在的线程一致，UI的更新并非只能在主线程才能进行。

void checkThread() {
if (mThread != Thread.currentThread()) {
throw new CalledFromWrongThreadException(
“Only the original thread that created a view hierarchy can touch its views.”);
}
}

这里需要引入一些概念，Window是Android中的窗口，每个Activity和Dialog，Toast分别对应一个具体的Window，Window是一个抽象的概念，每一个Window都对应着一个View和一个ViewRootImpl，Window和View通过ViewRootImpl来建立联系，因此，它是以View的形式存在的。我们来看一下Toast中的ViewRootImpl的创建过程，调用toast的show方法最终会调用到其handleShow方法

//Toast.java
public void handleShow(IBinder windowToken) {
···
if (mView != mNextView) {
// Since the notification manager service cancels the token right
// after it notifies us to cancel the toast there is an inherent
// race and we may attempt to add a window after the token has been
// invalidated. Let us hedge against that.
try {
mWM.addView(mView, mParams); //进行ViewRootImpl的创建
trySendAccessibilityEvent();
} catch (WindowManager.BadTokenException e) {
/* ignore */
}
}
}

这个mWM（WindowManager）的最终实现者是WindowManagerGlobal，其的addView方法中会创建ViewRootImpl，然后进行root.setView(view, wparams, panelParentView)，通过ViewRootImpl来更新界面并完成Window的添加过程。

//WindowManagerGlobal.java
root = new ViewRootImpl(view.getContext(), display); //创建ViewRootImpl

view.setLayoutParams(wparams);

mViews.add(view);
mRoots.add(root);
mParams.add(wparams);

// do this last because it fires off messages to start doing things
try {
//ViewRootImpl
root.setView(view, wparams, panelParentView);
} catch (RuntimeException e) {
// BadTokenException or InvalidDisplayException, clean up.
if (index >= 0) {
removeViewLocked(index, true);
}
throw e;
}
}

setView内部会通过requestLayout来完成异步刷新请求，同时也会调用checkThread方法来检验线程的合法性。

@Override
public void requestLayout() {
if (!mHandlingLayoutInLayoutRequest) {
checkThread();
mLayoutRequested = true;
scheduleTraversals();
}
}

因此，我们的ViewRootImpl的创建是在子线程，所以mThread的值也是子线程，同时我们的更新也是在子线程，所以不会产生异常，同时也可以参考这篇文章分析，写的非常详细。同理下面的代码也可以验证这个情况

//子线程中调用
public void showDialog(){
new Thread(new Runnable() {
@Override
public void run() {
//创建Looper，MessageQueue
Looper.prepare();
new Handler().post(new Runnable() {
@Override
public void run() {
builder = new AlertDialog.Builder(HandlerActivity.this);
builder.setTitle(“jackie”);
alertDialog = builder.create();
alertDialog.show();
alertDialog.hide();
}
});
//开始处理消息
Looper.loop();
}
}).start();
}

在子线程中调用showDialog方法，先调用alertDialog.show()方法，再调用alertDialog.hide()方法，hide方法只是将Dialog隐藏，并没有做其他任何操作(没有移除Window)，然后再在主线程调用alertDialog.show()；便会抛出Only the original thread that created a view hierarchy can touch its views异常了。

2020-11-09 18:35:39.874 24819-24819/com.jackie.testdialog E/AndroidRuntime: FATAL EXCEPTION: main
Process: com.jackie.testdialog, PID: 24819
android.view.ViewRootImpl$CalledFromWrongThreadException: Only the original thread that created a view hierarchy can touch its views.
at android.view.ViewRootImpl.checkThread(ViewRootImpl.java:8191)
at android.view.ViewRootImpl.requestLayout(ViewRootImpl.java:1420)
at android.view.View.requestLayout(View.java:24454)
at android.view.View.setFlags(View.java:15187)
at android.view.View.setVisibility(View.java:10836)
at android.app.Dialog.show(Dialog.java:307)
at com.jackie.testdialog.HandlerActivity$2.onClick(HandlerActivity.java:41)
at android.view.View.performClick(View.java:7125)
at android.view.View.performClickInternal(View.java:7102)

所以在线程中更新UI的重点是创建它的ViewRootImpl和checkThread所在的线程是否一致。

如何在主线程中访问网络

在网络请求之前添加如下代码

StrictMode.ThreadPolicy policy = new StrictMode.ThreadPolicy.Builder().permitNetwork().build();
StrictMode.setThreadPolicy(policy);

StrictMode（严苛模式）Android2.3引入，用于检测两大问题：ThreadPolicy（线程策略）和VmPolicy(VM策略)，这里把严苛模式的网络检测关了，就可以在主线程中执行网络操作了，一般是不建议这么做的。关于严苛模式可以查看这里。

系统为什么不建议在子线程中访问UI？

这是因为 Android 的UI控件不是线程安全的，如果在多线程中并发访问可能会导致UI控件处于不可预期的状态，那么为什么系统不对UI控件的访问加上锁机制呢？缺点有两个：

1. 首先加上锁机制会让UI访问的逻辑变得复杂

2. 锁机制会降低UI访问的效率，因为锁机制会阻塞某些线程的执行。

所以最简单且高效的方法就是采用单线程模型来处理UI操作。（安卓开发艺术探索）

子线程如何通知主线程更新UI（都是通过Handle发送消息到主线程操作UI的）

1. 主线程中定义 Handler，子线程通过 mHandler 发送消息，主线程 Handler 的 handleMessage 更新UI。
2. 用 Activity 对象的 runOnUiThread 方法。
3. 创建 Handler，传入 getMainLooper。
4. View.post(Runnable r) 。

Looper死循环为什么不会导致应用卡死，会耗费大量资源吗？

从前面的主线程、子线程的分析可以看出，Looper会在线程中不断的检索消息，如果是子线程的Looper死循环，一旦任务完成，用户应该手动退出，而不是让其一直休眠等待。（引用自Gityuan）线程其实就是一段可执行的代码，当可执行的代码执行完成后，线程的生命周期便该终止了，线程退出。而对于主线程，我们是绝不希望会被运行一段时间，自己就退出，那么如何保证能一直存活呢？简单做法就是可执行代码是能一直执行下去的，死循环便能保证不会被退出，例如，binder 线程也是采用死循环的方法，通过循环方式不同与 Binder 驱动进行读写操作，当然并非简单地死循环，无消息时会休眠。Android是基于消息处理机制的，用户的行为都在这个Looper循环中，我们在休眠时点击屏幕，便唤醒主线程继续进行工作。

主线程的死循环一直运行是不是特别消耗 CPU 资源呢？ 其实不然，这里就涉及到 Linux pipe/epoll机制，简单说就是在主线程的 MessageQueue 没有消息时，便阻塞在 loop 的 queue.next() 中的 nativePollOnce() 方法里，此时主线程会释放 CPU 资源进入休眠状态，直到下个消息到达或者有事务发生，通过往 pipe 管道写端写入数据来唤醒主线程工作。这里采用的 epoll 机制，是一种IO多路复用机制，可以同时监控多个描述符，当某个描述符就绪(读或写就绪)，则立刻通知相应程序进行读或写操作，本质同步I/O，即读写是阻塞的。 所以说，主线程大多数时候都是处于休眠状态，并不会消耗大量CPU资源。

主线程的Looper何时退出

在App退出时，ActivityThread中的mH（Handler）收到消息后，执行退出。

//ActivityThread.java
case EXIT_APPLICATION:
if (mInitialApplication != null) {
mInitialApplication.onTerminate();
}
Looper.myLooper().quit();
break;

如果你尝试手动退出主线程Looper，便会抛出如下异常

Caused by: java.lang.IllegalStateException: Main thread not allowed to quit.
at android.os.MessageQueue.quit(MessageQueue.java:428)
at android.os.Looper.quit(Looper.java:354)
at com.jackie.testdialog.Test2Activity.onCreate(Test2Activity.java:29)
at android.app.Activity.performCreate(Activity.java:7802)
at android.app.Activity.performCreate(Activity.java:7791)
at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1299)
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:3245)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:3409)
at android.app.servertransaction.LaunchActivityItem.execute(LaunchActivityItem.java:83)
at android.app.servertransaction.TransactionExecutor.executeCallbacks(TransactionExecutor.java:135)
at android.app.servertransaction.TransactionExecutor.execute(TransactionExecutor.java:95)
at android.app.ActivityThread H . h a n d l e M e s s a g e ( A c t i v i t y T h r e a d