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(调用setMotionEventSplittingEnabled将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事件的传递流程，如果发现文中有何错误，希望不吝赐教！
