前言

Android的事件分发机制看了很多文章，背都背出来了，但是一直没有自己去看源码追一遍，现在写下这篇文章记录下从源码分析Android的事件分发机制，如果有哪个地方说的不对的，望大家指出！谢谢！

事件分发示意图

解析

本文基于API 26

点击事件到Activity

详情可见这一篇，引用大佬的文章 Touch事件如何传递到Activity

Activity到PhoneWindow再到DecorView

Activity收集到点击事件后会调用到自己的dispatchTouchEvent方法，并且在其中通过调用window的superDispatchTouchEvent的方法来判断是否消费该事件，因为window是一个抽象类，他有一个唯一的子类Phonewindow，所以实际上会调用到PhoneWindow中的superDispatchTouchEvent，而到了PhoneWindow那就是直接调用DecorView，没有其他的判断

• Activity中调用PhoneWindow的superDispatchTouchEvent方法判断是否消费该事件

• PhoneWindow直接调用DecorView中的superDispatchTouchEvent方法

• DecorView到ViewGroup再到View

DecorView继承自FrameLayou，FrameLayout继承于ViewGroup,所以DecorView也是ViewGroup的子类，DecorView中的superDispatchTouchEvent调用父类ViewGroup的dispatchTouchEvent进行事件的分发

• DecorView调用父类的dispatchTouchEvent方法

• ViewGroup中dispatchTouchEvent进行了事件拦截的处理，首先判断了当前是否可以进行拦截，然后调用onInterceptTouchEvent进行拦截判断，如果返回为false，则继续向子View进行分发事件（前提是存在子View的情况下，如果不存在，并且拦截为false，则dispatchTouchEvent返回为false，向上级传递告诉他们你们自己消费去吧）

• 向子类分发事件，首先判断是否存在子View，如果存在子View，则调用dispatchTransformedTouchEvent方法去筛选，调用子View的dispatchTouchEvent方法

• 子View中判断自身的onTouchEvent是否执行，如果不执行，则返回false，如果执行返回true

总结

事件分发理解起来比较容易，就是一层一层的关系，中间任何一个环节出现了消费事件的操作，则都不用下发给下一层了，并且消费过后告诉上一层我已经消费了，然后上一层再告诉上上层，直到顶层。

事件cancel的时机

ACTION_CANCEL事件是收到前驱事件后，后续事件被父控件拦截的情况下产生，onTouchEvent的事件回传到父控件只会发生在ACTION_DOWN事件中。 所以当父View拦截到后续事件时才会触发ACTION_CENCEL,我们正常的流程只有DOWN,UP,MOVE,这三个事件，所以保证ACTION_CENCEL事件不会触发即可"。

解决自定义View触发ACTION_CANCEL

结束

漫漫开发之路，我们只是其中的一小部分……只有不断的学习、进阶，才是我们的出路！才跟得上时代的进步！

今年年初我花一个月的时间收录整理了一套知识体系，如果有想法深入的系统化的去学习的，可以私信我【安卓】，我会把我收录整理的资料都送给大家，帮助大家更快的进阶。

重要的事说三遍，转发+转发+转发，让更多需要的朋友们都可以看到并且领到！