Handler异步与同步执行的巧妙之处

最近突然想起Handler这个设计，再结合Python，JavaScript，RxJava这些经常遇到的一些回调好像是执行在一个异步线程，但实际不是。之后突然想到一个问题，Android应用UI线程实际就是ActivityThread的Main函数中执行，大家都知道在一个应用进程创建时就会执行Main函数，同时会初始化一个基于mainThread的Handler，同时这个线程进入

Looper.loop();

无线循环！！！

那么此时问题出来了，既然UI线程一直运行在死循环中，为什么我们应用程序却能和我们相互交互。如果这个Looper.loop()是运行再HandlerThread中那就很好理解了，但问题不是啊！

当然大家都会想到应用程序能和我们做交互就是通过Handler啊，但是具体这个原理是怎么样的，相信一般人首先会丈二和尚摸不着头脑，二般的人就不必浪费时间往下看了哈哈哈

 

好，我带着这个好奇进源码翻了一圈，现在总结如下

1、Handler如果是一个异步的话，那因为Looper.loop()执行再异步线程中，所以对我们来说很好理解。

2、UI上的Handler主要是因为一个应用进程在最初创建时，由launcher启动，下面做一个列表更好说明

Launcher ——> startActivity  // Launcher进程中

通过Binder切换到AMS进程 startActivity  // AMS进程

在AMS进程中会先从Zygote fork一个应用进程出来  // AMS进程

此时进入了ActivityThread Main 函数中  // 进入应用进程，同时Handler循环开启

继续执行一些应用的初始化工作，Application，Instrumentation,Context，Activity 的初始化工作，这里已经开始
通过BInder使用Handler进行初始化了  // 这里执行在AMS进程中，通过binder切换到Handler

切换到Handler后会回调Application、Activity的回调方法（onCreate,onResume等）// 此时通过Handler回到了UI线程

好，以上一言以蔽之，大概意思就是，UI线程处于无限循环，但还可以与我们进行交互的主要原因就是应用最初创建时由于AMS进程的参与给了UI线程的回调，有了这个开始那UI线程就可以开始之后与我们进行交互了通过Handler

转载于:https://my.oschina.net/u/3336230/blog/1571262