一点见解: Android事件分发机制(一) - 基本概念解释
一点见解: Android事件分发机制(二) - 分析ViewGroup
一点见解: Android事件分发机制(三) - 分析View

本文主要分析事件分发机制传递到View后的处理逻辑.

上一篇文章的最后我们得到结论, 在事件传递到ViewGroup#dispatchTouchEvent后, 经过一系列的判断最终总会把事件传递给View#dispatchTouchEvent, 所以我们从View#dispatchTouchEvent开始.

View#dispatchTouchEvent中包含很多滚动的判断, 对于事件分发机制我们只需要关注返回值的赋值, 知道什么时候子控件会消费事件就可以了. 相关代码如下

// View#dispatchTouchEventpublic boolean dispatchTouchEvent(MotionEvent event) {     // ...    boolean result = false;    if (onFilterTouchEventForSecurity(event)) {        ListenerInfo li = mListenerInfo;        if (li != null && li.mOnTouchListener != null                && (mViewFlags & ENABLED_MASK) == ENABLED                && li.mOnTouchListener.onTouch(this, event)) {            // 第一个条件判断            result = true;        }        if (!result && onTouchEvent(event)) {            // 第二个条件判断            result = true;        }    }     // ...     return result;}

整个方法内对返回值得赋值仅有2个地方, 都是在条件判断内条件成立的时候就代表子控件消费该事件.第一个条件判断关键就是当控件为enable时执行OnTouchListener#onTouch方法(如果存在该接口方法), 从这里可以得到结论

OnTouchListener#onTouch是在View#dispatchTouchEvent被调用的, 如果返回true则不会调用View#onTouchEvent, 且表示控件消费该事件.

第二个条件的判断关键则是View#onTouchEvent, 当其返回true的时候控件消费该事件, 所以接着分析View#onTouchEvent方法, 关键代码如下

// View#onTouchEventpublic boolean onTouchEvent(MotionEvent event) {     // ...     if ((viewFlags & ENABLED_MASK) == DISABLED) {         // ...         // disable但是clickable则消费该事件         return (((viewFlags & CLICKABLE) == CLICKABLE                     || (viewFlags & LONG_CLICKABLE) == LONG_CLICKABLE)                     || (viewFlags & CONTEXT_CLICKABLE) == CONTEXT_CLICKABLE);     }     if (mTouchDelegate != null) {         if (mTouchDelegate.onTouchEvent(event)) {             return true;         }     }     if (((viewFlags & CLICKABLE) == CLICKABLE             || (viewFlags & LONG_CLICKABLE) == LONG_CLICKABLE)             || (viewFlags & CONTEXT_CLICKABLE) == CONTEXT_CLICKABLE) {         switch (action) {             case MotionEvent.ACTION_UP:                 // ...                 if (!mHasPerformedLongPress && !mIgnoreNextUpEvent) {                     // 一系列状态判断                     removeLongPressCallback();                     if (!focusTaken) {                         // 利用Handler调用OnClickListener#onClick                         if (!post(mPerformClick)) {                               performClick();                         }                     }                 }                 // ...                 break;             case MotionEvent.ACTION_DOWN:                 // ...                 break;             case MotionEvent.ACTION_CANCEL:                 // ...                 break;             case MotionEvent.ACTION_MOVE:                 // ...                 break;         }         return true;     }     return false;}

事件经过一系列的dispatch之后被传递到View#onTouchEvent中, 这个方法的返回值直接决定控件是否消费事件, 所以同样忽略跟返回值无关的代码, 看以上代码, 决定返回值的地方有4处.

  1. 处理disable的情况, 因为在dispatchTouchEvent中, 当控件为disable时会直接调用onTouchEvent方法, 从这里可以看出, 如果控件是disable同时是clickable则会消费事件, 但是不会调用任何clickable的相关接口.
  2. mTouchDelegate优先处理事件, 通常情况下不会使用, 我们可以通过设置代理来覆盖控件默认的处理事件逻辑.
  3. 只要是控件是可点击的, 就会消费事件, 下面进一步分析.
  4. 其他情况则不消费事件.

经过上面返回值的分析可以知道

控件是否消费事件的关键是CLICKABLE, LONG_CLICKABLECONTEXT_CLICKABLE, 而这3个参数都有对应的get/set方法, 通常情况下只要设置了对应的接口就会赋值对应的参数为真.

当参数是可点击的时候会进入一个switch块内对不同的事件进行不同的操作, 值得注意的是这里只对4个事件作出处理, 而且大部分是修改控件状态, 值得关注的是ACTION_UP事件, 因为ACTION_UP代表一个操作的结束, 所以在这里应该可以判断出这个操作具体是什么操作了, 在View这里区分了长点击和点击两种情况, 稍作分析就可以知道performClick()执行了OnClickListener#onClick方法, 代码就不贴了, 所以这里可以得知

OnClickListener#onClickOnLongClickListener#onLongClick是在View#onTouchEvent内被回调的, 且同时只会回调其中一个, 另外只要有回调, 就代表控件消费了ACTION_UP事件, 即消费了整个操作.

源码bonus

  1. 改变控件处理事件的逻辑可以设置OnTouchListener#onTouch并返回true或者通过View#setTouchDelegate设置事件代理.
  2. OnTouchListener#onTouch是在View#dispatchTouchEvent中调用, 而OnClickListener#onClick是在View#onTouchEvent中调用, 所以OnTouchListener#onTouch先于OnClickListener#onClick被调用.
  3. 即使控件是disable, 事件仍然会传递到onTouchEvent, 而且只要控件是clickable, 虽然接口不会回调, 但是控件仍会消费这事件.

总结

关于事件传递机制的路径网上已经有很多文章了, 这个系列主要关注的是源码中的一些细节, 所以不再花篇幅细说了.
概括来说, 传递路径的逻辑主要是ViewGroup#dispatchTouchEvent决定的, 事件进来后先决定是否拦截事件, 如果不拦截事件则会根据一定的顺序(默认是在布局中的前后顺序)逐个询问在触摸坐标下的子控件是否消费事件, 如果所有子控件都不消费事件那么就会调用父控件自己的onTouchEvent.
更具体的说明可以参考图解 Android 事件分发机制中的图解, 画得相当清晰.

如果关于这系列的文章有任何意见或者表意模糊的地方欢迎回复讨论 :D

更多相关文章

  1. Android UI设计——ListView控件与SimpleAdapter适配器(三)
  2. Android中的多击事件
  3. 3.6.3新版本AndroidStudio报Could not resolve all artifacts fo
  4. 浅谈Android常用控件
  5. Android中Market的Loading效果实现方法
  6. android:TabHost使用方法
  7. Android 自定义控件实现刮刮卡效果 真的就只是刮刮卡么

随机推荐

  1. Android中的文件权限操作
  2. Android(安卓)控件一 TextView
  3. Android(安卓)AVD Manager无法识别真机,ad
  4. Android(安卓)P 中的新文本特性
  5. Android(安卓)判断网络状态,并且在没有网
  6. Android(安卓)控件二 Button
  7. Android(安卓)Stuido 使用WIFI测试
  8. SQLSERVER 拼接含有变量字符串案例详解
  9. SQLServer清理日志文件方法案例详解
  10. SQLServer日期函数总结案例详解