Android事件分发机制记录
前言
实际开发中，竟然很少碰到需要处理滑动冲突的场景，所以关于Android的事件分发知识一直没有接触过，这两天学习了下，初看好像还不难理解，ViewGroup向自己的子View分发事件，可以选择拦截起来自己处理，也可以不拦截转而交给子View去处理，但事实没这么简单。
正文
首先稍微具体了解一下事件分发的过程：ViewGroup在点击事件到来时，会询问自己要不要拦截，要拦截，就交给自己的onTouchEvent处理，如果自己的onTouchEvent不处理，就再向上传递；如果onTouchEvent愿意处理，那么后续拦截下来的事件都会交给它处理；如果不拦截，就会派发给子View，子View调用onTouchEvent来处理这个事件，如果子View也不处理，那就反弹给派发给它的上层。
以上简短的阐述，看起来是没什么难度，符合科学，但是如果想深入了解就会有几个问题：
1.ViewGroup拦截了事件，是怎么交给onTouchEvent去处理的；
2.onTouchEvent不处理时，是怎么向上传递给上层的onTouchEvent处理的；
第一个问题分析：
ViewGroup拦截了事件，交给onTouchEvent去处理，意思就是在拦截了事件后，调用到了onTouchEvent，我们带着这个猜测到源码里找答案。
事件分发的源头是Activity，分发到顶层View，也就是DecorView，DecorView再分发给下一级的ViewGroup，这个过程平时应该基本不会接触到，所以直接从接地气的ViewGroup分发开始研究。
先看用来进行事件分发的方法
ViewGroup.class
@Override
public boolean dispatchTouchEvent(MotionEvent ev) {
...
// Check for interception.
final boolean intercepted;
if (actionMasked == MotionEvent.ACTION_DOWN
|| mFirstTouchTarget != null) {
final boolean disallowIntercept = (mGroupFlags & FLAG_DISALLOW_INTERCEPT) != 0;
if (!disallowIntercept) {
intercepted = onInterceptTouchEvent(ev); //回调拦截方法
ev.setAction(action); // restore action in case it was changed
} else {
intercepted = false;
}
} else {
// There are no touch targets and this action is not an initial down
// so this view group continues to intercept touches.
intercepted = true;
}
...
这是ViewGroup重写了父类View的dispatchTouchEvent方法，主要是要拦截或派发消息给子view。当一个点击事件到达这个ViewGroup，会先来到这个方法，首先询问自己是否要拦截这个点击事件，从源码知道onInterceptTouchEvent默认是返回false的，也就是ViewGroup默认是不拦截任何事件的，先来两个if判断，第一个if判断：是否是DOWN事件或者子View是否消费了该点击事件，分析下为什么判断这两个条件：DOWN事件比较好理解，因为DOWN事件代表的是一个事件序列的开始，每次用户一DOWN，就要走一下onInterceptTouchEvent询问自己是否要拦截；mFirstTouchTarget 判断的是子view是否愿意消费这个事件序列，不为null就说明愿意消费（这个源码后面会贴上），这时候也还是要先询问下ViewGroup要不要拦截。相反的如果这两个条件同时不成立，actionMasked ！= MotionEvent.ACTION_DOWN&& mFirstTouchTarget == null，这说明了没有子view愿意处理事件，那么就不会再去询问拦截了，而是交给自己的onTouchEvent来处理。其实以上讲的进入拦截判断，还需要
进入第二个if判断，判断子View是否要让父View拦截事件（这里是通过requestDisallowInterceptTouchEvent来指使的）。
接下来就是处理拦不拦截的后续工作，intercepted 是true还是false，我们分为拦截与不拦截两种情况分别分析。
-
拦截
ViewGroup决定拦截事件！ intercepted = onInterceptTouchEvent(ev)为true，会调用到super.dispatchTouchEvent(event)，也就是父类View的dispatchTouchEvent方法
View.class
public boolean dispatchTouchEvent(MotionEvent event) {
...
if (li != null && li.mOnTouchListener != null
&& (mViewFlags & ENABLED_MASK) == ENABLED
&& li.mOnTouchListener.onTouch(this, event)) {
result = true;
}
if (!result && onTouchEvent(event)) {
result = true;
}
...
}
这里会先进行四个条件的判断，li是监听器们的包装对象，不为空，mOnTouchListener是否为空，view是否可点击，onTouch是否返回true，如果这些条件成立，那dispatchTouchEvent就直接返回true，直接就消费了该事件；否则就进入下一个if判断，也就是调用onTouchEvent方法，这个方法略长，其实就是判断view是否可点击（返回true，反之false）。
这就回答了我们之前的第一个问题，理一下：当Viewgroup决定拦截这个序列的事件，除非应用层注册了Touch事件消费掉，否则后续除了down事件，其他move，up事件都会直接交给onTouchEvent方法处理，当然从上段源码看出onTouchEvent也必须返回true，dispatchTouchEvent才能返回true，代表要消费这次事件，上层才会把事件发给你处理。那如果onTouchEvent返回false不处理呢？那么后续除了down事件，其他事件都不会再派发onTouchEvent。
这么一说，我们也隐约知道上层是根据你子元素的dispatchTouchEvent返回值来给你派发消息的，去源码寻找证据吧。顺便带上我们的第二个问题，我们可以直接把当前这层当成所谓的“上层”，然后给它的子View派发事件，也就是我们这层不拦截事件
-
不拦截
一样是回到ViewGroup的dispatchTouchEvent方法
@Override
public boolean dispatchTouchEvent(MotionEvent ev) {
...
//intercepted false 不拦截
if (!canceled && !intercepted) {
final View[] children = mChildren;
for (int i = childrenCount - 1; i >= 0; i--) {
//这个for循环就是给子view派发事件的
if (dispatchTransformedTouchEvent(ev, false, child, idBitsToAssign)) {
// Child wants to receive touch within its bounds.
mLastTouchDownTime = ev.getDownTime();
if (preorderedList != null) {
// childIndex points into presorted list, find original index
for (int j = 0; j < childrenCount; j++) {
if (children[childIndex] == mChildren[j]) {
mLastTouchDownIndex = j;
break;
}
}
} else {
mLastTouchDownIndex = childIndex;
}
mLastTouchDownX = ev.getX();
mLastTouchDownY = ev.getY();
newTouchTarget = addTouchTarget(child, idBitsToAssign);
alreadyDispatchedToNewTouchTarget = true;
break;
}
}
}
}
...
上面我们说了，上层是根据我们的dispatchTouchEvent返回值决定是否给我们派发事件，那我们现在是上层了，要给子View派发事件，就要看子view的dispatchTouchEvent给我们返回true还是false，很显然上面遍历子view的时候，我们看到if (dispatchTransformedTouchEvent(ev, false, child, idBitsToAssign))这个判断，进入方法看下
private boolean dispatchTransformedTouchEvent(MotionEvent event, boolean cancel,
View child, int desiredPointerIdBits) {
final boolean handled;
// Canceling motions is a special case. We don't need to perform any transformations
// or filtering. The important part is the action, not the contents.
final int oldAction = event.getAction();
if (cancel || oldAction == MotionEvent.ACTION_CANCEL) {
event.setAction(MotionEvent.ACTION_CANCEL);
if (child == null) {
handled = super.dispatchTouchEvent(event);
} else {
handled = child.dispatchTouchEvent(event); //获得子view返回值
}
event.setAction(oldAction);
return handled;
}
}
如果handled是true的话，就说明子view要处理这个事件序列，后续上层就不应该再去判断拦不拦截，而是直接派发事件给这个子 view，那这个逻辑是怎么做的呢。先看下上面for循环：当dispatchTransformedTouchEvent方法返回true时，进入方法体看到 newTouchTarget = addTouchTarget(child, idBitsToAssign);这个newTouchTarget 就是第一段源码里的mFirstTouchTarget，这是返回true的情况，如果子view返回false不处理呢，这时候 就为空，那我们看它为空时怎么处理的
// Dispatch to touch targets.
if (mFirstTouchTarget == null) {
// No touch targets so treat this as an ordinary view.
handled = dispatchTransformedTouchEvent(ev, canceled, null,
TouchTarget.ALL_POINTER_IDS);
}
依然是调用dispatchTransformedTouchEvent，这里child传入是null，由此知道会调用super.dispatchTouchEvent(event);也就是上面阐述的内容了，最终交给View的onTouchEvent处理
这就是第二个问题的分析，理一下：ViewGroup不拦截事件，派发到它的子view，如果子view没有注册onTouch事件，就调用了自己的onTouchEvent并返回true或者false，这时候ViewGroup会得到这个值，来回调自己的dispatchTouchEvent，进而调用自己的onTouchEvent。注意这时候是不会走拦截方法了，因为上文所讲的mFirstTouchTarget = null。这就是所谓的子view的onTouchView不处理事件时，会饭回来给派发者，也就是ViewGroup的onTouchEvent来处理。
-
未完待续
这一篇主要是自己阅读源码，加上阅读任主席的开发艺术做的笔记，理解上可能还有偏差，所以后续再写一篇实战，Kotlin版的，加深理解。（2018.08.28更新：实战版已发布，直通车：Kotlin实现一个支持侧滑删除的ViewGroup
）
