Android事件分发机制源代码分析

Posted 2020-10-02 yutingliuyl

小小感慨一下，做android有一段时间了，一直以来都是习惯整理笔记存到有道笔记上，没有写博客的习惯。

以后逐步分类整理出来，也算“复习”一遍了 - _ - 。

 

android的事件分发相关的方法有三个：

    1.public booleandispatchTouchEvent(MotionEvent ev)

    2.public boolean onInterceptTouchEvent(MotionEvent ev)

    3.public booleanonTouchEvent(MotionEvent event)                           

第一个方法表示是否分发事件，第二个方法表示是否拦截事件（只ViewGroup有这种方法。View没有） ，第三个方法表示是否消费事件。

分析源代码之前，我们先总结一下事件分发的规律，或者说上面3个方法的用法：

    ①当TouchEvent发生时，首先Activity将TouchEvent传递给最顶层的View，通常是一个ViewGroup。

TouchEvent最先到达最顶层 view 的 dispatchTouchEvent ，然后由  dispatchTouchEvent 方法进行分发。返回true则不分发。所有事件都交给dispatchTouchEvent 处理。假设dispatchTouchEvent返回 false 。则view以及它的子view都接收不到兴许事件，假设调用super.dispatchTouchEvent,则交给interceptTouchEvent 处理。

    ②假设 interceptTouchEvent 返回 true ，也就是拦截掉了。则兴许事件交给它的 onTouchEvent 来处理interceptTouchEvent 不再处理(假设手拿起来在又一次点击，down事件还会走一次，后面的move和up不走了)。假设onTouchEvent不处理，事件原路返回。兴许事件就不交给这个view了，假设 interceptTouchEvent 返回 false 或者调用super.interceptTouchEvent ，那么兴许事件仍然经过interceptTouchEvent 处理，可是不经过onTouchEvent。

没有interceptTouchEvent方法的普通view不考虑这种方法，其它规律同样

    ③对于onTouvhEvent返回true表示消费事件，false表示不消费，调用super.onTouchEvent时分两种情况，对于ViewGroup等能够放子View的来说不消费事件，对于不能放子View的View来说消费事件。不消费事件时事件到达最底层的view后会回传，仅仅走onTouchEvent，可能被上层View消费

假设你不过关心这几个方法的使用。然后自己自己定义view。那看到这里应该就没神马问题了。反正我知道这几个方法会对事件分发造成什么影响了。至于为啥我就不关心了

可是作为一个积极学习高素养的程序员来说，我们不仅要弄明确怎么用。还要明确为什么会出现这些情况（此处应有掌声）。我们就依照上面的三点逐点分析。

 

    首先我们看第一点：dispatchTouchEvent。

这种方法返回false表示事件不分发，那么能够理解为这个view以及子view都不会消费事件。那兴许事件就不会在给你了，反正给了你你也不消费嘛。干嘛还给你，这个非常好理解，代码实现是把全部消耗事件的View都保存起来，所以不消费事件的View是不会即受到兴许事件的，这部分代码没贴出来，參见ViewGroup代码的第2213行调用addTouchTarget方法的代码。依照常规来想。既然返回false表示不消费事件，那么返回true就应该是消费事件了吧？NO NO NO，too young to simple。

假设你写demo试试就会发现dispatchTouchEvent方法一直走，可是事件却没有分发下去，子view收不到事件，仅仅有返回值是super.dispatchTouchEvent才干把事件分发下去。。。

纳尼，这是什么鬼。不按套路出牌啊。好吧，这样的情况仅仅能翻源代码了。我们以android6.0（API Level 23）的源代码为准进行分析。

以下这段代码是摘自ViewGroup的dispatchTouchEvent方法。在2167行是取到第i个子view。然后到2197行，这里调用了一个方法，将上面取到的第i个子view作为參数之中的一个传了过去。

以下这段代码是刚才说到的在dispatchTouchEvent中调用的这种方法，看第2553行，当child不为空的时候，调用了child的dispatchTouchEvent（详细会走到2553或者2575行。他们本质上是一样的，差别就是对传过来的MotionEvent进行了一个split操作，详细做了啥没去深究。

有知道它们差别的小伙伴能够留言赐教）。

到这里是不是有一种豁然开朗的感觉呢？ViewGroup之所以能将事件分发给子view是由于在dispatchTouchEvent中又调用了子view的事件分发方法，假设你在ViewGroup的dispatchTouchEvent方法中仅仅返回true而不返回super.dispatchTouchEvent，那么子view的事件分发的方法将不会调用。子view就拿不到事件。明确了吧，我认为我说的还是挺清楚的。中间我们忽略了其它不相关的代码。假设你想深入了解，能够再去阅读一下源代码，看完博客阅读源代码，一切so easy~。

以下的这种方法后面还要用到。dispatchTouchEvent方法中多次调用了这种方法。

    再看第二点onInterceptTouchEvent方法：这种方法表示是否拦截事件。假设返回true。那么事件会直接交给自身的onTouchEvent处理。为什么会这样呢？看以下的代码块：

第2104行，按下手机屏幕，走到这里，2106行，这里的disallowIntercept默认的情况下这里得到的是false的（默认初始化出来的值计算），会走到2108行，调用onInterceptTouchEvent，假设我们复写这种方法返回true，这是intercept的值就是true，再往下走会走到2238行。这时候mFirstTouchTarget是为null的。会走到2240。这里又调用了dispatchTransformedTouchEvent方法，也就是本文中的第二个代码块。这时候第三个參数child是null，方法会走到2547或者2566行（详细是哪一个。whatever）。然后调用了父类的dispatchTouchEvent方法。我们再去看父类的方法：

看到红框框中的代码了没，直接调用了onTouchEvent。所以假设你的onInterceptTouchEvent返回true时会调用自身的onTouchEvent，事件就传到自己的onTouchEvent了。

 

第三点，为啥事件不消费时会回传给父view，我有点词穷了。

。。

不知道该怎样描写叙述，原因就是递归。父View传递事件的时候是递归调用disPatchTouchEvent。当事件没有被子View消费时。就会调用自己的onTouchEvent方法，所以从日志看起来的效果就是事件被回传回去了。

 

 

关于自己对这方面的理解。整体上就这么多。源代码的解析不太具体，就大概理出来了个初步的条理，可能理解的存在问题甚至错误，欢迎指正。