‘壹’ 深入分析android-Handler消息机制
Handler是Android消息机制的上层接口。通过它可以轻松地将一个任务切换到Handler所在的线程中去执行。通常情况下，Handler的使用场景就是 更新UI 。
在子线程中，进行耗时操作，执行完操作后，发送消息，通知主线程更新UI。
Handler消息机制主要包括： MessageQueue 、 Handler 、 Looper 这三大部分，以及 Message 。
从上面的类图可以看出：
MessageQueue、Handler和Looper三者之间的关系： 每个线程中只能存在一个Looper，Looper是保存在ThreadLocal中的。 主线程（UI线程）已经创建了一个Looper，所以在主线程中不需要再创建Looper，但是在其他线程中需要创建Looper。 每个线程中可以有多个Handler，即一个Looper可以处理来自多个Handler的消息。 Looper中维护一个MessageQueue，来维护消息队列，消息队列中的Message可以来自不同的Handler。
在子线程执行完耗时操作，当Handler发送消息时，将会调用 MessageQueue.enqueueMessage ，向消息队列中添加消息。 当通过 Looper.loop 开启循环后，会不断地从消息池中读取消息，即调用 MessageQueue.next ， 然后调用目标Handler（即发送该消息的Handler）的 dispatchMessage 方法传递消息， 然后返回到Handler所在线程，目标Handler收到消息，调用 handleMessage 方法，接收消息，处理消息。
从上面可以看出，在子线程中创建Handler之前，要调用 Looper.prepare() 方法，Handler创建后，还要调用 Looper.loop() 方法。而前面我们在主线程创建Handler却不要这两个步骤，因为系统帮我们做了。
初始化Looper ：
从上可以看出，不能重复创建Looper，每个线程只能创建一个。创建Looper，并保存在 ThreadLocal 。其中ThreadLocal是线程本地存储区（Thread Local Storage，简称TLS），每个线程都有自己的私有的本地存储区域，不同线程之间彼此不能访问对方的TLS区域。
开启Looper
创建Handler ：
发送消息 ：
post方法：
send方法：
‘贰’ Android消息队列浅析
当面试官问到你消息对列的时候，恭喜你，已经跨过初级，在试探你的中级水平了。
Android的消息循环是参考Windows的消息循环机制来实现的。
消息队列4件套 Message、MessageQueue、Looper、Handler
1、Message 是消息对列的消息实体类，因为消息队列中会存放最多10个Message对象。常用属性 what，是消息体的Tag，用来区分是那个一消息体。
2、 MessageQueue 先进先出”的原则存放消息，将Message对象以链表的方式串联起来。
3、Looper 是MessageQueue的管理者，主线程中是一对一的关系。子线程需要用到消息对列的话就需要经典二人组 。先调用 Looper.prepare()方法，然后再调用Looper.loop()；
4、Handler 是封装和处理Message对象的。
通过源码可知消息走向如下
handler.sendMessage()-->handler.sendMessageDelayed()-->handler.sendMessageAtTime()-->msg.target = this;queue.enqueueMessage==>把msg添加到消息队列中
‘叁’ 详解Android消息机制之Message
在分析Message这个类之前,有必要先看看它的类注释其中有这么一段话：
从这段话得知，尽管Message本身的构造方式是公共的，但实现Message对象的最好方法确实是通过Message.obtain()函数返回，或者通过Handler.obtainMessage()方法，查看其最终还是调用了obtain函数。
如果使用new来实现我们初步的推测，应该是会构建大量的Message对象，对内存有一定的影响。
在这还是先看一下谷歌给这个函数的注释：
从obtain函数的注释中也能看出其作用就是用避免大量的构建Message对象，但它是究竟是如何处理的呢？带着疑问查看obtain函数：
实现很简单：
但看到这里还是很模糊，虽然sPool看上去像一个消息池，但再仔细看居然是一个Message对象，这样真的就能避免多次构建Message对象吗？继续看会发现一个next字段，再看它的注释 sometimes we store linked lists of these things ，Message的消息池原来是一个链表，如下图所示 。
每一个Message 对象通过next指向下一个Message（最后一个Message的next为null)形成一个链表，Message对象就成了一个可用的Message池。
到这终于知道Message对象原来是从链表中获取的，但还有一个疑问：Message对象是什么时候放入链表中的呢？从obtain函数并没有看见存储Message的操作。这时候又要回到文章开头的那段类注释的最后一句话： which will pull them from a pool of recycled objects。
消息池是一些回收的对象，也就是说Message对象是在回收的时候将其添加到链表中的。通过查看在Message中有个recycle方法：
在recycleUnchecked函数中会先清空该消息的各个字段，并且把flags设置为FLGA_IN_USE，表明该消息已经被使用了。然后判断是否要将消息回收到消息池中，如果池的大小小于MAX_POOL_SIZE,就将自身添加到链表的表头，sPoolSize++。
例如最开始的开始的时候链表中没有任何消息，将第一个Message对象添加到表中，此时的sPool为空，因此next也为空，sPool又指向this，这时sPool就指向当前这个被回收的Message对象，sPoolSize加1。我们把这个Message命名为m1，这时的链表应该如下：
如果再次插入一个名为m2的Message，那么m2将被插入表头，sPool指向m2,这时sPool的链表中结构如下：
对象池默认的大小为50，如果池的大小小于50，被回收的消息将会被插入到链表头部。
如果池中有元素，这时候再调用obtain函数时，实际上是就获取链表中表头的元素，也就是sPool。再把sPool指针往后移动一个。在obtain汉中，首先会声明一个Message对象m,并且让m指向sPool.sPool实际上指向了m2,因此m实际上指向的也是m2,这里相当于保持了m2这个元素。下一步是sPool指向m2的下一个元素，也就是m1。sPool也完成后移之后此时把m.next置空，也就相当于m2.next变成了null。最后就是m指向了m2元素，m2的next为空，sPool从原来的表头m2指向了下一个元素m1，最后将对象的元素减1，这样m2就顺利的脱离了消息池队伍，就返回给了调用obtain函数的。
‘肆’ Android 系统运行机制 【Looper】【Choreographer】篇
目录：
1 MessageQueue next()
2 Vsync
3 Choreographer doFrame
4 input
系统是一个无限循环的模型， Android也不例外，进程被创建后就陷入了无限循环的状态
系统运行最重要的两个概念：输入，输出。
Android 中输入 输出 的往复循环都是在 looper 中消息机制驱动下完成的
looper 的循环中， messageQueue next 取消息进行处理， 处理输入事件， 进行输出， 完成和用户交互
应用生命周期内会不断 产生 message 到 messageQueue 中， 有： java层 也有 native层
其中最核心的方法就是 messageQueue 的 next 方法， 其中会先处理 java 层消息， 当 java 层没有消息时候， 会执行 nativePollOnce 来处理 native 的消息 以及监听 fd 各种事件
从硬件来看， 屏幕不会一直刷新， 屏幕的刷新只需要符合人眼的视觉停留机制
24Hz ， 连续刷新每一帧， 人眼就会认为画面是流畅的
所以我们只需要配合上这个频率， 在需要更新 UI 的时候执行绘制操作
如何以这个频率进行绘制每一帧： Android 的方案是 Vsync 信号驱动。
Vsync 信号的频率就是 24Hz ， 也就是每隔 16.6667 ms 发送一次 Vsync 信号提示系统合成一帧。
监听屏幕刷新来发送 Vsync 信号的能力，应用层 是做不到的， 系统是通过 jni 回调到 Choreographer 中的 Vsync 监听， 将这个重要信号从 native 传递到 java 层。
总体来说 输入事件获取 Vsync信号获取 都是先由 native 捕获事件 然后 jni 到 java 层实现业务逻辑
执行的是 messageQueue 中的关键方法： next
next 主要的逻辑分为： java 部分 和 native 部分
java 上主要是取java层的 messageQueue msg 执行， 无 msg 就 idleHandler
java层 无 msg 会执行 native 的 pollOnce@Looper
native looper 中 fd 监听封装为 requestQueue， epoll_wait 将 fd 中的事件和对应 request 封装为 response 处理， 处理的时候会调用 fd 对应的 callback 的 handleEvent
native 层 pollOnce 主要做的事情是：
vsync 信号，输入事件， 都是通过这样的机制完成的。
epoll_wait 机制 拿到的 event ， 都在 response pollOnce pollInner 处理了
这里的 dispatchVsync 从 native 回到 java 层
native：
java：
收到 Vsync 信号后， Choreographer 执行 doFrame
应用层重要的工作几乎都在 doFrame 中
首先看下 doFrame 执行了什么：
UI 线程的核心工作就在这几个方法中：
上述执行 callback 的过程就对应了图片中 依次处理 input animation traversal 这几个关键过程
执行的周期是 16.6ms， 实际可能因为一些 delay 造成一些延迟、丢帧
input 事件的整体逻辑和 vsync 类似
native handleEvent ，在 NativeInputEventReceiver 中处理事件， 区分不同事件会通过 JNI
走到 java 层，WindowInputEventReceiver 然后进行分发消费
native :
java:
input事件的处理流程：
输入event deliverInputEvent
deliver的 input 事件会来到 InputStage
InputStage 是一个责任链， 会分发消费这些 InputEvent
下面以滑动一下 recyclerView 为例子， 整体逻辑如下：
vsync 信号到来， 执行 doFrame，执行到 input 阶段
touchEvent 消费， recyclerView layout 一些 ViewHolder
scroll 中 fill 结束，会执行 一个 recyclerView viewProperty 变化， 触发了invalidate
invalidate 会走硬件加速， 一直到达 ViewRootImpl ， 从而将 Traversal 的 callback post choreographer执行到 traversal 阶段就会执行
ViewRootImpl 执行 performTraversal ， 会根据目前是否需要重新layout ， 然后执行layout， draw 等流程
整个 input 到 traversal 结束，硬件绘制后， sync 任务到 GPU ， 然后合成一帧。
交给 SurfaceFlinger 来显示。
SurfaceFlinger 是系统进程， 每一个应用进程是一个 client 端， 通过 IPC 机制，client 将图像显示工作交给 SurfaceFlinger
launch 一个 app：
‘伍’ 消息机制
Android的消息机制是指Handler的运行机制以及Handler所附带的MessageQueue和Looper的工作过程。Handler的主要作用是将一个任务切换到某个指定的线程中去执行。
Android规定访问UI只能在主线程中进行，如果在子线程中访问UI，那么程序就会抛出异常。
主线程即UI线程，它就是ActivityThread，ActivityThread被创建时就会初始化Looper，这也是主线程中默认可以使用Handler的原因。
1.Handler创建时会采用当前线程的Looper来构建内部的消息循环系统，Handler通过ThreadLocal来获取当前线程的Looper，ThreadLocal作用是可以在每个线程中存储数据；
2.Handler创建完毕后，这个时候其内部的Looper以及MessageQueue就可以和Handler一起协同工作了，通过Handler的post方法将一个Runnable投递到Handler内部的Looper中去处理，也可以通过Handler的send方法发送一个消息，这个消息同样会在Looper中处理；
3.当Handler的send方法被调用时，它会调用MessageQueue的enqueueMessage方法将这个消息放入消息队列，Looper发现有新消息到来时，就会处理这个消息，最终消息中的Runnable或者Handler的handleMessage方法就会被调用。
4.Looper是运行在创建Handler所在的线程中，这样Handler中的业务逻辑会被切换到创建Handler所在的线程中去执行了。
ThreadLocal是一个线程内部的数据存储类，通过它可以在指定的线程中存储数据，数据存储之后，只有在指定线程中可以获取到存储的数据，对于其他线程来说则无法获取到数据。
使用场景：android源码中会使用如Looper，ActivityThread，AMS中都手宽消用到了ThreadLocal还有就是复杂逻辑下的对象传递，比毕知如监听器的传递。
MessageQueue主要包含两个操作，插入和读取分别对应enqueueMessage
和next，enqueueMessage的作用是往消息队列中插入一条消息，而next的作用是从消息队列中取出一条消息并将其从消息队列中移除。它是通过一个单链表的数据结构来维护消息列表。
消息循环，它会不停地从MessageQueue中查看是否有新消息，如果有新消息就会立刻处理，否则就一直阻塞在那里。
通过Looper.prepare()即可以为当前线程创建一个Looper，接着通过Looper.loop()来开启消息循环。
Looper除了prepare方法外，还提供了prepareMainLooper方法，这个方法主要是给主线程也就是ActivityThread创建Looper使用的，其本质也是通过prepare方法来实现的。Looper提供了getMainLooper方法，通过它可以在任何地方获取到主线程的Looper，Looper也可以退出，提供了quit和quitSafely方法。
Looper的loop方法是一个死循环，唯一跳出循环的方式是MessageQueue的next方法返回了null；当Looper的quit方法被调用时，Looper就会调用MessageQueue的quit或者quitSafely方法来通知消息队列退出，当消息队列被标记为退出状态时，它的next方法就会返回null。
loop方法会调用MessageQueue的next方法来获取新消息，而next是一个阻塞操作，当没有消息时，next方法会一直阻塞在那，这也导致了loop方法一直阻塞在那。
Android的主线程就是ActivityThread，主线程的入口方法为main，在main方法中系统会通过Looper.prepareMainLooper()来创建主线程的Looper以及MessageQueue，并通过Looper.loop()来开启主线程的消息循环。
主线程的消巧埋息循环开始了以后，ActivityThread还需要一个Handler来和消息队列进行交互，这个Handler就是ActivityThread.H,它内部定义了一组消息类型，主要包括了四大组件的启动和停止过程。
ActivityThread通过ApplicationThread和AMS进行进程间通信，AMS以进程间通信的方式完成ActivityThread的请求后会回调ApplicationThread中的Binder方法，然后ApplicationThread会向H发送
消息，H接收消息后会将ApplicationThread中的逻辑切换到ActivityThread中去执行，即切换到主线程中去执行，这个过程就是主线程的消息循环模型。
在子线程执行完耗时操作，Handler通过sendMessage发送消息后，会调用MessageQueue.enqueueMessage方法向消息队列中添加消息，然后Looper调用loop()方法开启循环后会不断地从消息队列中读取消息，然后调用目标Handler的dispatchMessage方法传递消息，然后回到Handler所在线程，目标Handler收到消息，调用handleMessage方法，接收消息，处理消息。
每个线程中只能存在一个Looper，Looper是保存在ThreadLocal中的。主线程（UI线程）已经创建了一个Looper，所以在主线程中不需要再创建Looper，但是在其他线程中需要创建Looper。每个线程中可以有多个Handler，即一个Looper可以处理来自多个Handler的消息。 Looper中维护一个MessageQueue，来维护消息队列，消息队列中的Message可以来自不同的Handler。