View的事件分发机制

阅读更多

【分享】
从某处看到的一个关于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方法就会被调用，如此反复直到事件被最终处理。当然如果所有View都不处理，这个事件最终会传递给当前的Activity处理。

Tips

1. 这里说View，有时候也指ViewGroup，因为ViewGroup也是继承自View,当然我并不愿意这样，毕竟java类的爸爸都是object，总不能都叫object吧，那不就没了区分，下面的小窍门我会分开说，不会都叫View。
2. onInterceptTouchEvent这个方法在View、Activity里都没有，在ViewGroup里有，View没有这个方法，也就是说，一旦有事件传给它，那么它的onTouchEvent就会被调用，Activity呢，在源码中是先交给Activity所附属的Window往下分发，有人要，即返回true的话，整个事件循环就结束了，但都没人要，即返回false的话，那么Activity的onTouchEvent就会被调用。
3. 总的事件传递规则，Activity->Window->View，但如果都不处理，就会原路返回，最后交给Activity处理。
4. 事件传递过程是由外向内的，我喜欢说成由上向下的，即事件总是传递给父元素，然后再由父元素分发传递给子View，但通过requestDisallowInterceptTouchEvent方法可以在子元素中干预父元素的事件分发过程，但是ACTION_DOWN事件除外。
5. ViewGroup默认是不拦截任何事件的，在源码中ViewGroup的onInterceptTouchEvent返回了false。但是，记住我上面说的话，分开讲，ViewGroup是ViewGroup，但继承ViewGroup的扩展，其onInterceptTouchEvent就不一定返回false。
6. 当一个View需要处理事件时，如果它设置了OnTouchListener，那么OnTouchListener中的onTouch方法会被调用，这时事件如何处理，还要看onTouch的返回值，如果返回了false，则当前View的onTouchEvent会被调用；如果返回了true，那么onTouchEvent方法将不会调用。简单一句，OnTouchListener的优先级比较高，但这也是可以理解的。
7. 那接着6，在谈谈OnClickListener吧，如果设置了OnClickListener，其onClick方法也会调用，但不会影响到View onTouchEvent方法的调用，即OnClickListener处在事件传递的尾端，优先级最低，可以理解的，因为如果设置了OnClickListener，View的onTouchEvent方法就不调用了，也不怎么现实啊，事件都没处理，就知道是点击了？

感谢大家的阅读，如有不理解的地方，欢迎在下方评论，也欢迎大家的收藏，这不是我的原创，算是我的分享，我的总结，希望能帮助到大家。