Android事件傳遞機制一直都是一個痛點，希望這篇文章能夠給你點不一樣的
基礎知識—>源碼分析—>進階—>應用場景
基礎知識
觸摸事件對應MotionEvent類，三種事件類型：ACTION_DOWN,ACTOIN_MOVE,ACTION_UP。
事件傳遞的三個階段：
-
分發(Dispatch)
方法：
public boolean dispatchTouchEvent(MotionEvent ev) -
攔截(Intercept)
方法：
public boolean onInterceptTouchEvent(MotionEvent ev) -
消費(Consume)
方法：
public boolean onTouchEvent(MotionEvent event)
Android中擁有事件處理能力的類有3種：
| 類 | dispatchTouchEvent | onInterceptTouchEvent | onTouchEvent |
|---|---|---|---|
| Activity | ?? | ?? | |
| ViewGroup | ?? | ?? | ?? |
| View | ?? | ?? |
正常狀態下事件傳遞機制如下圖(以下僅針對ACTION_DOWN事件)：
關于上圖有幾點說明(僅針對ACTION_DOWN事件的傳遞)：
dispatchTouchEvent和onTouchEvent一旦return true,終結事件傳遞；-
dispatchTouchEvent和onTouchEventreturn false,事件都回傳給父控件的onTouchEvent處理。dispatchTouchEvent返回值為 false,意味著事件停止往子View分發，并往父控件回溯。onTouchEvent返回值為 false,意味著不消費事件，并往父控件回溯。 -
return super.xxxxxx() 就會讓事件依照U型的方向的完整走完整個事件流動路徑。
ViewGroup的dispatchTouchEvent方法返回super的時候，默認調用onInterceptTouchEvent -
**
onInterceptTouchEventreturn true時, 攔截事件并交由自己的onTouchEvent處理 **onInterceptTouchEventreturn super和false, 不攔截事件，并將事件傳遞給子View。super.onInterceptTouchEvent(ev)的默認實現返回值為false。
源碼分析
知其然，還要知其所以然。通過源碼分析，可能會更深刻的理解View的事件分發的真正原理。
Activity的事件分發機制
首先看一下Activity的dispatchTouchEvent源碼：
/**
* Called to process touch screen events. You can override this to
* intercept all touch screen events before they are dispatched to the
* window. Be sure to call this implementation for touch screen events
* that should be handled normally.
*
* @param ev The touch screen event.
*
* @return boolean Return true if this event was consumed.
*/
public boolean dispatchTouchEvent(MotionEvent ev) {
// 事件序列開始一般都是ACTION_DOWN，此處一般為true
if (ev.getAction() == MotionEvent.ACTION_DOWN) {
// 空方法，主要用于屏保
onUserInteraction();
}
if (getWindow().superDispatchTouchEvent(ev)) {
return true;
}
return onTouchEvent(ev);
}
上面這段代碼，關鍵的就是：getWindow().superDispatchTouchEvent(ev)
Window是抽象類，PhoneWindow是Window的唯一實現類，Window的superDispatchTouchEvent(ev)是一個抽象方法，在PhoneWindow類中看一下superDispatchTouchEvent(ev)的實現：
@Override
public boolean superDispatchTouchEvent(MotionEvent event) {
// mDecor是DecorView的實例, DecorView是視圖的頂層view，繼承自FrameLayout，是所有界面的父類
return mDecor.superDispatchTouchEvent(event);
}
繼續追蹤一下mDecor.superDispatchTouchEvent(event)方法：
public boolean superDispatchTouchEvent(MotionEvent event) {
// DecorView繼承自FrameLayout,那么它的父類就是ViewGroup
// 而super.dispatchTouchEvent(event)方法，其實就應該是ViewGroup的dispatchTouchEvent()
return super.dispatchTouchEvent(event);
}
顯然，當一個點擊事件發生時，事件最先傳到Activity的dispatchTouchEvent進行事件分發，最終是調用了ViewGroup的dispatchTouchEvent方法, 這樣事件就從Activity傳遞到了ViewGroup。
ViewGroup的事件分發機制
-
ViewGroup攔截事件
ViewGroup的
dispatchTouchEvent方法較長，分段進行說明。// Check for interception. final boolean intercepted; // 關注點1 if (actionMasked == MotionEvent.ACTION_DOWN || mFirstTouchTarget != null) { // 關注點2 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; }關注點1: 當事件由
ViewGroup子元素成功處理時，會被賦值并指向子元素，即當ViewGroup不攔截事件并將事件交由子元素處理時，mFirstTouchTarget != null成立。-
關注點2:
FLAG_DISALLOW_INTERCEPT標記位，通過requestDisallowInterceptTouchEvent方法進行設置，一般用于子View中。FLAG_DISALLOW_INTERCEPT一旦設置之后，ViewGroup將無法攔截除ACTION_DOWN以外的其他點擊事件。原因參見以下代碼：// 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(); }ViewGroup會在
ACTION_DOWN事件到來時做重置狀態的操作。在resetTouchState方法中重置FLAG_DISALLOW_INTERCEPT標記位。因此，子View調用requestDisallowInterceptTouchEvent方法并不能影響ViewGroup對ACTION_DOWN事件的處理。 -
結論：
當ViewGroup決定攔截事件后，那么后續的點擊事件將默認交給它處理并且不再調用它的
onInterceptTouchEvent方法。FLAG_DISALLOW_INTERCEPT標記位的作用是讓ViewGroup不再攔截事件，前提是ViewGroup不攔截ACTION_DOWN事件。
-
ViewGroup不攔截事件
ViewGroup不攔截事件的時候，事件會向下分發交由它的子View進行處理：
final View[] children = mChildren; for (int i = childrenCount - 1; i >= 0; i--) { final int childIndex = getAndVerifyPreorderedIndex( childrenCount, i, customOrder); final View child = getAndVerifyPreorderedView( preorderedList, children, childIndex); // If there is a view that has accessibility focus we want it // to get the event first and if not handled we will perform a // normal dispatch. We may do a double iteration but this is // safer given the timeframe. if (childWithAccessibilityFocus != null) { if (childWithAccessibilityFocus != child) { continue; } childWithAccessibilityFocus = null; i = childrenCount - 1; } // 判斷子元素能否接收到點擊事件 // 1. 子元素是否在播放動畫 // 2. 點擊事件的坐標是否落在子元素區域內 if (!canViewReceivePointerEvents(child) || !isTransformedTouchPointInView(x, y, child, null)) { ev.setTargetAccessibilityFocus(false); continue; } newTouchTarget = getTouchTarget(child); if (newTouchTarget != null) { // Child is already receiving touch within its bounds. // Give it the new pointer in addition to the ones it is handling. newTouchTarget.pointerIdBits |= idBitsToAssign; break; } resetCancelNextUpFlag(child); // 關注點1 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(); // 關注點2 newTouchTarget = addTouchTarget(child, idBitsToAssign); alreadyDispatchedToNewTouchTarget = true; break; } // The accessibility focus didn't handle the event, so clear // the flag and do a normal dispatch to all children. ev.setTargetAccessibilityFocus(false); }-
關注點1:
dispatchTransformedTouchEvent實際上調用的就是子元素的dispatchTouchEvent方法：if (child == null) { handled = super.dispatchTouchEvent(event); } else { handled = child.dispatchTouchEvent(event); } -
關注點2: 當子元素的
dispatchTouchEvent返回值為true時，mFirstTouchTarget就會被賦值，并跳出for循環，終止對子元素的遍歷：newTouchTarget = addTouchTarget(child, idBitsToAssign); alreadyDispatchedToNewTouchTarget = true;mFirstTouchTarget被賦值是在addTouchTarget內部實現的：private TouchTarget addTouchTarget(@NonNull View child, int pointerIdBits) { final TouchTarget target = TouchTarget.obtain(child, pointerIdBits); target.next = mFirstTouchTarget; mFirstTouchTarget = target; return target; }可以看出，
mFirstTouchTarget是一種單鏈表結構。mFirstTouchTarget是否被賦值將直接影響Viewgroup對事件的攔截策略。如果mFirstTouchTarget為null，ViewGroup默認攔截同一序列中的所有點擊事件。 -
關注點3: 當ViewGroup沒有子元素，或者子元素的
dispatchTouchEvent返回值為false，在這兩種情況下，ViewGroup會自己處理點擊事件：// 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的事件分發機制
View的事件分發機制相對簡單一些，先看它的dispatchTouchEvent方法：
public boolean dispatchTouchEvent(MotionEvent event) {
...
boolean result = false;
...
if (onFilterTouchEventForSecurity(event)) {
if ((mViewFlags & ENABLED_MASK) == ENABLED && handleScrollBarDragging(event)) {
result = true;
}
//noinspection SimplifiableIfStatement
ListenerInfo li = mListenerInfo;
// 關注點1
if (li != null && li.mOnTouchListener != null
&& (mViewFlags & ENABLED_MASK) == ENABLED
&& li.mOnTouchListener.onTouch(this, event)) {
result = true;
}
if (!result && onTouchEvent(event)) {
result = true;
}
}
...
return result;
}
代碼中可以看出，OnTouchListener優先級高于onTouchEvent。
關注點1:View對點擊事件的處理過程，三個判斷條件，
-
li != null && li.mOnTouchListener != null： 判斷是否設置了OnTouchListener -
(mViewFlags & ENABLED_MASK) == ENABLED：判斷當前點擊的控件是否enable，很多View默認是enable的，因此該條件恒定為true -
li.mOnTouchListener.onTouch(this, event)：回調onTouch方法，如果返回值為true的話，上述三個條件全部成立，從而整個方法直接返回true；返回值為false的時候，就會去執行onTouchEvent(event)方法。
再看一下onTouchEvent的實現：
public boolean onTouchEvent(MotionEvent event) {
...
// 不可用狀態下的View照樣會消耗點擊事件
if ((viewFlags & ENABLED_MASK) == DISABLED) {
if (action == MotionEvent.ACTION_UP && (mPrivateFlags & PFLAG_PRESSED) != 0) {
setPressed(false);
}
// A disabled view that is clickable still consumes the touch
// events, it just doesn't respond to them.
return (((viewFlags & CLICKABLE) == CLICKABLE
|| (viewFlags & LONG_CLICKABLE) == LONG_CLICKABLE)
|| (viewFlags & CONTEXT_CLICKABLE) == CONTEXT_CLICKABLE);
}
if (mTouchDelegate != null) {
if (mTouchDelegate.onTouchEvent(event)) {
return true;
}
}
if (((viewFlags & CLICKABLE) == CLICKABLE ||
(viewFlags & LONG_CLICKABLE) == LONG_CLICKABLE) ||
(viewFlags & CONTEXT_CLICKABLE) == CONTEXT_CLICKABLE) {
switch (action) {
case MotionEvent.ACTION_UP:
boolean prepressed = (mPrivateFlags & PFLAG_PREPRESSED) != 0;
if ((mPrivateFlags & PFLAG_PRESSED) != 0 || prepressed) {
// take focus if we don't have it already and we should in
// touch mode.
boolean focusTaken = false;
if (isFocusable() && isFocusableInTouchMode() && !isFocused()) {
focusTaken = requestFocus();
}
if (prepressed) {
// The button is being released before we actually
// showed it as pressed. Make it show the pressed
// state now (before scheduling the click) to ensure
// the user sees it.
setPressed(true, x, y);
}
if (!mHasPerformedLongPress && !mIgnoreNextUpEvent) {
// This is a tap, so remove the longpress check
removeLongPressCallback();
// Only perform take click actions if we were in the pressed state
if (!focusTaken) {
// Use a Runnable and post this rather than calling
// performClick directly. This lets other visual state
// of the view update before click actions start.
if (mPerformClick == null) {
mPerformClick = new PerformClick();
}
if (!post(mPerformClick)) {
// 關注點1
performClick();
}
}
}
if (mUnsetPressedState == null) {
mUnsetPressedState = new UnsetPressedState();
}
if (prepressed) {
postDelayed(mUnsetPressedState,
ViewConfiguration.getPressedStateDuration());
} else if (!post(mUnsetPressedState)) {
// If the post failed, unpress right now
mUnsetPressedState.run();
}
removeTapCallback();
}
mIgnoreNextUpEvent = false;
break;
case MotionEvent.ACTION_DOWN:
...
break;
case MotionEvent.ACTION_CANCEL:
...
break;
case MotionEvent.ACTION_MOVE:
...
break;
}
return true;
}
return false;
}
-
關注點1: 當
ACTION_UP事件發生時，會觸發performClick方法：public boolean performClick() { final boolean result; final ListenerInfo li = mListenerInfo; if (li != null && li.mOnClickListener != null) { playSoundEffect(SoundEffectConstants.CLICK); li.mOnClickListener.onClick(this); result = true; } else { result = false; } sendAccessibilityEvent(AccessibilityEvent.TYPE_VIEW_CLICKED); return result; }如果View設置了
OnClickListener，那么performClick方法內部會調用它的onClick方法。 -
總結：
onTouch的優先級高于onClick
-
控件被點擊時，
onTouch返回false—>dispatchTouchEvent方法返回false—>執行onTouchEvent—>在performClick方法里回調onClickonTouch返回true—>dispatchTouchEvent方法返回true—>不執行onTouchEvent，顯然onClick方法也不會被調用
進階
ACTION_MOVE和ACTION_UP相關
先來看看兩個實驗：
-
在View的
dispatchTouchEvent返回false并且在ViewGroup的onTouchEvent返回true
紅色的箭頭代表ACTION_DOWN事件的流向
藍色的箭頭代表ACTION_MOVE和ACTION_UP事件的流向
ViewDispatch_2 -
在
ViewGroup的onTouchEvent返回true
紅色的箭頭代表ACTION_DOWN 事件的流向
藍色的箭頭代表ACTION_MOVE 和 ACTION_UP 事件的流向
ViewDispatch_03
總結一下：
如果在某個控件的
dispatchTouchEvent返回true消費終結事件，那么收到ACTION_DOWN的函數也能收到ACTION_MOVE和ACTION_UP。在哪個View的
onTouchEvent返回true，那么ACTION_MOVE和ACTION_UP的事件從上往下傳到這個View后就不再往下傳遞了，而直接傳給自己的onTouchEvent并結束本次事件傳遞過程。-
ACTION_DOWN事件在哪個控件消費了（return true）， 那么ACTION_MOVE和ACTION_UP就會從上往下（通過dispatchTouchEvent）做事件分發往下傳，就只會傳到這個控件，不會繼續往下傳如果
ACTION_DOWN事件是在dispatchTouchEvent消費，那么事件到此為止停止傳遞如果
ACTION_DOWN事件是在onTouchEvent消費的，那么會把ACTION_MOVE或ACTION_UP事件傳給該控件的onTouchEvent處理并結束傳遞。
onTouch()和onTouchEvent()的區別
兩個方法都是在View的
dispatchTouchEvent中調用，但onTouch優先于onTouchEvent執行。如果在
onTouch方法中返回true將事件消費掉，onTouchEvent將不會再執行。-
View的dispatchTouchEvent方法中：
if (li != null && li.mOnTouchListener != null && (mViewFlags & ENABLED_MASK) == ENABLED && li.mOnTouchListener.onTouch(this, event)) { result = true; } if (!result && onTouchEvent(event)) { result = true; }onTouch能夠執行需要的兩個前提：-
mOnTouchListener不為空 - 當前點擊的控件必須是
ENABLED
因此如果你有一個控件是非enable的，那么給它注冊
onTouch事件將不會執行。 -
應用場景—滑動沖突的解決
滑動沖突在Android開發中一直都是一個痛點，之前的所有講解，就像是所有的招式，滑動沖突，就是我們的用武之地。
常見滑動沖突場景
-
外部滑動和內部滑動方向不一致
ViewPager和Fragment配合使用組成的頁面滑動效果。這種沖突的解決方式，一般都是根據水平滑動還是豎直滑動(滑動的距離差)來判斷到底是由誰來攔截事件。
-
外部滑動和內部滑動方向一致
內外兩層同時能上下滑動或者能同時左右滑動。這種一般都是根據業務來進行區分。
以上兩種場景的嵌套
滑動沖突的解決方式
-
外部攔截法
外部攔截法，就是所有事件都先經過父容器的攔截處理，由父容器來決定是否攔截。這種方式需要重寫父容器的
onInterceptTouchEvent方法，偽代碼如下：public boolean onInterceptTouchEvent(MotionEvent ev) { boolean intercepted = false; int x = (int) ev.getX(); int y = (int) ev.getY(); switch (ev.getAction()) { case MotionEvent.ACTION_DOWN: intercepted = false; break; case MotionEvent.ACTION_MOVE: if (父容器需要當前點擊事件) { intercepted = true; } else { intercepted = false; } break; case MotionEvent.ACTION_UP: intercepted=false; break; default: break; } mLastXIntercept = x; mLastYIntercept = y; return intercepted; }幾點說明：
- 不攔截
ACTION_DOWN事件。一旦父容器攔截ACTION_DOWN，則后續的ACTION_MOVE和ACTION_UP事件都會直接交由父容器處理，無法傳遞給子元素。 -
ACTION_MOVE事件根據具體需求來決定是否攔截。 -
ACTION_UP事件必須返回false，ACTION_UP事件本身沒什么意義，但如果父容器在ACTION_UP返回true會導致子元素無法接收ACTION_UP事件，無法響應onClick事件。
- 不攔截
-
內部攔截法
內部攔截法是指父容器不攔截任何事件，所有事件都傳遞給子元素。內部攔截法需要配合
requestDisallowInterceptTouchEvent方法才能正常工作。這種方式需要重寫子元素的dispatchTouchEvent方法，偽代碼如下：public boolean dispatchTouchEvent(MotionEvent ev) { int x = (int) ev.getX(); int y = (int) ev.getY(); switch (ev.getAction()) { case MotionEvent.ACTION_DOWN: getParent().requestDisallowInterceptTouchEvent(true); break; case MotionEvent.ACTION_MOVE: int deltaX = x - mLastX; int deltaY = y - mLastY; if (父容器需要當前點擊事件) { getParent().requestDisallowInterceptTouchEvent(false); } break; case MotionEvent.ACTION_UP: break; default: break; } mLastX = x; mLastY = y; return super.dispatchTouchEvent(ev); }父元素需要默認攔截除
ACTION_DOWN事件以外的其他事件，父元素修改如下：public boolean onInterceptTouchEvent(MotionEvent ev) { if (ev.getAction()==MotionEvent.ACTION_DOWN) { return false; } else { return true; } }ACTION_DOWN事件并不受FLAG_DISALLOW_INTERCEPT這個標記位的控制。一旦父容器攔截ACTION_DOWN事件，那么所有的事件都無法傳遞到子元素中去。
參考
- 圖解Android事件分發機制
- Android事件分發機制詳解：史上最全面、最易懂
- Android開發藝術探索
