深入理解android消息机制（五）——主线程handler和looper
分析Handler的构造方法后，我们知道了如果不传入Looper对象，那么将会使用本线程的Looper。这也就解释了在非UI线程中需要首先调用Looper.prepare()，因为在那里创建了Looper对象并保存在了sThreadLocal中；那么问题来了:
在UI线程中初始化的Handler，它的Looper是在哪里赋值的？
主线程ActivityThread中main方法
public static void main(String[] args) {
//与本文无关的代码
...
Looper.prepareMainLooper();
ActivityThread thread = new ActivityThread();
thread.attach(false);////建立Binder通道 (创建新线程)
if (sMainThreadHandler == null) {
sMainThreadHandler = thread.getHandler();
}
if (false) {
Looper.myLooper().setMessageLogging(new
LogPrinter(Log.DEBUG, "ActivityThread"));
}
// End of event ActivityThreadMain.
Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
Looper.loop();
//如果能执行下面方法，说明应用崩溃或者是退出了...
throw new RuntimeException("Main thread loop unexpectedly exited");
}Looper.prepareMainLooper()方法
public static void prepareMainLooper() {
//等同于Looper.prepare()
prepare(false);
synchronized (Looper.class) {
if (sMainLooper != null) {
throw new IllegalStateException("The main Looper has already been prepared.");
}
sMainLooper = myLooper();
}
//============================
public static Looper getMainLooper() {
synchronized (Looper.class) {
return sMainLooper;
}
}Activity的生命周期都是依靠主线程的Looper.loop，当收到不同Message时则采用相应措施：一旦退出消息循环，那么你的程序也就可以退出了。
从消息队列中取消息可能会阻塞，取到消息会做出相应的处理。如果某个消息处理时间过长，就可能会影响UI线程的刷新速率，造成卡顿的现象。
thread.attach(false)方法函数中便会创建一个Binder线程（具体是指ApplicationThread，Binder的服务端，用于接收系统服务AMS发送来的事件），该Binder线程通过Handler将Message发送给主线程。「Activity 启动过程」
比如收到msg=H.LAUNCH_ACTIVITY，则调用ActivityThread.handleLaunchActivity()方法，最终会通过反射机制，创建Activity实例，然后再执行Activity.onCreate()等方法；
再比如收到msg=H.PAUSE_ACTIVITY，则调用ActivityThread.handlePauseActivity()方法，最终会执行Activity.onPause()等方法。
主线程的消息又是哪来的呢？当然是App进程中的其他线程通过Handler发送给主线程
system_server进程是系统进程，java framework框架的核心载体，里面运行了大量的系统服务，比如这里提供ApplicationThreadProxy（简称ATP），ActivityManagerService（简称AMS），这个两个服务都运行在system_server进程的不同线程中，由于ATP和AMS都是基于IBinder接口，都是binder线程，binder线程的创建与销毁都是由binder驱动来决定的。
这涉及到activity启动流程，留待下节探讨，此处暂不深入研究
创建handler
final Handler getHandler() {
return mH;
}
//========================================================
final H mH = new H();
//===================================================
private class H extends Handler {
...
public void handleMessage(Message msg) {
if (DEBUG_MESSAGES) Slog.v(TAG, ">>> handling: " + codeToString(msg.what));
switch (msg.what) {
case LAUNCH_ACTIVITY: {
Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, “activityStart”);
final ActivityClientRecord r = (ActivityClientRecord) msg.obj;
r.packageInfo = getPackageInfoNoCheck(r.activityInfo.applicationInfo, r.compatInfo);
handleLaunchActivity(r, null);
Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
}
break;
case RELAUNCH_ACTIVITY: {
Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, “activityRestart”);
ActivityClientRecord r = (ActivityClientRecord) msg.obj;
handleRelaunchActivity(r);
Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
}
break;
case PAUSE_ACTIVITY:
Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, “activityPause”);
handlePauseActivity((IBinder) msg.obj, false, (msg.arg1 & 1) != 0, msg.arg2, (msg.arg1 & 2) != 0);
maybeSnapshot();
Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
break;
case PAUSE_ACTIVITY_FINISHING:
Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, “activityPause”);
handlePauseActivity((IBinder) msg.obj, true, (msg.arg1 & 1) != 0, msg.arg2, (msg.arg1 & 1) != 0);
Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
break;
//还有很多case
...
}
}
}对于主线程的loop，肯定会有两个疑问，
1、会不会造成anr
anr大家都不陌生
Android的UI控件不是线程安全的，如果在多线程中并发访问可能会导致UI控件处于不可预期的状态，那么为什么系统不对UI控件的访问加上锁机制呢？缺点有两个：
①首先加上锁机制会让UI访问的逻辑变得复杂
②锁机制会降低UI访问的效率，因为锁机制会阻塞某些线程的执行。
所以最简单且高效的方法就是采用单线程模型来处理UI操作。
子线程更新UI的方法，就是转移的主线程
1. 主线程中定义Handler，子线程通过mHandler发送消息，主线程Handler的handleMessage更新UI。
2. 用Activity对象的runOnUiThread方法。
3. 创建Handler，传入getMainLooper。
4. View.post(Runnable r) 。
对于线程即是一段可执行的代码，当可执行代码执行完成后，线程生命周期便该终止了，线程退出。而对于主线程，ActivityThread的main方法主要就是做消息循环，一旦退出消息循环，那么你的应用也就退出了。我们是绝不希望会被运行一段时间，自己就退出，那么如何保证能一直存活呢？简单做法就是可执行代码是能一直执行下去的，死循环便能保证不会被退出。
android是基于时间驱动的，looper.loop()不断接收处理事件，每一个点击触摸或者说activity的生命周期，都是运行在looper.loop()控制之下，如果停止了，应用就停止了，我们常说的anr，只能是某一个消息或者说对消息的处理阻塞了looper.loop()，而不是looper.loop()阻塞它
onCreate/onStart/onResume等操作时间过长，会导致掉帧，甚至发生ANR，looper.loop本身不会导致应用卡死。
比如oncreate和onResume处理耗时操作， 下一次消息，比如点击事件不能处理了，整个循环就会产生卡顿，时间一长就成了anr。
造成anr的原因一般有两个
- 当前时间没有机会得到处理，（主线程正在处理前一个时间，没有及时完成，火车looper被阻塞）
- 当前事件正在处理，没有及时完成
2、会不会消耗cpu资源
这里就涉及到Linux pipe/epoll机制，简单说就是在主线程的MessageQueue没有消息时，便阻塞在loop的queue.next()中的nativePollOnce()方法里，此时主线程会释放CPU资源进入休眠状态，直到下个消息到达或者有事务发生，通过往pipe管道写端写入数据来唤醒主线程工作。这里采用的epoll机制，是一种IO多路复用机制，可以同时监控多个描述符，当某个描述符就绪(读或写就绪)，则立刻通知相应程序进行读或写操作，本质同步I/O，即读写是阻塞的。 所以说，主线程大多数时候都是处于休眠状态，并不会消耗大量CPU资源。