前序
本文将会把一下三个问题阐述清楚以及一个网上的普遍观点的补充：
1，安卓 APP 启动过程，对于Activity 的 onCreate 等生命周期的函数为什么不会因为 Looper.loop()里的死循环卡死而永无机会执行。
2，在 1 的基础上，View 的绘制到底是怎样完成的，它又为什么不会因为 Looper.loop()里的死循环卡死而永无机会刷新。
3，网传的观点大概如下：
1.handler机制是使用pipe来实现的
2.主线程没有消息处理时阻塞在管道的读端
3.binder线程会往主线程消息队列里添加消息，然后往管道写端写一个字节，这样就能唤醒主线程从管道读端返回，也就是说queue.next()会调用返回
4.dispatchMessage()中调用onCreate, onResume
4，子线程真的不能刷新 UI ?
其次，最终的内容我将放到两张图片上面去展示出来，源码的分析这里将不再累赘去说。第一部分网上很多，第二部分网上零散，我是通过源码分析书籍总结出来的。
告知答案，再放直观图片，最后文字辅助解析的顺序。
解答第一个问题
此部分的源码分析，网上很多，搜索关键字，ActivityThread，Activity 的 onCreate 在哪调用等。
总结： Activity 的 生命周期函数都是在 Looper 里面的死循环中被 ActivityThread 内部的 Handler 的 handleMessage 入口调用的，本身在循环里面调用，也就不会被阻塞，在 onCreate 等函数里面发送一个 message 也是会到这里被处理掉，仍然互不影响。
先上图， 看不懂，结合后面文字看，或者源码。
文字解析， 仅描述重点：
APP 的启动过程很复杂，但是最终的入口会在 ActivityThread 类里面的 main 函数，在这个函数里面，首先会调用 Looper.prepare 目的是实例化一个 looper 对象，方便后续的主线程中的 handler 实例化获取并使用。
因为 Handler 的消息发送和处理机制是基于 Looper 里面 MessageQueue 的，所以得先存在looper。
mAppThread Binder实例以及一个H Handler实例，当 H 发送或处理下消息的时候，使用的Looper就是上面实例化的。然后是它自身的 attach(...)函数，在内部进行AMS(ActivityManagerSevice)和mAppThread Binder进程通讯者的绑定，即是AMS的attachApplication(...)的调用。
随后调用AMS的attachApplicationLocked(...)，在这个函数里面，将会进行第一次跨进程通讯，AMS运行在系统进程，而我们的APP是另外一个进程。此时在AMS里面会调用我们上面绑定的mAppThread binder对象的bindApplication(...)方法，触发BIND_APPLICATION消息，该消息由 H 来进行发送，也就是 sendMessage(...)，此时消息会在 Looper 里面的 loop() 进行处理。
像 Handler 源码一样，最后会在 H.handleMessage(...) 处理， 然后就是进入到对应的函数里面进行 Context 的初始化，Application开始初始化，并且调用它的 onCreate，等其他操作。
上面为第一部分，接下来是第二部分。在AMS的attachApplicationLocked(...)函数里面，在触发了第一次进程通讯后，代码接着运行，会在里面进行第二次的进程通讯，首先是Activity的栈管理者之一ActivityStackSupervisor调用它的attachApplicationLocked(...)，在里面调用 realStartActivityLocked(...)，然后是正式发起第二次IPC，触发 LAUNCH_ACTIVITY 消息，一样是 H 发送和处理，处理处调用 performLaunchActivity(...)，在这里面，根据一直传下来的信息，将会 new 一个 Actiivity，然后就是调用它的 onCreate，onStart。
第二个问题
声明： 此部分的内部十分地复杂！包括下面的图与文字解析在内，仅作抛砖引玉，是个人总结的大概流程。关于源码分析，网上很零散，十分建议看源码分析类书籍。
总结：View 的底层绘制是基于Binder进程通讯触发，由底层 SurfaceFlinger 的工作线程中的事件机制，包含 handler ，looper，messageQueue 来进行接收、处理，它和 ActivityThread 的 Handler 没关系，即是与 ActivityThread 几乎无关，但是如果在ActivityThread 里面调用 View的相关函数，例如 handleMessage 的一个 setText(..)，最终触发到View其它底层函数，它将会将这些信息发送到 SurfaceFlinger 的事件机制中去，被对应处理，最终刷新到界面。
文字解析， 里面所有函数和变量都是底层C++代码 的。Android 的GUI系统，也是图形界面系统，其依赖于OpenGL,EGL 等函数库，同时Android硬件HAL层的接口Composer的直接使用者是SurfaceFlinger，SurfaceFlinger，对于OpenGL而言，是一个很重要 ”应用“，它依赖于OpenGL,EGL的函数库，并使用他们的API来进行图形的最终绘制。
SurfaceFlinger 在启动时会先进行自己内部的一个工作线程实例化和运行，该线程在后面承担着整个的绘制事件流程，在运行该线程时，会先进行MessageQueue内部的 looper 和 handler 的实例化，然后再 Run，Run 内部启动了事件的循环。
从这一刻开始，它将进入到 waitForEvent(...)方法，这里是个死循环，并在里面调用 waitMessage(...)，waitMessage 里面将会调用 looper的pollOnce(...)，该方法和 ActivityThread 的 loope() 内部的 next() 里面的 queue.next() 差不多，不同的是 pollOnce(...) 会调用 MessageQueue 内部的函数 eventReceiver(...) 。
对应的VSync 消息，那么将会对其进行下一步的分发，就是 dispatchInvalidate(...) 或 dispatchRefesh(...)，最后会进入到 handler 的 handlMessage，然后回调 SurfaceFlinger 的 onMessgeReceiver(...)，内部再调用 handleMessageRefresh(...)。
然后是 SurfaceFlinger 的 layer层对View改变的绘制，绘制结合 NativeWindow 和 FrameBuffer 的缓存技术，最终将结果呈现到终端。代码非常复杂。
第三个补充
网上对于博文标题的这个问题的解析普遍是：见前序的第三点，这里要补充的是，如果是 View 的 UI 刷新，不会导致阻塞的原因是本文的第二个解释，View 的绘制与 Java 代码的looper无关，而是由底层 SurfaceFlinger 自身的事件处理机制处理的。对于第一个问题的解析，那么可以参考前序第三点的内容。
第四个问题
子线程不能刷新UI，这样是否和上面说的冲突呢？其实不然，看下下面的代码片段，它是源码里面限制我们在子线程刷新UI的。
1 void checkThread() {
2
3 if (mThread != Thread.currentThread()) {
4
5 throw new CalledFromWrongThreadException(
6
7 "Only the original thread that created a view hierarchy can touch its views.");
8
9 }
10
11 }
代码第三行，其中 mThread 是创建 ViewRootImpl 的线程，而ViewRootImpl是在主线程中创建的，所以，我们习惯地称它为主线程，mThread和当前代码运行的线程来做了个等式运算，相同就出错，也就是说，并不是子线程不能刷新UI，准确来说，是发送进行 UI 刷新消息的消息，因为真正的底层刷新也不是当前 APP 的主线程。而是限制了，如果当ViewRootImpl是由子线程创造的，那么就可以在该子线程中发送更新UI的消息，自然地就能更新了，那么为什么限制呢?
因为不光是gui，同样的道理在几乎所有编程领域里都是这样的，这背后是线程同步的开销问题。显然两个线程不能同时draw，否则屏幕会花；不能同时insert map，否则内存会花；不能同时write buffer，否则文件会花。需要互斥，比如锁。结果就是同一时刻只有一个线程可以做ui。那么当两个线程互斥几率较大时，或者保证互斥的代码复杂时，选择其中一个长期持有其他发消息就是典型的解决方案。所以普遍的要求ui只能单线程。
