android 事件分发以及滑动冲突

Android Activity 页面布局如下:

android应用界面的布局

view 的事件分发机制

事件分发的对象其实就是MotionEvent 也就是点击事件,点击事件的分发其实就是对MotionEvent事件额分发过程,就是当一个MotionEvent事件产生之后,系统需要把这个事件传递给一个具体的VIew,这个传递的过程就是事件分发!点击事件的分发过程由三个很重要的方法来共同完成:

• dispatchTouchEvent(MotionEvent ev)

用来事件的分发,如果事件可以传递给当前View那么此方法一定会被调用,返回的结果手当前的View的onTouchEvent 和下级的dispatchTouchEvent 方法的影响,表示是否消耗当前事件.

• onInterceptTouchEvent(MotionEvent ev)

在上述方法内部调用,用来判断是否拦截某个事件,如果当前View 拦截了某个事件,那么在同一个事件序列当中,此方法不会被再次调用,返回结果表示是否拦截当前的事件

• onTouchEvent(MotionEvent ev)

在dispatchTouchEvent 方法中调用,用来处理点击事件,返回结果表示是否消耗当前事件,如果不消耗,则在同一个事件序列中,当前View无法再次接受到事件.

具体表示为:

public boolean dispatchTouchEvent(MotionEvent ev){
        boolean consume = false;
        if(onInterceptTouchEvent(ev)){
        consume = onTouchEvent(ev);
        }else{
        
        consume = child.dispatchTouchEvent(ev);
        }

    return consume;

}

事件分发图解

上述伪代码可以看清楚事件传递的规则:

对于一个根的ViewGroup来说,点击事件产生之后,首先会传递给他,这个时候他的dispatchTouchEvent会被调用,如果这个ViewGroup的onInterceptTouchEvent 方法返回true,就表示它要拦截当前的事件,接着事件就交给ViewGroup处理,就是它的onTouchEvent 方法就会被调用;如果这个ViewGroup的onInterceptTouchEvent 方法返回false,就表示它不拦截当前事件,这时候当前事件就继续传递给他的子元素,接着子元素的dispatchTouchEvent方法就会被调用.如此反复知道事件被最终处理!

上面图中其实还缺失了一块:

activity首先会将事件分发给Window处理，调用Window的superDispatchTouchEvent；

 public boolean dispatchTouchEvent(MotionEvent ev) {
        if (ev.getAction() == MotionEvent.ACTION_DOWN) {
            onUserInteraction();
        }
        if (getWindow().superDispatchTouchEvent(ev)) {
            return true;
        }
        return onTouchEvent(ev);
    }

然后在在window 类的唯一子类PhoneWindow 的 superDispatchTouchEvent 方法内调用的DecorView的superDispatchTouchEvent:

 @Override
    public boolean superDispatchTouchEvent(MotionEvent event) {
        return mDecor.superDispatchTouchEvent(event);
    }

这个DecorView其实就是一个FrameLayout,也就是整个布局的根布局, DecorView会调用父类FrameLayout 的dispatchTouchEvent 的函数进行传递!

备注
这个DecorView 调用父类FrameLayout 的superDispatchTouchEvent 这个函数其实是来自FrameLayout的父类,也就是ViewGroup的dispatchTouchEvent,而不是FrameLayout 它自己的,到这也就都串起来了

    public boolean superDispatchTouchEvent(MotionEvent event) {
        return super.dispatchTouchEvent(event);
    }

PhoneWindow又会调用DectorViewsuperDispatchTouchEvent方法.DectorView会调用父类FrameLayout也就是ViewGroup的dispatchTouchEvent方法进行事件分发,接着就会分发发到用户调用setContentView传入的ViewGroup的dispatchTouchEvent中

事件传递的流程

Activity--> PhoneWindow -->DecorView -->ViewGroup ... View  

事件的回传

Activity <-- PhoneWindow <--DecorView <--ViewGroup ... View

至此,其实可以完全理解事件传递的整个流程了!
可以得出一些结论:

• 事件传递是从手指按下开始,到手指松开结束

• 正常情况下,一个事件序列只能被一个View拦截且消费,因为一旦一个元素拦截了某些事件,那么同一个事件序列内的所有事件都会直接传递给它处理,因此同一个事件序列中的事件不能分别由两个View同时处理

• 某一个view 一旦决定拦截,那么这一事件都只能由它处理,并且他的onInterceptTouchEvent不会再调用(针对的是ViewGroup,View 作为整个事件传递的最低端,要么消费事件,前提是事件可以分发到它这里,要么就不处理返回)

• ViewGroup 默认不拦截任何事件,源码中直接返回false

• View 没有onInterceptTouchEvent 分发,一旦事件传递给他,那么它的onTouchEvent分发就会被调用