android事件分发机制
我们只考虑最重要的四个触摸事件,即:down,move,up和cancel。一个手势(gesture)是一个事件列,以一个down事件开始(当用户触摸屏幕时产生),后跟0个或多个move事件(当用户四处移动手指时产生),最后跟一个单独的up或cancel事件(当用户手指离开屏幕或者系统告诉你手势(gesture)由于其他原因结束时产生)。当我们说到“手势剩余部分”时指的是手势后续的move事件和最后的up或cancel事件。
在这里我也不考虑多点触摸手势(我们只假设用一个手指)并且忽略多个move事件可以被归为一组这一实际情况。最后,我们假设文中的view都没有注册ontouchlistener。
我们将要讨论的视图层次是这样的:最外层是一个viewgroup a,包含一个或多个子view(children),其中一个子view是viewgroup b,viewgroupb中又包含一个或多个子view,其中一个子view是 view c,c不是一个viewgroup。这里我们忽略同层级view之间可能的交叉叠加。
假设用户首先触摸到的屏幕上的点是c上的某个点,该点被标记为触摸点(touch point),down事件就在该点产生。然后用户移动手指并最后离开屏幕,此过程中手指是否离开c的区域无关紧要,关键是手势(gesture)是从哪里开始的。
默认情况
假设上面的a,b,c都没有覆写默认的事件传播行为,那么下面就是事件传播的过程:
由于没有view关心这个手势(gesture),它们将不再会从“手势剩余部分”中接收任何事件。
处理事件
现在,让我们假设c实际上是关心这个手势(gesture)的,原因可能是c被设置成可点击的(clickable)或者你覆写了c的ontouchevent方法。
个人理解:从这里可以看出,各个view的ontouchevent方法对down事件的处理,代表了该view对以此down开始的整个手势(gesture)的处理意愿,返回true代表愿意处理该gesture,返回false代表不愿意处理该gesture。
onintercepttouchevent
现在我们将讨论一个新的方法:onintercepttouchevent,它只存在于viewgroup中,普通的view中没有这个方法。在任何一个view的ontouchevent被调用之前,它的父辈们(ancestors)将先获得拦截这个事件的一次机会,换句话说,它们可以窃取该事件。在刚才的“处理事件”部分中,我们遗漏了这一过程,现在,让我们把它加上:
个人理解:感谢@编程世界的孩子 的提醒,由此可见,down事件的处理实际上经历了一下一上两个过程,下是指a->b的onintercepttouchevent,上是指c->b->a的ontouchevent,当然,任意一步的方法中返回true,都能阻止它继续传播。
拦截事件
现在,让我们更进一步,假设b没有拦截down事件,但它拦截了接下来的move事件。原因可能是b是一个scrolling view。当用户仅仅在它的区域内点击(tap)时,被点击到的元素应当能处理该点击事件。但是当用户手指移动了一定的距离后,就不能再视该手势(gesture)为点击了——很明显,用户是想scroll。这就是为什么b要接管该手势(gesture)。
下面是事件被处理的顺序:
下面的一些小事情可能会令你感到吃惊:
从此开始,你可以更进一步。比如对mouthful-method (实在不知道该怎么翻译啦!)requestdisallowintercepttouchevent,c可以用该方法阻止b窃取事件。如果你想更加疯狂一点,你可以在你自己的viewgroup中直接覆写dispatchtouchevent方法,并对传递进来的事件做任何你想做的处理。但这样的话你可能会破坏一些约定,所以应当小心。
如有疑问请留言或者到本站社区交流讨论,感谢阅读,希望能帮助到大家,谢谢大家对本站的支持!
如对本文有疑问, 点击进行留言回复!!
Android studio 中基于c++的OpenCV 配置
Android 在线查看、修改 Settings 等值的方法
一次Pandas踩坑记录(为什么Dataframe创建时指定的列名和列不对应)
网友评论