}else{
return onTouchEvent(event);
}
}
这段代码非常好的展示了三个方法之间的关系：在viewGroup收到触摸事件时，会先去调用 onInterceptTouchEvent 方法判断是否拦截，如果拦截则调用自己的 onTouchEvent 方法处理事件，否则调用子view的 dispatchTouchEvent 方法来分发事件。因为子view也有可能是一个viewGroup，这样就形成了一个类似递归的关系。
这里我再补上view分发逻辑的简化伪代码：
public boolean dispatchTouchEvent(MotionEvent event){
// 先判断是否存在onTouchListener且返回值为true
if (mOnTouchListener!=null && mOnTouchListener.onTouch(event)){
// 如果成功消费则返回true
return true;
}else{
// 否则调用onTouchEvent消费事件
return onTouchEvent(event);
}
}
view与viewGroup不同的是他不需要分发事件，所以也就没有必要拦截事件。view会先检查是否有onTouchListener且返回值是否为true，如果是true则直接返回，否则调用onTouchEvent方法来处理事件。
基于上述的关系，可以得到下面的工作流程图：
这里为了展示类递归关系使用了画了两个viewGroup，只需看中间一个即可，下面对这个图进行解析：
- viewGroup
- viewGroup的dispatchTouchEvent方法接收到事件消息，首先会去调用onInterceptTouchEvent判断是否拦截事件
-
如果拦截，则调用自身的onTouchEvent方法
-
如果不拦截则调用子view的dispatchTouchEvent方法
-
子view没有消费事件，那么会调用viewGroup本身的onTouchEvent
-
上面1、2步的处理结果为viewGroup的dispatchTouchEvent方法的处理结果，并返回给上一层的onTouchEvent处理
- view
-
view的dispatchTouchEvent默认情况下会调用onTouchEvent来处理事件，返回true表示消费事件，返回false表示没有消费事件
-
第1步的结果就是dispatchTouchEvent方法的处理结果，成功消费则返回true，没有消费则返回false并交给上一层的onTouchEvent处理
可以看到整个工作流程就是一个“U”型结构，在不拦截的情况下，会一层层向下寻找消费事件的view。而如果当前view不处理事件，那么就一层层向上抛，寻找处理的viewGroup。
上述的工作流程模型并不是完整的，还有其他的特殊情况没有考虑。下面讨论几种特殊的情况：
事件序列被中断
我们知道，当一个view接收了down事件之后，该触控点接下来的事件都会被这个view消费。但是，viewGroup是可以在中途掐断事件流的，因为每一个需要分发给子view的事件都需要经过拦截方法：onInterceptTouchEvent （当然，这里不讨论子view设置不拦截标志的情况）。那么当viewGroup掐断事件流之后，事件的走向又是如何的呢？参看下图：（注意，这里不讨论多指操作的情况，仅讨论单指操作的move或up事件被viewGroup拦截的情况）
-
当viewGroup拦截子view的move或up事件之后，会将当前事件改为cancel事件并发送给子view
-
如果当前事件序列还未结束，那些接下来的事件都会交给viewGroup的ouTouchEvent处理
-
此时不管是viewGroup还是view的onTouchEvent返回了false，那么将导致整个控件树的dispatchTouchEvent方法返回false
- 秉承着一个事件序列只能给一个view消费的原则，如果一个view消耗了down事件却在接下来的move或up事件返回了false，那么此事件不会给上层的viewGroup处理，而是直接返回false。
多点触控情况
上面讨论的所有情况，都是不包含多点触控情况的。多点触控的情况，在原有的事件分发流程上，新增了一些特殊情况。这里就不再画图，而是把一些特殊情况描述一下，读者了解一下就可以了。
默认情况下，viewGroup是支持多点触控的分发，但view是不支持多点触控的，需要自己去重写 dispatchTouchEvent 方法来支持多点触控。
多点触控的分发规则如下：
viewGroup在已有view接受了其他触点的down事件的情况下，另一个手指按下产生ACTION_POINTER_DOWN事件传递给viewGroup：
- viewGroup会按照ACTION_DOWN的方式去分发ACTION_POINTER_DOWN事件
-
如果子view消费该事件，那么和单点触控的流程一致
-
如果子view未消费该事件，那么会交给上一个最后接收down事件的view去处理
- viewGroup两个view接收了不同的down事件，那么拦截其中一个view的事件序列，viewGroup不会消费拦截的事件序列。换句话说，viewGroup和其中的view不能同时接收触摸事件。
Activity的事件分发
细心的读者会发现，上述的工作流程并不涉及Activity。我们印象中的事件分发都是 Activity -> Window -> ViewGroup ，那么这是怎么回事？这一切，都是DecorView “惹的祸” 。
DecorView重写viewGroup的 dispatchTouchEvent 方法，当接收到触摸事件后，DecorView会首先把触摸对象传递给内部的callBack对象。没错，这个callBack对象就是Activity。加入Activity这个环节之后，分发的流程如下图所示：
整体上和前面的流程没有多大的不同，Activity继承了Window.CallBack接口，所以也有dispatchTouchEvent和onTouchEvent方法。对上图做个简单的分析：
-
activity接收到触摸事件之后，会直接把触摸事件分发给viewGroup
-
如果viewGroup的dispatchTouchEvent方法返回false，那么会调用Activity的onTouchEvent来处理事件
-
第1、2步的处理结果就是activity的dispatchTouchEvent方法的处理结果，并返回给上层
上面的流程不仅适用于Activity，同样适用于Dialog等使用DecorView和callback模式的控件系统。
总结
–
到这里，事件分发的主要内容也就讲解完了。结合前两篇文章，相信读者对于事件分发有更高的认知。
纸上得来终觉浅，绝知此事要躬行。学了知识之后最重要的就是实践。下一篇文章将简单分析一下如何利用学习到的事件分发知识运用到实际开发中。
最后
–
在这里我也分享一份由几位大佬一起收录整理的 Flutter进阶资料以及Android学习PDF+架构视频+面试文档+源码笔记 ，并且还有 高级架构技术进阶脑图、Android开发面试专题资料，高级进阶架构资料……
自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。
深知大多数Android工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！
因此收集整理了一份《2024年Android移动开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Android开发知识点，真正体系化！
由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且后续会持续更新
如果你觉得这些内容对你有帮助，可以添加V：vip204888 备注Android获取（资料价值较高，非无偿）
学习路线+知识梳理
花了很长时间，就为了整理这张详细的知识路线脑图。当然由于时间有限、能力也都有限，毕竟嵌入式全体系实在太庞大了，包括我那做嵌入式的同学，也不可能什么都懂，有些东西可能没覆盖到，不足之处，还希望小伙伴们一起交流补充，一起完善进步。
这次就分享到这里吧，下篇见。
4888 备注Android获取（资料价值较高，非无偿）**
[外链图片转存中…(img-4lZm9aHO-1711547804770)]
学习路线+知识梳理
花了很长时间，就为了整理这张详细的知识路线脑图。当然由于时间有限、能力也都有限，毕竟嵌入式全体系实在太庞大了，包括我那做嵌入式的同学，也不可能什么都懂，有些东西可能没覆盖到，不足之处，还希望小伙伴们一起交流补充，一起完善进步。
这次就分享到这里吧，下篇见。
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
