android事件传递机制的浅谈

分类：Android

想必大家有时会遇到需要自定义控件吧，这个时候就会遇到事件的传递和处理了，非常繁琐啊！百度上面一大票关于事件的传递机制，但是都千篇一律，都是dispatchTouchEvent

返回true，则事件被拦截，false则分发给子控件之类的，经过几天的研究发现这个事件传递并没有说的这么简单也没有想象中的难。

一般的点击事件、滑动事件都是用ACTION_UP、ACTION_MOE、ACTION_DOWN组成的，android应用里面默认情况下，触摸事件是从activity开始传递，假设里面的view都不需要拦截事件，那么这个触摸事件会沿着里面的视图走一圈再回到activity，如果我们对某一个view绑定了一个事件监听器，那么这个事件只能被一个view消费。

其实以上说的大家一般都清楚，但是当需要重写某个控件的时候又会犯难了，因为光知道以上的还不够，这个时候我们需要去看源码研究下，通过俺的鼓捣，发现了事件传递的规律：

dispatchTouchEvent

viewgroup的传递顺序：dispatchTouchEvent→onInterceptTouchEvent→事件传递给下一层→onTouchEvent

其实一个触摸事件不管是activity还是viewgroup、view，都是从dispatchTouchEvent这个回调函数开始，里面会把触摸事件传给它的下一层，如果他的下一层dispatchTouchEvent返回了ture，则这个事件就回不去了，，因为被下一层拦截到了，onTouchEvent方法只是在dispatchTouchEvent中最后调用的，因为会先把事件传递给下一层，如果下一层不要了才会执行到调用onTouchEvent这一步，而onInterceptTouchEvent只有viewgroup中才有，是对事件的再一次拦截。

这个是系统默认方式，但是如果重写上面的dispatchTouchEvent方法，就可以颠覆这个默认的规律，比如viewgroup传递给它的子view，我在他们的相关事件拦截方法里面都返回false，然后对他们都各自处理自己的事件，那么这样就不是一个事件只能被一个视图消费了，暂时就水到这，这只是自己的一点心得，欢迎大家互相学习交流

上一篇android studio 非法字符: '\ufeff' 解决方案

顶0踩0

与其在那里苦苦挣扎，碍于面子硬撑，倒不如微笑着面对，

相关文章：

你感兴趣的文章：

标签云：