一、Activity,Window,View
我们在View里面接收到的MotionEvent是哪里来的？
事件由系统先传递给Activity的dispatchTouchEvent方法，然后再通过window对象传递给decorView，decorView会最终传递给我们设置的布局里。
如何向下传递？
假设我们设置的顶级view是一个ViewGroup，那么事件会由Activity传递给DecorView,DecorView传递给我们的ViewGroup的dispatchTouchEvent方法。
然后会调用ViewGroup的onIntercepetionTouchEvent询问是否要拦截事件，如果此方法返回true则代表拦截，然后会调用此ViewGroup的onTouchEvent方法。
如果此ViewGroup的onTouchEvent方法返回true的话，那么后续所有的事件则不会调用onInterceptTouchEvent方法，会直接通过dispatchTouchEvent方法
进入onTouchEvent方法。如果此ViewGroup的onTouchEvent方法返回false的话，那么同一事件序列的其他事件也不会再交由它处理。为啥呢？因为当第一个
事件ACTION_DOWN经过一次完整的传递之后，它一定会找到自己的宿主，那么何为宿主？就是消耗了这个事件的那个东西，可以是Activity,可以是ViewGroup，可以是View，而当所有的View都不消耗这个事件时，那么这个事件最终是传回到Activity的onTouchEvent方法。而如果ACTION_DOWN传回到了Activity的onTouchEvent方法了，那么后续所有的事件都会直接走activity的dispatchTouchEvent方法并且直接交给onTouchEvent方法，事件就传递不下去了。
如果一个ViewGroup不拦截事件，但是它的onTouchEvent消耗了down事件，那么后续的所有事件也会传递给它，并且不询问onInterceptionTouchEvent方法。
如果当前View消耗了ACTION_DOWN事件，但是不消耗其他事件，那么其他事件不会像ACTION_DOWN一样回传给父View，而是直接交由Activity的onTouchEvent方法来处理。
总结：
总归来说最重要的一件事：通过ACTION_DOWN事件来确认，这一事件序列到底交由谁处理。而事件的回传机制也只是ACTION_DOWN事件，ACTION_MOVE,ACTION_UP没有回传这一概念。而所谓的onInterceptTouchEvent，也只是为了确定ACTION_DOWN的消耗着，假如一个ViewGroup的onInterceptTouchEvent方法返回true，那么ACTION_DOWN会直接交由它的onTouchEvent来执行，而它的onTouchEvent如果返回了false，那么会交由它的父View的onTouchEvent方法，如果它的父view的OnTouchEvent方法消耗了，那么后续的事件就会直接交由它的父View，如果它的父View返回的false，那么事件会依次向上传，反正总会找到一个宿主的。
view和activity没有onInterceptTouchEvent方法。
View默认的onTouchEvent方法的返回值由clickable和longclickable属性来决定，只要这两个属性中有一个为true，那么onTouchEvent就返回true，而longClickable默认为false，那么其实默认是由clickable属性来决定的。enable属性不影响。view如果是disable状态的话，不影响onTouchEvent的返回值，但是会影响onClick的执行。因为源码中会先判断enable属性。
如果设置了onTouchListener，onTouch方法会先于onTouchEvent方法。如果onTouch方法返回true，那么onTouchEvent不执行，如果返回false，那么再接着调用onTouchEvent方法，并且如果view设置了onClickListener，并且clickable或者longclickable属性有一个为true的话（事实上是，view执行了setOnClickListener或者setOnLongClickListener就会把对应的clickable或longclickable属性置为true的），并且没有设置TouchDelegate，则会执行onClick方法。