Android事件的分发机制

1. Android——消息分发机制

什么是 Handler 机制 ？
Handler 机制是 Android 中用于 线程间通信 的一套通信机制。

为什么是 Handler ？Handler 机制为什么被那么多次的提及 ？
从Android4.0开始，Android 中网络请求强制不允许在主线程中操作，而更新UI的操作则不允许在子线程中执行。当在子线程中执行网络请求，拿到服务器返回的数据之后，要更新UI。由于系统的要求，势必会产生一种矛盾：数据在子线程，更新UI要在主线程。此时我们必须要把数据返回到主线程中才行，Handler机制应运而生。

Android 中针对耗时的操作，放在主线程操作，轻者会造成 UI 卡顿，重则会直接无响应，造成 Force Close。同时在 Android 3.0 以后，禁止在主线程进行网络请求。

针对耗时或者网络操作，那就不能在主线程进行直接操作了，需要放在子线程或者是工作线程中进行操作，操作完成以后，再更新主线程即 UI 线程。这里就涉及到一个问题了，在子线程执行完成以后，怎么能更新到主线程即 UI 线程呢，针对以上问题，就需要用到 Android 的消息机制了，即： Handler, Message, MessageQueue, Looper 全家桶

Handler机制中最重要的四个对象

Handler的构造方法:

Looper :

Handler的使用：

MessageQueue：

Looper.loop()

Handler.dispatchMessage()

handler导致activity内存泄露的原因：
handler发送的消息在当前handler的消息队列中，如果此时activity finish掉了，那么消息队列的消息依旧会由handler进行处理，若此时handler声明为内部类（非静态内部类），我们知道内部类天然持有外部类的实例引用，这样在GC垃圾回收机制进行回收时发现这个Activity居然还有其他引用存在，因而就不会去回收这个Activity，进而导致activity泄露。

假如在子线程执行了耗时操作，这时用户操作进入了其他的 acitvity， 那么 MainActivity 就会被内存回收的，但是这个时候发现 Handler 还在引用着 MainActivity，内存无法及时回收，造成内存泄漏。

Handler 防止内存泄漏常见方法：

为什么通过 Handler 可以把子线程的结果通知或者携带给 UI 线程 ？
这里的 Handler 指的是主线程的 Handler ,同时与 Handler 配套的 Looper ， MessageQueue 是在 UI 线程初始化的，所以在子线程中调用 Handler 发送消息可以更新 UI 线程。
Looper 在 UI 线程源码, 在 ActivityThread 类：

2. android事件分发机制 什么意思

android事件分发机制 就是一个触摸事件发生了，从一个窗口传递到一个视图，再传递到另外一个视图，最后被消费的过程，在android中还是比较复杂的传递流程如下：

(1) 事件从Activity.dispatchTouchEvent()开始传递，只要没有被停止或拦截，从最上层的View(ViewGroup)开始一直往下(子View)传递。子View可以通过onTouchEvent()对事件进行处理。

(2) 事件由父View(ViewGroup)传递给子View，ViewGroup可以通过onInterceptTouchEvent()对事件做拦截，停止其往下传递。

(3) 如果事件从上往下传递过程中一直没有被停止，且最底层子View没有消费事件，事件会反向往上传递，这时父View(ViewGroup)可以进行消费，如果还是没有被消费的话，最后会到Activity的onTouchEvent()函数。

(4) 如果View没有对ACTION_DOWN进行消费，之后的其他事件不会传递过来。

(5) OnTouchListener优先于onTouchEvent()对事件进行消费。

上面的消费即表示相应函数返回值为true。

3. Android-View的事件分发及拦截-父控件和子控件都处理触摸事件的方式

比如接着上篇 Android-View的事件分发及拦截机制简单流程先体验再研究(场景？疑问? 具体？待续...） ，小白现在要实现就是子View和父ViewGroup都响应点击事件。

1. 单纯的都只是响应down事件

这个就很简单了 - 直接子View的**public boolean **onTouchEvent(MotionEvent event) 里面直接返回false就行了。也就是子控件响应了一次down后，接下来就交给父ViewGroup了.(子View就啥几把也干不了了）;

2. 响应down和up事件，move啥的

我们知道子View如果onTouch里面返回了true，那么将会处理后续的move，up事件。而不再交给上层父ViewGroup。那父ViewGroup就没办法在Touch里面处理，所以我们只能放到dispatchTouchEvent或者onInterceptTouchEvent中处理这个down，up等事件：

比如dispatchTouchEvent中：

这样的情况就是父ViewGroup先执行点击事件，然后子View再执行。 如果您需要父ViewGroup晚点，可以延时执行啥的。

如果此时，子View的dispatchTouchEvent返回true - 表示拦截，不继续了

那么子View的所有的事件都不会响应了。其实也就是我们的一个事件先传递，touch再处理的树形图：

网络上拔个图来

简单记录下下而已，继续加深理解...这是上一篇的续，还是上一篇....啧啧....后面是官方文档分析来着...

4. 【Android】ANR是如何产生的

众所周知，Android的输入事件是通过 InputReader 监听系统 dev/input 下的文件来获取输入事件，并由 InputDispatcher 来进行分发的。

而ANR事件就是在 InputDispatcher 中产生的。

InputDispatcher 内部维护了一个线程 InputDispatcherThread ，输入事件在这个线程中进行处理。这个线程在 InputManager 中进行创建和启动。

它只做了一件事，就是无限调用 dispatchOnce() 进行事件分发。

dispatchOnce() 会调用 dispatchOnceInnerLocked() 进行事件分发，而如果判断出当前事件是触摸事件，则会又调用 dispatchMotionLocked() 来分发触摸事件。在处理结束之后，会阻塞直到下一次事件的到来。

dispatchMotionLocked() 会调用 () 查找触摸事件对应窗口目标并进行分发。如果当前窗口尚有未处理完的事件，则会调用 handleTargetsNotReadyLocked 处理。

handleTargetsNotReadyLocked 会判断目标事件等待时间，如果其大于5秒，则会调用 onANRLocked 进入ANR流程。

以上便是ANR的产生过程。

ANR的产生有两个必要条件：

/frameworks/native/services/inputflinger/InputDispatcher.cpp
Android输入事件分发与拦截

5. Android Touch事件分发处理机制详解

Android应用的开发过程不可能不涉及到Touch事件的处理，简单地如设置OnClickListener、OnLongClickListener等监听器处理View的点击事件，复杂地如在自定义View中通过重写onTouchEvent来捕获用户交互事件以定制出各种效果，在使用的过程中或多或少会遇到一些奇怪的Bug，让你对Touch事件“从哪来，到哪去”产生迷之疑惑，经过多少次徘徊之后终于决定系统的分析下源码，本文就给大家分享下我的收获。

MotionEvent作为Touch事件的载体，采用时间片来管理Touch事件所有相关行为的数据，本文这样理解时间片这个概念：

通常MotionEvent会将触发当前事件的Pointer作为主要Pointer，其PointerIndex为0，而MotionEvent通过提供getX()这类不带index参数的接口以更方便的操作主要Pointer的数据。
了解了MotionEvent的组成结构之后，接下来就可以分析MotionEvent包含的事件类型了，MotionEvent通过getAction接口来获取事件Action，而Action中低8位地址存储的是事件类型（对于触摸事件来说，主要包括Down、Move、Up、Cancel、PointerDown、PointerUp），高8位地址存储的是PointerId（当事件类型为PointerDown、PointerUp时）。通常来说事件会以Down开始，以Up或Cancel结束，各事件所承担的角色以及各自的特点在分析事件分发与处理的过程时再详细说明。
另外，MotionEvent中的Flag需要说明一下：

本文仅分析Touch事件在Framework中Java层的传递，因此从事件传递到Activity开始分析。当Touch事件传递给Activity时，会调用Activity.dispatchTouchEvent(MotionEvent)，Activity会将事件传递给其Window进行处理，实际会调用PhoneWindow.superDispatchTouchEvent(MotionEvent)，PhoneWindow会将该事件传递给Android中View层级前埋中的顶层View（即DecorView）进行处理：

在Window未设置Callback的情况下，会调用父类的dispatchTouchEvent，DecorView继承自FrameLayout，然后FrameLayout并未实现dispatchEvent，因此最终调用ViewGroup.dispatchTouchEvent，也就是Touch事件分发的核心逻辑所在，前文中提到MotionEvent中事件类型主要包括Down、Move、Up、Cancel、PointerDown、PointerUp，而dispatchTouchEvent根据事件的不同类型会做不同处理，因此这里分别进行分析：

Down事件处理

非异常情况下，Touch事件的事件周期总是以Down事件开始的，因此Down事件在整个事件分发逻辑中起关键作用，将决定了后续Move、Up及Cancel事件的处理主体，先看一张Down事件分发的流程图：

从流程图中可以看到，Down事件的分发逻辑主要目的在于寻找到能处理该Touch事件的View控件（该View为以当前ViewGroup为Root节点的View层级中的View，利用寻找到的View创建事件处理Target），整个处理逻辑主要包含以下渣悔陆几步：

Move、Up、Cancel事件处理

完成Down事件的分发逻辑后，就确定了该Down事件后续Move、Up及Cancel事件的处理主体（注意：这里并没有确定PointerDown事件的处理主体，关于PointerDown事件的分发逻辑稍后分析），先通过一张流程图来感受下Move、Up、Cancel事件的分发逻辑：

从流程图可以看出，对于Move、Up、Cancel事件的分发步骤如如顷下：

PointerDown事件处理

PointerDown事件是在支持多Pointer(调用将FLAG_SPLIT_MOTION_EVENTS置位)的环境下，当有新的Pointer按下时产生的，该事件处理的特殊性在于会重新遍历View层级，寻找可以处理新Pointer事件的Target，具体流程参考Down事件的分发逻辑；遍历结束若仍没有找到处理该事件的Target，则会将新Pointer的处理权设置给已有Target中最早被添加的Target。完成Target的寻找之后，会将该事件通过dispatchTransformedTouchEvent传递至所有已有Target进行处理，可以通过下面流程图，对PointerDown事件的处理有一个更全局的认识：

PointerUp事件处理

相对于Up事件来说，对于PointerUp事件的处理区别在于当传递至所有已有Target结束之后并不能标记以Down事件起始的整个事件周期结束，仅能标记其关联Pointer（以PointerDown事件起始）的事件周期结束，因此不会清除所有状态，而仅会从已有Target中移除掉与该Pointer相关的部分。

onInterceptTouchEvent

在ViewGroup进行事件分发的过程中，会调用该函数来确定是否需要拦截事件，当该函数返回true时该事件将会被拦截，即不会进行正常的View层级传递，而是直接由该ViewGroup来处理，而拦截后的操作需要根据拦截事件的类型不同而不同：

dispatchTransformedTouchEvent(MotionEvent event, boolean cancel, View child, int desiredPointerIdBits)

在将事件传递给Target进行处理之前会调用该函数对MotionEvent进行处理：

MotionEvent.split(int idBits)

判断一个View控件是否消费一个事件，是由View.dispatchEvent的返回值来决定的，而View.dispatchEvent用于寻找事件的最终消费者，话不多说，还是通过一张流程图来个直观感受：

从流程图中可以看出，View会根据ouch事件对Scroll状态进行调整，并寻找该事件的最终处理器：

View.dispatchEvent将向其直接ViewGroup返回是否消费掉该事件，返回值将决定上级ViewGroup是否需要继续询问其他子View是否需要消费该事件。这就是View中分发事件的逻辑，真是简单粗暴！

从View.dispatchEvent的分析中可以发现当未对View设置mTouchListener或mTouchListener未消费掉该事件时，Touch事件最终将由View.onTouchEvent来决定是否消费，自定义View可以重写该方法实现自身的逻辑，此处仅分析View中的通用处理逻辑：

从上述分析可以很开心地发现熟悉的onClick及onLongClick事件的产生逻辑，若是之前没看过类似的文章，应该会有原来如此的感觉吧，哈哈~~

至此，Touch事件的分发与处理流程算是走通了，个人看完整个源码之后有种豁然开朗的感觉，能很清晰的分析向“为什么事件有时候传到某个View有时候却不传？”、“有时候只传前面几个事件后面却不传了？”等问题，也希望本文的分析能让你更清晰地感知Android中Touch事件的传递流程，如果发现文中有何错误，希望不吝赐教！

6. Android消息机制和原理

Android消息机制及其原理

Handle的原理

andriod提供了Handler和Looper来满足线程间的通信。Handler先进先出原则。Looper类用来管理特定线程内对象之间的消息交换(MessageExchange)。

MessageQueue

MessageQueue是持有Message（在Looper中派发）的一个链表，Message并不是直接添加到MessageQueue中的，而是通过与Looper相关联的Handler来进行的。

用来存放线程放入的消息,读取会自动删除消息，单链表维护，在插入和删除上有优势。在其next()中会无限循环，不断判断是否有消息，有就返回这条消息并移除。

Looper

一个线程可以产生一个Looper对象，由它来管理此线程里的MessageQueue

Looper创建的时候会创建一个MessageQueue，调用loop()方法的时候消息循环开始，loop()也是一个死循环，会不断调用messageQueue的next()，当有消息就处理，否则阻塞在messageQueue的next()中。当Looper的quit()被调用的时候会调用messageQueue的quit(),此时next()会返回null，然后loop()方法也跟着退出。

MessageQueue和Looper是一对一关系，Handler和Looper是多对一

Handler

在主线程构造一个Handler，与Looper沟通，以便push新消息到MessageQueue里;

接收Looper从MessageQueue取出Handler所送来的消息。然后在其他线程调用sendMessage(),此时主线程的MessageQueue中会插入一条message，然后被Looper使用.

Thread

UIthread 通常就是main thread，而Android启动程序时会替它建立一个MessageQueue,系统的主线程在ActivityThread的main()为入口开启主线程，其中定义了一系列消息类型，包含四大组件的启动停止。

消息队列分发算法源码

每个message之间拉手，知道自己前面和后面的message

message通过时间戳来排序，小的在前

配合handle取出message，message时间到，就去除队列首个message，取出之后置为null，第二个message就排在第一，类推

//消息的存放

boolean enqueueMessage(Message msg, long when) {

    synchronized (this) {

        msg.when = when;

        Message p = mMessages;  //注解1

        if (p == null || when == 0 || when < p.when){

            msg.next = p;

            mMessages = msg;    //注解2

        } else {

            Message prev;

            for (;;) {          //注解3

                prev = p;

                p = p.next;

                if (p == null || when < p.when) {

                    break;

                }

            }

            msg.next = p;

            prev.next = msg;

        }

    }

    return true;

}

7. Android事件分发机制

Android中对视图的Touch事件进行分发处理。
单手指操作：ACTION_DOWN -> ACTION_MOVE -> ACTION_UP
多手指操作：ACTION_DOWN -> ACTION_POINTER_DOWN -> ACTION_MOVE -> ACTION_POINTER_UP -> ACTION_UP.

（1） dispatchTouchEvent（） ：事件分发

（2） onInterceptTouchEvent（） ：事件拦截

（3） onTouchEvent（） ：事件处理

ViewGroup 的相关事件有三个：onInterceptTouchEvent、dispatchTouchEvent、onTouchEvent。

View 的相关事件只有两个：dispatchTouchEvent、onTouchEvent。

先分析ViewGroup的处理流程：首先得有个结构模型概念：ViewGroup和View组成了一棵树形结构，最顶层为Activity的ViewGroup，下面有若干的ViewGroup节点，每个节点之下又有若干的ViewGroup节点或者View节点，依次类推。如图：

点击事件达到顶级 View(一般是一个 ViewGroup)，会调用 ViewGroup 的 dispatchTouchEvent 方法，如果顶级 ViewGroup 拦截事件即 onInterceptTouchEvent 返回 true，则事件由 ViewGroup 处理，这时如果 ViewGroup 的 mOnTouchListener 被设置，则 onTouch 会被调用，否则 onTouchEvent 会被调用。也就是说如果都提供的话，onTouch 会屏蔽掉 onTouchEvent。在 onTouchEvent 中，如果设置了 mOnClickListenser，则 onClick 会被调用。如果顶级 ViewGroup 不拦截事件，则事件会传递给它所在的点击事件链上的子 View，这时子 View 的 dispatchTouchEvent 会被调用。如此循环。