昨天在用requestDisallowInterceptTouchEvent的时候，发如今设置了requestDisallowInterceptTouchEvent(true)之后，父View的onInterceptTouchEvent方法照样运行。
怎么会这样呢？仅仅能通过查看源代码来一探到底了。
首先看下requestDisallowInterceptTouchEvent方法的源代码，在android.view.ViewGroup类中：
public void requestDisallowInterceptTouchEvent(boolean disallowIntercept) {
if (disallowIntercept == ((mGroupFlags & FLAG_DISALLOW_INTERCEPT) != 0)) {
// We're already in this state, assume our ancestors are too
return;
}
if (disallowIntercept) {
mGroupFlags |= FLAG_DISALLOW_INTERCEPT;
} else {
mGroupFlags &= ~FLAG_DISALLOW_INTERCEPT;
}
// Pass it up to our parent
if (mParent != null) {
mParent.requestDisallowInterceptTouchEvent(disallowIntercept);
}
}
这里看到，requestDisallowInterceptTouchEvent方法做了两个操作：
1. 设置ViewGroup自己的FLAG_DISALLOW_INTERCEPT标志位为true。
2. 递归设置ViewGroup其父View的FLAG_DISALLOW_INTERCEPT标志位为true。
主要和FLAG_DISALLOW_INTERCEPT标志位有关。这里全局看下android.view.ViewGroup的源码，发现仅仅有三个地方用到了FLAG_DISALLOW_INTERCEPT：
read：dispatchTouchEvent方法。
write：requestDisallowInterceptTouchEvent方法，resetTouchState方法。
先来看下涉及到write操作的地方，requestDisallowInterceptTouchEvent方法前面看过了，这里看下resetTouchState方法的源码：
/**
* Resets all touch state in preparation for a new cycle.
*/
private void resetTouchState() {
clearTouchTargets();
resetCancelNextUpFlag(this);
mGroupFlags &= ~FLAG_DISALLOW_INTERCEPT;
mNestedScrollAxes = SCROLL_AXIS_NONE;
}
这里看到。resetTouchState方法会把ViewGroup的FLAG_DISALLOW_INTERCEPT置为false。
再来看下涉及到读操作的dispatchTouchEvent方法的源码：
@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代码中唯一用到FLAG_DISALLOW_INTERCEPT的地方。它的主要罗辑就是推断ViewGroup的FLAG_DISALLOW_INTERCEPT标志位是否为true。假设为true，调用ViewGroup的onInterceptTouchEvent的方法。假设不是则不会走。
这也和requestDisallowInterceptTouchEvent的官方解释也是一致的。
而我遇到的问题是：明明调用了requestDisallowInterceptTouchEvent(true)方法。而还是走了ViewGroup的onInterceptTouchEvent方法，那仅仅有一个可能：FLAG_DISALLOW_INTERCEPT被改回了false。对FLAG_DISALLOW_INTERCEPT进行写操作的除了requestDisallowInterceptTouchEvent方法，仅仅有resetTouchState方法，一定是某个地方调用了resetTouchState方法，把FLAG_DISALLOW_INTERCEPT标志位置为false。才造成了我遇到的问题。
看一下resetTouchState的调用关系，发现仅仅有一个方法调用了：
@Override
public boolean dispatchTouchEvent(MotionEvent ev) {
......
final int action = ev.getAction();
final int actionMasked = action & MotionEvent.ACTION_MASK;
// Handle an initial down.
if (actionMasked == MotionEvent.ACTION_DOWN) {
// Throw away all previous state when starting a new touch gesture.
// The framework may have dropped the up or cancel event for the previous gesture
// due to an app switch, ANR, or some other state change.
cancelAndClearTouchTargets(ev);
resetTouchState();
}
......
// Update list of touch targets for pointer up or cancel, if needed.
if (canceled
|| actionMasked == MotionEvent.ACTION_UP
|| actionMasked == MotionEvent.) {
resetTouchState();
} else if (split && actionMasked == MotionEvent.ACTION_POINTER_UP) {
final int actionIndex = ev.getActionIndex();
final int idBitsToRemove = 1 << ev.getPointerId(actionIndex);
removePointersFromTouchTargets(idBitsToRemove);
}
......
}
看完代码就发现，原来在ViewGroup的ACTION_DOWN时，FLAG_DISALLOW_INTERCEPT标志位被置为false，这就是我使用requestDisallowInterceptTouchEvent方法失效的原因。由于我是在findView之后，直接调用的requestDisallowInterceptTouchEvent(true)，而在事件处理的開始(ACTION_DOWN)。这里又被设为了false。
怎么解决问题呢？仅仅有重写自己用到的View的onTouchEvent方法，在其ACTION_DOWN的时候，调用父View的requestDisallowInterceptTouchEvent(true)方法设置，在ACTION_UP或者ACTION_CANCEL的时候。调用调用父View的requestDisallowInterceptTouchEvent(false)方法重置。