(2)android触摸事件处理流程
2014-10-07 09:11
399 查看
最近在工作中,经常需要处理触摸事件,但是有时候会出现一些奇怪的bug,比如有时候会检测不到ACTION_MOVE和ACTION_UP,我决定下决心写个测试的小程序,来研究一个触摸事件从上往下是怎么传递和处理的。
先说下大概的流程吧,这个应该在很多博客中都有讲解:当一个事件来临的时候,会先传递给最外层的ViewGroup(比如LinearLayout,FrameLayout),如果这个ViewGroup没有去拦截这个事件的话,才会给传递给下层的ViewGroup或者View。如果被拦截掉的话,它会自己去处理这个事件,这个ViewGroup内的View将无法得知上层发生了什么。
ViewGroup的拦截事件的函数为
onInterceptTouchEvent的参数ev就是一个触摸事件,可以从ev获取到事件的坐标,类型,当前屏幕上点的个数等等。通常我们在继承ViewGroup的时候都会重写这个方法,判断目前需不需要拦截,即返回true还是false。返回true的时候表明事件不再往下传了,否则就往下传。那返回true的时候怎么处理呢?
这就需要onTouchEvent():
具体怎么实现就根据实际的需要来了。我们发现他的返回值也是boolean,那返回true或者false的时候会有什么影响呢?用一张图来说明:
这个一个典型的流程,也就是所有的相关方法都返回false的时候,一个事件先到了LinearLayout,它不拦截,然后就往下面跑,到了FrameLayout上,他又不处理,又传到了Button上,这个时候Button返回了false,然后这个事件往上传,最后没有人处理。当FrameLayout的两个方法返回true的时候会怎样呢?
FrameLayout的onInterceptTouchEvent返回true后,就拦截触摸消息了,然后交给自己的onTouchEvent处理。这里面的逻辑自己定义就好了,如果这个事件被消费掉了,返回true就可以了,这样系统就不会接着传了,事件处理到此为止。
是不是按下,移动,松开的流程都是按照这样处理的呢?答案是否定的。ACTION_DOWN时间的判断和处理,直接影响到了后续的ACTION_MOVE和ACTION_UP,在上面的图中,FrameLayout的onTouchEvent返回了true,那么当ACTION_MOVE来到FrameLayout这一层的时候,就不再需要通过onInterceptTouchEvent拦截了,直接用onTouchEvent处理。如果说一个ACTION_DOWN从头到尾都是返回false,那么后续的ACTION_MOVE和ACTION_UP就没法被感知到了。
下面说一下多点触摸的情况:
多点触摸的时候,会多两个事件 ACTION_POINTER_UP和ACTION_POINTER_DOWN。当第一个手指按下的时候,会产生ACTION_DOWN,当第二个手指按下的时候,会产生ACTION_POINTER_DOWN,第三个或者更多手指按下的时候,也是ACTION_POINTER_DOWN,如果此时有一个手指离开屏幕,会产生ACTION_POINTER_UP,当最后一个手指离开屏幕的时候,才会产生ACTION_UP。在整个操作过程中,一个触点会始终保持一个固定的ID,方便记录和处理,比如说在ACTION_MOVE的处理过程中,可以通过MotionEvent的getX(int
pointerIndex)来获取某个点的坐标。
先说下大概的流程吧,这个应该在很多博客中都有讲解:当一个事件来临的时候,会先传递给最外层的ViewGroup(比如LinearLayout,FrameLayout),如果这个ViewGroup没有去拦截这个事件的话,才会给传递给下层的ViewGroup或者View。如果被拦截掉的话,它会自己去处理这个事件,这个ViewGroup内的View将无法得知上层发生了什么。
ViewGroup的拦截事件的函数为
1 | public boolean onInterceptTouchEvent(MotionEvent ev) |
这就需要onTouchEvent():
1 | public boolean onTouchEvent(MotionEvent ev) |
这个一个典型的流程,也就是所有的相关方法都返回false的时候,一个事件先到了LinearLayout,它不拦截,然后就往下面跑,到了FrameLayout上,他又不处理,又传到了Button上,这个时候Button返回了false,然后这个事件往上传,最后没有人处理。当FrameLayout的两个方法返回true的时候会怎样呢?
FrameLayout的onInterceptTouchEvent返回true后,就拦截触摸消息了,然后交给自己的onTouchEvent处理。这里面的逻辑自己定义就好了,如果这个事件被消费掉了,返回true就可以了,这样系统就不会接着传了,事件处理到此为止。
是不是按下,移动,松开的流程都是按照这样处理的呢?答案是否定的。ACTION_DOWN时间的判断和处理,直接影响到了后续的ACTION_MOVE和ACTION_UP,在上面的图中,FrameLayout的onTouchEvent返回了true,那么当ACTION_MOVE来到FrameLayout这一层的时候,就不再需要通过onInterceptTouchEvent拦截了,直接用onTouchEvent处理。如果说一个ACTION_DOWN从头到尾都是返回false,那么后续的ACTION_MOVE和ACTION_UP就没法被感知到了。
下面说一下多点触摸的情况:
多点触摸的时候,会多两个事件 ACTION_POINTER_UP和ACTION_POINTER_DOWN。当第一个手指按下的时候,会产生ACTION_DOWN,当第二个手指按下的时候,会产生ACTION_POINTER_DOWN,第三个或者更多手指按下的时候,也是ACTION_POINTER_DOWN,如果此时有一个手指离开屏幕,会产生ACTION_POINTER_UP,当最后一个手指离开屏幕的时候,才会产生ACTION_UP。在整个操作过程中,一个触点会始终保持一个固定的ID,方便记录和处理,比如说在ACTION_MOVE的处理过程中,可以通过MotionEvent的getX(int
pointerIndex)来获取某个点的坐标。
相关文章推荐
- Android触摸事件处理流程
- android触摸事件处理流程
- android触摸事件处理流程
- android 触摸事件处理流程说明
- Android View系统源码分析(一)——概述&触摸事件总体处理流程
- Android 触摸事件的分发与处理流程:onInterceptTouchEvent和onTouchEvent
- [转]Android键盘和触摸事件处理
- 【转】Android事件处理流程
- Android 事件捕捉和处理流程分析
- Android键盘和触摸事件处理
- android触摸事件的分发和处理
- Android事件处理分析+Android事件处理 +Android输入事件流程
- Android热插拔事件处理流程
- Android热插拔事件处理流程--Vold
- Android的frameworks层键盘事件处理流程分析
- android处理触摸(touchEvent)详细流程
- Android:处理触摸事件
- Android的键盘事件处理流程学习
- Android键盘和触摸事件处理
- android中的触摸事件处理过程详解