Android——View、ViewGroup事件(Touch事件)处理机制总结

  • 来源:csdn
  • 作者:走慢一点点
  • 字体:【
  • 时间:2015-06-18
  • 点击:
  • 收藏本文
Android中的事件
Touch事件,四种状态:
ACTION_DOWN     ——>   表示按下了屏幕,一个事件必然从ACTION_DOWN开始
ACTION_MOVE      ——>   表示移动手势
ACTION_UP            ——>  表示离开屏幕
ACTION_CANCEL  ——>   表示取消手势,一般由程序产生,不会由用户产生
一个ACTION_DOWN, n个ACTION_MOVE,1个ACTION_UP,就构成了Android中众多的事件。
Android中的事件onClick, onScroll, onFling等等,都是由许多个Touch组成的。
一个原则,所有的touch事件都是从父容器开始向下传递的,呈U字形。
 
View事件处理机制核心代码
Android中诸如ImageView、textView、Button等控件都没有重写View的dispatchTouchEvent方法,所以View的事件处理机制对这些控件都有效。
 
View.java(基于android2.3.3):
总结:
只有我们注册OnTouchListener时重写的onTouch()方法中返回false  ——> 执行onTouchEvent方法 ——>  导致onClick()回调方法执行
onTouch()方法返回true ——> onTouchEvent方法不执行 ——>  导致onClick()回调方法不会执行
 
ViewGroup事件处理机制核心代码
Android中诸如LinearLayout等的五大布局控件,都是继承自ViewGroup,而ViewGroup本身是继承自View,所以ViewGroup的事件处理机制对这些控件都有效。
 
ViewGroup.java(基于android2.3.3):
总结:
1、dispatchTouchEvent作用:决定事件是否由onInterceptTouchEvent来拦截处理。
返回super.dispatchTouchEvent时,由onInterceptTouchEvent来决定事件的流向
返回false时,会继续分发事件,自己内部只处理了ACTION_DOWN
返回true时,不会继续分发事件,自己内部处理了所有事件(ACTION_DOWN,ACTION_MOVE,ACTION_UP)
 
2、onInterceptTouchEvent作用:拦截事件,用来决定事件是否传向子View
返回true时,拦截后交给自己的onTouchEvent处理
返回false时,拦截后交给子View来处理
 
3、onTouchEvent作用:事件最终到达这个方法
返回true时,内部处理所有的事件,换句话说,后续事件将继续传递给该view的onTouchEvent()处理
返回false时,事件会向上传递,由onToucEvent来接受,如果最上面View中的onTouchEvent也返回false的话,那么事件就会消失
 
综合案例分析
以下摘自:http://www.longdw.com/android-onintercepttouchevent-ontouchevent/
源码:

分别重写Group1和Group2的onInterceptTouchEvent和onTouchEvent方法,重写MyTextView的onTouchEvent方法,最终得到的控件层次结构如下:

1.在默认返回值情况下logcat输出如下:

测试后可知默认情况下和所有方法返回值为false的结果一致,down事件的捕获顺序onInterceptTouchEvent先于onTouchEvent,由于onTouchEvent返回值为false,down事件没被消化,后续的move和up事件没有出现,同时逆序返回到父控件的onTouchEvent方法来捕获,如下图所示:

2.所有onTouchEvent返回值为true情况下logcat输出如下:

输出结果可以看出子控件MyTextView消化了down事件,后续的move和up事件正常捕获,由于down事件被消化,上层的onTouchEvent方法不执行,如下图所示:(三箭头分别指down、move、up事件)

既然如此,如果MyTextView中onTouchEvent方法返回为false,而group1和group2的onTouchEvent方法返回true的结果自然也就如下图的顺序了:

测试输出结果证明了这一猜测顺序:

注意:可能有人对这种情况比较疑惑,ACTION_DOWN还好理解,但是ACTION_MOVE为什么没有经历myTv,
而且ACTION_MOVE只经历了group1的onInterceptTouchEvent和group2的onTouchEvent而没有经历group2的onInterceptTouchEvent?我开始也费解
,后来想想也是,大家对比第1条,由于onTouchEvent返回了false而没有消耗down事件导致后续的move和up都没有出现
这里也是一样由于myTv中onTouchEvent返回了false也就是说没有消耗down事件,那么后面的move和up也都不会出在这个view里面
但是group2截获到了down事件,但后来的move为什么group2中的onInterceptTouchEvent没有执行到呢
原因大家不要忘记了onInterceptTouchEvent的初衷是什么,返回false是让它的子view或viewgroup类处理
而group2的子控件显然是myTv而myTv的onTouchEvent返回了false也就是接收不到后续的move和up事件
也就没必要经过onInterceptTouchEvent来继续分发了(因为分发了也还是接收不到)
经过group2的onTouchEvent因为它返回的是true,截获了事件并且消耗了事件。
 
3.当某个GroupView中的onInterceptTouchEvent方法返回值为true情况下logcat输出如下(如group2):

如果在该方法返回值中返回true,那么子控件将获取不到任何点击事件,转而向自身的onTouchEvent方法转发,如下图所示:

如果onTouchEvent方法返回值都为true,那么根据规律结果就如下图顺序触发:

最后logcat的结果证实了这一猜测:

暂无评论
  • 1:请一针见血的评论。
  • 2:评论需要审核通过后才能显示。
  • 3:评论字数限制在1000字以内。
  • 当前字数:0
热门文章
推荐文章
随机文章
关于本站 - 广告服务 - 版权声明 - 联系我们 - 友情链接 - 网站地图 - 帮助中心