标签:
昨天在用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)方法重置。
探究requestDisallowInterceptTouchEvent失效的原因
标签:
原文地址:http://www.cnblogs.com/bhlsheji/p/5307724.html