１.前言
View的事件分发机制是面试的要点，也是必须要吃透的基础知识。虽然平时用到的地方不是那么频繁，但是一旦要用，如果这个不够扎实，就会卡手。就独立一篇来整理，日常开发中有发现有要注意的事情也在此补充归纳。
与View做交互操作会产生事件，事件起点是谁，系统是如何将一个事件从起点传到目标View的。带着疑问去探索。
2.点击事件的传递规则
起始与流通：
从Android应用层看，事件起于Activity,Activity也有dispatchTouchEvent,onTouchEvent方法。
Activity会传递给Window,Window会传给顶层View，顶层View分发给子View,一级级向下分发，如果某层不消费，则返给父层处理。
Activity -》 Window ->Decor View -> ContentView
形象地来看，就如上级分派任务给下级。
三个核心方法：
- public boolean dispatchTouchEvent(MotionEvent ev)
View都有。事件能传给当前View，则一定会调用．在这个方法会根据不同条件去调用onInterceptTouchEvent和onTouchEvent．返回值表示当前view是否消费了事件。
true消费了；false没消费，事件交给父View处理.所有的父View都不处理，则传回Activity，在Activity中消亡。 - public boolean onInterceptTouchEvent(MotionEvent ev)
仅ViewGroup有。返回值表示是否拦截事件。默认false不拦截，拦截则交给onTouch处理.不拦截交给子View处理(调用子View的dispatchTouchEvent（）)。 - public boolean onTouchEvent(MotionEvent ev)
View都有。返回值表示对事件的处理。true表示处理了，false表示不处理。
改变这三个方法的返回值可以改变事件分发传递的过程，需要注意这样做默认的父类处理逻辑就不会执行了。
onTouchListener与方法优先级：
View可以设置onTouchListener，这个监听能干扰View的事件分发过程。它会先于onTounchEvent执行，也就是它的优先级高。
优先级onTouchListener > onTouchEvent > onClickListener(具体View交互回调)
onTouchListener中方法onTouch默认返回false，onTouchEvent会调用；true，不会调用OnTouchEvent，认为是当前View消费事件，即dispatchTouchEvent 返回true。
无论onTouch怎样，dispatchTouchEvent最终都会调用，可以认为dispatchTouchEvent的优先级要高于onTouchListener。
View的dispatchTouchEvent（）源码直观地体现了这一点．
事件与事件序列：
一个事件序列指手指从接触屏幕一刻起到离开屏幕这个过程产生的一系列事件。事件序列完整才会有相应的View交互回调方法执行。有ACTION_DOWN起。。。ACTION_UP止。
正常情况下，一个事件序列交由一个View处理。一些特殊的手段可以让两个View都响应，比如在一个View的onTouchEvent中强行传递给其他View。
ViewGroup拦截ACTION_DOWN,ACTION_Down会传给自身的onTouchEvent．事件序列中之后事件不会再向下分发,传给自身的onTouchEvent．
ViewGroup拦截除ACTION_DOWN之外的事件，会产生一个ACTION_CANCEL的事件分发给子View.事件序列中之后的事件传给自身的onTouchEvent．此时mFirstTouchTarget为null，dispatchTouchEvent()不会调用onIntercepte()判断是否拦截，直接将intercepted赋值true．
View如果不消耗ACTION_DOWN事件(在onTounch或dispatchTouchEvent返回false)，ACTION_DOWN事件和事件序列中之后的事件都交给父View处理．
View如果不消耗除ACTION_DOWN事件之外的事件，当前事件交给父View处理，之后还是会继续接收到事件序列中之后的事件.
子View用requestDisallowInterceptTouchEvent设置标记量mGroupFlags是否允许父View拦截事件,默认值是允许．每当有ACTION_DOWN事件来时会重置此标记量允许．所以面对ACTION_DOWN事件时，ViewGroup总会调用自己的InterceptTouchEvent方法来询问自己是否要拦截事件。当此标记量设置成不允许的时候，除ACTION_DOWN事件，dispatchTouchEvent()不会调用onIntercepte()判断是否拦截，直接将intercepted赋值false．
longClickable与clickable对View事件消耗的影响
View的onTouchEvent默认都会消耗事件,除非是不可点击的,即longClickable与clickable都为false.
View的enable不影响事件分发.点击事件不会响应．
源码分析可以参考：
http://blog.csdn.net/weixin_37077539/article/details/54895485
可点击这个属性对View的事件消费有影响，在处理View的事件分发逻辑，记得检查View是否可点击．
dispatchTouchEvent()源码分析
原理在源码体现．
传送门：http://www.jianshu.com/p/93a060053cbc
3.滑动冲突实训
场景一：外部滑动方向与内部不一致。（外横内竖，viewpage已做外部拦截）
A：外部拦截法（常用）
重写父容器的onInterceptTouchEvent().当事件为ACTION_MOVE的时候。根据条件判断外部是否要拦截。ACTION_DOWN只在外层滑动将结束，优化滑动体验的时候才加上．
boolean intercepted = false;
int x = (int) ev.getX();
int y = (int) ev.getY();
switch (ev.getAction()) {
case MotionEvent.ACTION_DOWN:
intercepted = false;
if (!mScroller.isFinished()) {
mScroller.abortAnimation();
intercepted = true;
}
break;
case MotionEvent.ACTION_MOVE:
int deltaX = x - mLastXIntercept;
int deltaY = y - mLastYIntercept;
intercepted = Math.abs(deltaX) > Math.abs(deltaY);
break;
case MotionEvent.ACTION_UP:
//给子View响应点击事件
intercepted = false;
break;
}
mLastX = x;
mLastY = y;
mLastXIntercept = x;
mLastYIntercept = y;
return intercepted;
B：内部拦截法
内部拦截要重写父View的onInterceptTouchEvent与子View的dispatchTouchEvent().利用的是子View可以用getParent.requestDisallowInterceptTouchEvent()方法改变父View的拦截标记位mGroupFlags，达到事件按照业务规则给自己或者父View处理的目的．
使用这个方法需要注意
1.父View不能将ACTION_DOWN拦截掉，ACTION_DOWN一旦被拦截，子View得不到事件序列后续的事件.
2.较外部拦截的效果需要处理内部滑动后不再将事件给父View.
//内部拦截父View需要的代码
mLastX = (int) ev.getRawX();
mLastY = (int) ev.getRawY();
if (MotionEvent.ACTION_DOWN == ev.getAction()) {
if (!mScroller.isFinished()) {
mScroller.abortAnimation();
return true;
}
return false;
} else {
return true;
}
@Override
public boolean dispatchTouchEvent(MotionEvent ev) {
float x = ev.getRawX();
float y = ev.getRawY();
if (MotionEvent.ACTION_DOWN == ev.getAction()) {
getParent().requestDisallowInterceptTouchEvent(true);
slop = false;
}
if (MotionEvent.ACTION_MOVE == ev.getAction()) {
if (Math.abs(mLastY - y) < Math.abs(mLastX - x)) {
if (!slop) getParent().requestDisallowInterceptTouchEvent(false);
} else {
int touchSlop = ViewConfiguration.get(getContext()).getScaledTouchSlop();
if (Math.abs(y - mLastY) > touchSlop) {
//已经开始了竖向滑动
slop = true;
}
}
}
mLastX = x;
mLastY = y;
return super.dispatchTouchEvent(ev);
}
场景二：外部滑动方向与内部一致。
同场景一处理方式，区别在判断条件由业务定，看业务什么时候需要交给外层，什么时候需要交给内层。
场景三：场景一场景二交替同时出现
剥茧法层层解决．
可以加一些回弹或过渡效果使滑动冲突处理的过程显得更加圆滑。
后记
分发机制比较灵活，比较细腻，花我老长时间去分析理解巩固，源码风格不怎么利于阅读．．．233．有些情况套用公式是不行的，要多动手结合真实项目代码思考练习．
如果碰到不懂的地方，翻源码思考是一个比较好的选择．
Action_Cancle事件怎么产生与如何影响分发的，待做．
接下来会想对项目中RecyclerView左滑的实例进行思考探究．在这之前也需要有一定的View的绘制机制基础．
