2024年View-事件分发看了那么多还是不懂？这回让你一次明白！，程序员去大公司面试问题-CSDN博客

本文链接：https://blog.csdn.net/2401_84558353/article/details/138870749

写在最后

今天关于面试的分享就到这里，还是那句话，有些东西你不仅要懂，而且要能够很好地表达出来，能够让面试官认可你的理解，例如Handler机制，这个是面试必问之题。有些晦涩的点，或许它只活在面试当中，实际工作当中你压根不会用到它，但是你要知道它是什么东西。

最后在这里小编分享一份自己收录整理上述技术体系图相关的几十套腾讯、头条、阿里、美团等公司的面试题，把技术点整理成了视频和PDF（实际上比预期多花了不少精力），包含知识脉络 + 诸多细节，由于篇幅有限，这里以图片的形式给大家展示一部分。

还有 高级架构技术进阶脑图、Android开发面试专题资料，高级进阶架构资料帮助大家学习提升进阶，也节省大家在网上搜索资料的时间来学习，也可以分享给身边好友一起学习。

【Android核心高级技术PDF文档，BAT大厂面试真题解析】

【算法合集】

【延伸Android必备知识点】

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化学习资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

**2.**每次完整的事件分发流程，都是针对一个事件（MotionEvent）完成的递归，而一个事件只对应着一个 ACTION，例如 ACTION_DOWN。

**3.**一次用户触摸操作，我们称之为一个事件序列。一个事件序列会包含 ACTION_DOWN、ACTION_MOVE … ACTION_MOVE、ACTION_UP 等多个事件。（其中 ACTION_MOVE 的数量是从 0 到多个不等）

也即一个事件序列，包含从 ACTION_DOWN 到 ACTION_UP 的多次事件分发流程。

下面我用一张图概括 View 事件分发的递和归流程。

如图所示：👆👆👆

事先分发包含 3 个重要方法：

dispatchTouchEvent，onInterceptTouchEvent，onTouchEvent。

因而首先，在递的过程中，当前层级是执行 child.dispatchTouchEvent：

如果 child 是 ViewGroup，那么实际执行的就是 ViewGroup 重写的 dispatchTouchEvent 方法。该方法内可以判断，是否在当前层级拦截当前事件、或是递给下一级。
如果 child 是不再有 child 的 View 或 ViewGroup，那么实际执行的就是 View 类实现的 super.dispatchTouchEvent 方法。该方法内可以判断，如果 View enabled 并且实现了 onTouchListener，且 onTouch 返回 true，那么不执行 onTouchEvent，并直接返回结果。否则执行 onTouchEvent。

此外，在 onTouchEvent 中如果 clickable 并且实现了 onClickListener 或 onLongClickListener，那么会执行 onClick 或 onLongClick。

总之，走到没有 child 的层级，即意味着步入“归”流程，如果该层级的 super.dispatchTouchEvent 没有返回 true，那么将继续执行上一级的 super.dispatchTouchEvent，直到被某一级消费，也即返回 true 了为止。

上面我们介绍了正常流程下，所会执行到的方法，包括 View 实现的 dispatchTouchEvent，ViewGroup 重写的 dispatchTouchEvent，以及 onTouchEvent。

如图。👆👆👆

其实在事件的 “递” 流程中，ViewGroup 可以在当前层级，通过设置 onInterceptTouchEvent 方法返回 true，来拦截事件的下发，而直接步入“归”流程。

正所谓 “上有正策、下有对策”。在 ViewGroup 可以拦截事件下发的同时，child 也可以通过 getParent.requestDisallowInterceptTouchEvent 方法，来阻止上一级的下发拦截。

额外需要明确的 3 个小细节

细节1：明确消费的概念

要将 “消费” 和 “执行” 这两个概念明确区分开。

网上的内容总让人误以为，当前层级不消费，就是不执行 super.dispatchTouchEvent 了。

事实上，不消费，简单地理解就是，“事情做了、只是结果不 OK” —— 在归流程中，如果当前层级的 super.dispatchTouchEvent return true 了，那么再往上的层级都不再执行自己的 super.dispatchTouchEvent，而是直接 return true。并且，当前层级的下级，都执行过 super.dispatchTouchEvent，只是结果返回了 false 而已。

细节2：明确拦截的作用

网上的内容总是让人误以为，当前层级拦截了，就直接在当前层级消费了。

实际上，当前层级拦截了，只是提前结束了 “递” 流程，并从当前层级步入 “归” 流程而已。具体判定是在哪个层级被消费，还是根据 <细节1> 的指标：看在哪个层级的 super.dispatchTouchEvent return true。

细节3：拦截方法只走一次，不代表拦截只走一次

网上的内容总是让人误以为，本次 ACTION_DOWN 被拦截了，那么往后的 ACTION_MOVE 和 ACTION_UP 都不被拦截了。

实际上，是 onInterceptTouchEvent 方法只走一次，一旦走过，就会留下记号（mFirstTouchTarget == null）那么下一次直接根据这个记号来判断拦不拦截。

为什么这么设计呢？因为一连串的事件序列，要求在几百微秒内完成。如果每次都完整走一遍方法，那岂不耽误事？所以本着 “能省即省” 的原则，凡是已确认会拦截的，后续就不再走方法判断，而是直接走变量标记来判断。

到此已经讲完 3 个细节了，要不要再讲 2 个呢？

讲？不讲？讲？不讲？
好嘛，再讲 2 个 ~

细节4：ACTION_DOWN 不执行，那么没下次了

这个很好理解，和 <细节3> 同理。

连事件序列的第一个事件都不接了（父容器走后续事件的分发时发现 mFirstTouchTarget == null），那就意味着不接了呗 —— 那后续的活就不会交给你了（不会再走你的 super.dispatchTouchEvent 来试探），直接根据变量标记（mFirstTouchTarget == null）做出判断，“能省即省”。

细节5：内部拦截并不能阻止父容器对 ACTION_DOWN 的处理

也即在 child 的 onTouch、onTouchEvent 中调用 getParent.requestDisallowInterceptTouchEvent 时，被设计为对父容器的 ACTION_DOWN 无效 —— 在父容器 dispatchTouchEvent 时，会首先重置 mGroupFlags。（ ViewGroup 正是根据 mGroupFlags 是否包含 FLAG_DISALLOW_INTERCEPT 来判断是否不拦截的）

为什么这么设计呢？
这个问题读者可以想一想，欢迎在评论区留言 ~

总结

View 事件分发的本质是递归。
递归的本质是，任务的下发和结果的上报。
View 事件分发设计成递归，是为了配合 View 的排版规则，形成符合用户直觉的触控体验。
View 事件分发的对象是一个 MotionEvent。
一次用户触控操作包含多个 MotionEvent（例如从 ACTION_DOWN 到 ACTION_UP ），也即会走多次事件分发流程。
一次 View 事件分发流程包含 “递” 流程和 “归” 流程，“递” 流程可以因 ViewGroup 的拦截而提前步入 “归” 流程。
child 可以通过 getParent.requestDisallowInterceptTouchEvent 阻止父容器的拦截。因而需要差异化地配置阈值，来确保 child 执行 getParent.requestDisallowInterceptTouchEvent 优先于父容器 onInterceptTouchEvent 返回 true（不然都先被拦截了，child 哪有机会阻止？）
在“归”流程中，唯有当前层级的 super.dispatchTouchEvent 返回了 true，才认定被消费，被消费前，下级都有干活，只是结果不 OK。被消费后，上级都不需要干活，直接向上传达消费者的功。

这样说，你理解了吗？