android 事件机制，

view的事件机制：

不管是DOWN，MOVE，UP都会按照下面的顺序执行：

1、dispatchTouchEvent,（其中这个方法包括了setOnTouchListener（），还有onTouch（）方法）

2、 setOnTouchListener的onTouchListener

3、onTouchEvent 

分析：在dispatchTOucheEvent()首先判断mOnTouchListener不为null，并且view是enable的状态，然后 mOnTouchListener.onTouch(this, event)返回true，这三个条件如果都满足，直接return true ; 也就是不执行onTouchEvent(event）;

（1）mOnTouchListener是否为null就的看他什么时候负值的，这个时候我们在源码中看到setOnTouchListener（）

（2）ENABLED是判断当前点击的控件是否是enable的，按钮默认都是enable的，因此这个条件恒定为true。

（3） mOnTouchListener.onTouch(this, event)，回调控件注册touch事件时的onTouch方法。也就是说如果我们在onTouch方法里返回                   true，就会让这三个条件全部成立，从而整个方法直接返回true。如果我们在onTouch方法里返回false，就会再去执行                                       onTouchEvent(event)方法。

   注：这里面就会出现你在代码中view.setOnTouchListener(new OnTouch(){   return  true}),导致了你onTouchEvent(event)没执行了

onTouchEvent()方法中 就会去判断你的点击事件类型 比如长按还是点击，手指的操作类型，按下，移动，抬起，（对了这个里面点用了onclick（）方法，这个需要知道）

 （1） setEnable（false），CLICKABLE 都是在这个里面进行判断，false的话都会直接return false；

 （2）onclick()方法在switch()中up情况下调用（先是调用performClick() ，onclick（）就在这个方法中），这个方法其实就是      我们            长写的button.setOnClickListener(new OnClickListener(....))

ViewGroup事件分发：

其实比上面的view多了一些流程，就是事件怎么传递的，怎么

 这里举个栗子，（1）公司项目bug了，老板一般先找项目经理，然后项目经理再去找你，然后你解决bug，然后告诉经理，经理就不用管了（一个正常的分发）

这里的bug就是一个事件，老板就是一个屏幕吧，项目经理就是一个viewGroup，你就是一个button，

（2）公司项目bug了，老板找项目经理，经理自己解决了bug，就不去找你了，（相当于事件  给拦截了）

（3）公司项目bug了，老板找经理，经理丢给你，你发现自己解决不了，有丢给经理，然后经理给解决了（事件回传）

带着这个栗子去理解源码：

分析：把ViewGroup看作一个View，一样执行上面view的3个循序，只是在dispatchTouchEvent（）中多了一个事件拦截的步骤也就是disallowIntercept变量和onInterceptTouchEvent（ev）方法，他拦截之后就不给他下面的view或者viewGroup了，如果不拦截，就给传下去下面的view和viewGroup去处理事件 ，如果这些事件在view和viewGroup没有处理，那么会回传去，这个ViewGroup自己去处理事件，处理事件就是相当于view的事件了。。。

事件拦截，是由disallowInercept || !onInterceptTouchEven(ev)  控制的(或的关系，第二个条件取放。。不要看错了)

（1）disallowIntercept是指是否禁用掉事件拦截的功能，默认是false，也可以通过调用requestDisallowInterceptTouchEvent方法对这个值进行修改

（2）onInterceptTouchEvent方法对事件传递进行拦截，onInterceptTouchEvent方法返回true代表不允许事件继续向子View传递，返回false代表不对事件进行拦截，默认返回false。

 子view和ViewGroup把事件处理掉了 ，直接在onTouchEvent（）中返回true就可以了，返回false就会回传给他的父控件，

最后说下事件拦截的一些事例（http://blog.csdn.net/lmj623565791/article/details/39102591）

（1）如何拦截

重写ViewGroup的onInterceptTouchEvent方法

@Override  
    public boolean onInterceptTouchEvent(MotionEvent ev)  
    {  
        int action = ev.getAction();  
        switch (action)  
        {  
        case MotionEvent.ACTION_DOWN:  
            //如果你觉得需要拦截  
            return true ;   
        case MotionEvent.ACTION_MOVE:  
            //如果你觉得需要拦截  
            return true ;   
        case MotionEvent.ACTION_UP:  
            //如果你觉得需要拦截  
            return true ;   
        }  
          
        return false;  
    }  

默认是不拦截的，即返回false；如果你需要拦截，只要return true就行了，这要该事件就不会往子View传递了，并且如果你在DOWN retrun true ，则DOWN,MOVE,UP子View都不会捕获事件；如果你在MOVE return true , 则子View在MOVE和UP都不会捕获事件。

原因很简单，当onInterceptTouchEvent(ev) return true的时候，会把mMotionTarget 置为null ; 

（2）如何不被拦截

如果ViewGroup的onInterceptTouchEvent(ev) 当ACTION_MOVE时return true ，即拦截了子View的MOVE以及UP事件；

此时子View希望依然能够响应MOVE和UP时该咋办呢？

Android给我们提供了一个方法：requestDisallowInterceptTouchEvent(boolean) 用于设置是否允许拦截，我们在子View的dispatchTouchEvent中直接这么写：

@Override  
    public boolean dispatchTouchEvent(MotionEvent event)  
    {  
        getParent().requestDisallowInterceptTouchEvent(true);    
        int action = event.getAction();  
  
        switch (action)  
        {  
        case MotionEvent.ACTION_DOWN:  
            Log.e(TAG, "dispatchTouchEvent ACTION_DOWN");  
            break;  
        case MotionEvent.ACTION_MOVE:  
            Log.e(TAG, "dispatchTouchEvent ACTION_MOVE");  
            break;  
        case MotionEvent.ACTION_UP:  
            Log.e(TAG, "dispatchTouchEvent ACTION_UP");  
            break;  
  
        default:  
            break;  
        }  
        return super.dispatchTouchEvent(event);  
    }  

getParent().requestDisallowInterceptTouchEvent(true);  这样即使ViewGroup在MOVE的时候return true，子View依然可以捕获到MOVE以及UP事件。

参考博客：或者想细看事件分发的话

看到一个介绍很全面的文章http://blog.csdn.net/carson_ho/article/details/54136311

http://blog.csdn.net/guolin_blog/article/details/9153747

http://blog.csdn.net/lmj623565791/article/details/39102591

http://www.open-open.com/lib/view/open1462179977450.html