1.2 事件传递流程
首先我们要明确一个概念：所有的触摸事件都会到达
Activity，Activity内部通过Window连接着一个View的根布局DecorView，事件会从Activity一层一层传递到最内层的View
基于上面的传递流程来分析一个实际问题，如下图所示，ViewGroup内部包含一个子View，二者都可点击，而用户希望指哪打哪，所以点击A处时需要ViewGroup响应，点击B处时需要View响应。但是当点击View时怎么保证ViewGroup不会响应？事情有点复杂。这时候我们需要借助一种设计思想递归。
因为View的优先级是高的，所以当事件来临时ViewGroup先不做处理直接传递到子View，此过程为递归中的递，当子View拿到事件后判断是否需要消费此事件，然后把消费结果传递给ViewGroup，ViewGroup拿到事件后判断是否已经被子View消费，如果已经被消费自己就没有权限处理这个事件了，否则做和子View相同的操作然后把结果传递给父View，这样逐层进行直到根布局，此过程为递归中的归。用两张图做一下表示：
注意点
- 一个
View需要消费一组事件也即是自己来处理这组事件，并且一组事件只能被消费一次。- 一组触摸事件分为
按下、移动、抬起，称之为一个事件序列，其中移动事件会有多个。当一个View决定自己消费一组事件需要在按下时就给出结果，反之如果在按下时决定消费意味着这一组事件序列均由自己消费。
1.3 滚动模型的设计
如果仅仅是处理点击事件用上面的方案没有任何问题，可是我们的屏幕还可以滑动啊，而且用户希望既可以点击又可以滑动。如果子View需要能点击，父View需要能滑动怎么办？因为一组事件只能被消费一次，如果子View消费了父View就没有权限处理了，所以基于上面的方案点击和滑动只能二选其一，害...白忙活~~ 先别急着走，往下看...
首先事件必然是从ViewGroup流向View,所以主动权还是在ViewGroup，如果ViewGroup判断出事件在滚动，不管子View是否消费事件，直接把事件拦截然后自己进行消费，看似可行。可是仔细思考后会带来一系列问题，如下：
View在点击的时候可以设置点击背景，按下时背景设置为深色，抬起背景恢复正常，比如微信聊天列表的item。这种情况下如果ViewGroup直接拦截即便事件结束View的背景色始终无法恢复正常。其实引发的问题不止这一个，我们只需要知道这样做不行就可以了。
哎呀，这可如何是好... 硬刚不行能不能来一手曲线救国？接着上面的思路往下分析，假如ViewGroup在判断出要滑动时给子View发送一个特殊的事件(偷偷告诉你，其实就是CANCEL事件)，子View收到这个特殊事件时把已经消费的事件作废，这样做是真的没啥问题了。不信接着看微信聊天列表，是不是按下有一个深色背景，一开始滑动就恢复正常了。
1.4 滑动冲突的解决方案
完美无瑕的外表下其实内心千疮百孔，你不会真的以为碰到滚动就拦截，这样就万事大吉了吧？少年你还是太年轻。如果ViewGroup和其父ViewGroup同时需要滚动呢？诶，好像不太对劲...
场景一
ViewPager嵌套ScrollView，当用户垂直方向滑ScrollView时滑着滑着滑歪了然后滑动就切换到了水平方向，这是非常有可能的，因为用户不可能玩手机时小心翼翼的搁那滑。按照1.3的方案这时会出现一点小问，用户：“本来我垂直方向滑的好好地，手指稍微一偏你就给我切换到水平滑动了，敏感过头了吧，我要换手机。”
其实这种问题很好解决，可惜面试的时候好多人都答不上来。ScrollView滚动时只需要给父View以及爷爷View发一个通知告诉他们：“我要开始滚动了，请不要拦截我”，OK，问题结局。
场景二
上面我们描述的是非同向滑动。关于同向滑动一直是一个比较难解决的问题，以至于Google花了三个版本的迭代才推出了一个相对稳定的NestedScrolling，这是基于事件分发扩展出来的一个专门用于解决滑动冲突的，关于NestedScrolling东西蛮多，感兴趣的同学可自行了解。
2. 源码解析
其实上一小节我已经把事件分发的原理描述的很清楚了，再去看事件分发源码应该会很轻松。另外读源码要懂得抽丝剥茧，如果非要把try catch之类的也要掰持清楚，那可有的折腾了。比如我们今天要阅读的事件分发源码，我会剥去大部分代码，只会找到关键一小部分，我们的目的是把原理搞明白。如果对其他部分代码也感兴趣可单独阅读。
关于前面提到的三大方法也就是传递、拦截、消费分别对应dispatchTouchEvent、onInterceptTouchEvent、onTouchEvent，其中onInterceptTouchEvent为ViewGroup独有，相信大家应该都很清楚在这就不多做赘述了。
另外Activity在事件分发的过程中与ViewGroup充当的角色类似，就不单独描述了。
2.1 事件传递
View和ViewGroup中存在dispatchTouchEvent，其中ViewGroup对其进行了复写。
View 的 dispatchTouchEvent()
其实View在事件分发中做的事情很简单，基本可以用三行代码概括
public boolean dispatchTouchEvent(MotionEvent event) { return onTouchEvent(event) }
View的dispatchTouchEvent方法本来就很短，把一些细节撇去基本和上面三行代码等价。
ViewGroup 的 dispatchTouchEvent()
关于事件分发的大部分细节都隐藏在ViewGroup 的 dispatchTouchEvent中，所以没办法，我也要开始大篇幅贴代码了...
提示：
关于TouchTarget：如果触摸的区域没有子View、子View不消费事件、子View收到了cancel事件，那么ViewGroup的mFirstTouchTarget会为null。弄清楚这个很重要，TouchTarget衔接了很多重要信息。
public boolean dispatchTouchEvent(MotionEvent ev) { boolean handled = false;//声明消费结果 final int action = ev.getAction(); final int actionMasked = action & MotionEvent.ACTION_MASK; // 1 if (actionMasked == MotionEvent.ACTION_DOWN) { //清理touchTarget cancelAndClearTouchTargets(ev); //清理上一次的事件序列，保证新事件序列的纯洁度 resetTouchState(); } ... ... // 2 final boolean intercepted;//声明预拦截 //ACTION_DOWN(第一次事件不能进行拦截，要给子View一次机会) || mFirstTouchTarget(触摸到了子View)不为空 if (actionMasked == MotionEvent.ACTION_DOWN || mFirstTouchTarget != null) { //子View是否申请对其不拦截 final boolean disallowIntercept = (mGroupFlags & FLAG_DISALLOW_INTERCEPT) != 0; //子View没有申请对其不拦截 if (!disallowIntercept) { intercepted = onInterceptTouchEvent(ev); ev.setAction(action); } else { intercepted = false; } } else { intercepted = true; } ... //此处巴拉巴拉一大堆代码，其实就是对TouchTarget做处理。大概内容就是如果：触摸的区域没有子View、子View不消费事件、 //子View收到了cancel事件(父View发的)，这三个种条件满足任意一种父View的mFirstTouchTarget都会变为null。 ...
//3 //如果给子View发送cancel事件后mFirstTouchTarget会变null， final boolean canceled = resetCancelNextUpFlag(this)||actionMasked == MotionEvent.ACTION_CANCEL; //mFirstTouchTarget == null等价于没有子View消费事件 if (mFirstTouchTarget == null) { //没有TouchTarget，第三个参数直接传null。此处会间接调用自己的onTouchEvent handled = dispatchTransformedTouchEvent(ev, canceled, null, ViewGroup.TouchTarget.ALL_POINTER_IDS); } else { ... //如果收到cancel事件 || 被拦截。 final boolean cancelChild = resetCancelNextUpFlag(target.child) || intercepted; if (dispatchTransformedTouchEvent(ev, cancelChild, target.child, target.pointerIdBits)) { handled = true; } } return handled; }
作者花了很长时间才把300行的代码精简到60行，过滤掉的代码不是说没用，只是跟事件分发的流程关系不太大，全部贴出来只会给大家徒添困扰。我们读源码不就是为了搞清楚本质吗，所以不要为了读而读。
关于精简代码我也给分成了四部分(步骤见注释 //1,2,3)，我们来逐步分析：
第一步：
首先在donw事件来临时执行了两个方法，
cancelAndClearTouchTargets方法用于重置touchTarget。resetTouchState方法用于重置上一次的事件序列，保证新的时间序列的纯洁度
第二步：
第二步用于做拦截处理。首先外层有两个判断条件，第二个条件意思是
mFirstTouchTarget不为空，也就是子View要消费事件，而第一个意为在DOWN事件来临时先不拦截，给子View一个机会，因为DOWN事件来临时mFirstTouchTarget肯定时null。内部的逻辑大概就是，如果子view没有申请对它不拦截，就执行自己的onInterceptTouchEvent并把结果返回给intercepted
第三步：
关于第三步的代码，其实很长很长，内部巴拉巴拉一大堆，逻辑相当复杂，我精简掉的大部分代码也都是在这个步骤，为了不给大家徒添困扰，我是废了好大力气才提炼出这几行代码。总的来说就是执行
dispatchTransformedTouchEvent来拿到事件的消费结果，调度子View的事件也是通过这个方法进行的。需要注意的一点：当ViewGroup确定拦截事件时不会立即执行，而是先将mFirstTouchTarget置为null，下一个事件到来时再自己处理。代码含义我在注释中已经写的很清楚，就不多做赘述。
下面来看一下dispatchTransformedTouchEvent这个方法的源码：
//第二个参数cancel包含两种含义，一种是外部收到了取消事件，另一种是事件被拦截 private boolean dispatchTransformedTouchEvent(MotionEvent event, boolean cancel, View child, int desiredPointerIdBits) { final boolean handled; // 1 //做取消事件的处理 final int oldAction = event.getAction(); if (cancel || oldAction == MotionEvent.ACTION_CANCEL) { event.setAction(MotionEvent.ACTION_CANCEL); //没有子view，自己执行super 也就是 View 的 dispatchTouchEvent 并将ACTION_CANCEL事件传递进去 if (child == null) { handled = super.dispatchTouchEvent(event); } else { //将cancel事件传递给子View。下一个事件传递时父View的TouchTarget会变为null handled = child.dispatchTouchEvent(event); } event.setAction(oldAction); return handled; } ... ... // 2 // 没有子View 执行View 的 dispatchTouchEvent 也就是执行自己的onTouchEvent if (child == null) {//基本等价于TouchTarget为null handled = super.dispatchTouchEvent(transformedEvent); } else { ... //拿到子 View 的 dispatchTouchEvent 的返回值(也即是消费结果)
结尾
我还总结出了互联网公司Android程序员面试涉及到的绝大部分面试题及答案，并整理做成了文档，以及系统的进阶学习视频资料，免费分享给大家。 （包括Java在Android开发中应用、APP框架知识体系、高级UI、全方位性能调优，NDK开发，音视频技术，人工智能技术，跨平台技术等技术资料），希望能帮助到你面试前的复习，且找到一个好的工作，也节省大家在网上搜索资料的时间来学习。
