Android 事件分發(fā)機制-源碼分析

事件分發(fā).png

說明

  • 具體流程如圖所示，

  • 對于dispatchTouchEvent , onTouchEvent 返回 true 就是自己消費了，返回 false 就傳到父View 的onTouchEvent方法

  • ViewGroup 想把事件分發(fā)給自己的 onTouchEvent,需要在onInterceptTouchEvent方法中返回 true 把事件攔截下來

  • ViewGroup 的 onInterceptTouchEvent 默認(rèn)不攔截，所以 super.onInterceptTouchEvent() = false

  • View(這里指沒有子View)沒有攔截器,所以 View 的dispatchTouchEvent的super.dispatchTouchEvent(event)默認(rèn)把事件分發(fā)給自己的onTouchEvent

源碼解析(以下內(nèi)容部分來自書籍《Android開發(fā)藝術(shù)探索》)

Activity對點擊事件的分發(fā)過程

  • 當(dāng)一個點擊事件發(fā)生時，事件首先傳遞給當(dāng)前 Activity ，由 Activity 的 dispatchTouchEvent() 來進行事件的分發(fā)，具體的工作是由 Activity 內(nèi)部 Window來完成。Window 會將事件傳遞給 decor view, decor view 一般就是當(dāng)前 Activity 的頂層 View， 源碼如下:

Activity#dispatchTouchEvent

 public boolean dispatchTouchEvent(MotionEvent ev) {
        if (ev.getAction() == MotionEvent.ACTION_DOWN) {
            onUserInteraction();
        }
        if (getWindow().superDispatchTouchEvent(ev)) {
            return true;
        }
        return onTouchEvent(ev);
    }
  • 事件交給 Activity 所附屬的 Window 進行分發(fā)， 如果返回 true 整個循環(huán)就結(jié)束了，返回 false 就表示沒有人要處理，交由 Activity 的onTouchEvent處理；可知 Activity 調(diào)用 getWindow().superDispatchTouchEvent(ev)把事件分發(fā)給ViewGroup, 所以我們來看

Windows#superDispatchTouchEvent

public abstract boolean superDispatchTouchEvent(MotionEvent event)
  • 可以看出 Window 是個抽象類，且 Window 唯一實現(xiàn)的是 PhoneWindow，所以接下來我們看看 PhoneWindow 怎么處理該方法的

PhoneWindow#superDispatchTouchEvent

@Override
public boolean superDispatchTouchEvent(MotionEvent event) {
        return mDecor.superDispatchTouchEvent(event);
    }
  • 到這里清晰， 是在 PhoneWidow 將事件傳遞給了 DecorView, 至于什么是 DercorView ，看源碼里如何解釋的:
// This is the top-level view of the window, containing the window decor.
    private DecorView mDecor;

這個 mDecor 顯然就是getWindow().getDecorView() 所返回的 View，而我們通過 setContentView 設(shè)置的 View 就是是它的一個子 view。目前事件傳遞到了 DecorView 這里，由于 DecorView 繼承自 FrameLayout 且又是父 View，所以最終事件會傳遞給 我們所設(shè)置setContentView的頂級 View 一般來說都是 ViewGroup（不傳遞給他怎么響應(yīng)用戶點擊事件呢??）

ViewGroup 對點擊事件的分發(fā)

  • ViewGroup 對點擊事件的分發(fā)過程主要實現(xiàn)在 dispatchTouchEvent 這個方法里，這個方法過程，我們分段說明，首先看看 他對是否攔截的邏輯

代碼位置

// 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 在兩種情況下會判斷是否要攔截當(dāng)前事件：

    • 事件類型 為 ACTION_DOWN ，這個很好理解
    • 或者 mFirstTouchTarget != null ， 這個從后面代碼可以看出，當(dāng)事件由 ViewGroup 的子元素成功處理時，mFirstTouchTarget 就會被賦值并指向子元素

  • 且當(dāng)ACTION_MOVE 和 ACTION_UP 事件到來時，由于actionMasked == MotionEvent.ACTION_DOWN || mFirstTouchTarget != null這個條件為 false ，將導(dǎo)致 ViewGroup 的 onInterceptTouchEvent 不被調(diào)用，并且同一序列中的其他事件都會默認(rèn)交給他處理。

  • 但是這里有個特殊情況，那就是FLAG_DISALLOW_INTERCEPT標(biāo)記，這個標(biāo)記是子 View 通過requestDisallowInterceptTouchEvent方法來設(shè)置。一旦設(shè)置了該標(biāo)記，ViewGroup 將無法攔截除了 ACTION_DOWN 以外的事件。為什么說除了ACTION_DOWN 以外的事件，這點從源碼也可以看出：因為在 ViewGroup 在事件分發(fā)時，如果是ACTION_DOWN就會重置FLAG_DISALLOW_INTERCEPT標(biāo)記，將導(dǎo)致子View 設(shè)置的這個標(biāo)記失效。因此 當(dāng)事件為ACTION_DOWN時 ViewGroup 總是會調(diào)用自己的onInterceptTouchEvent來詢問是否攔截事件。
    我們看看上面代碼的前一句代碼就明白了:
    代碼位置

     // 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標(biāo)記進行重置，因此子 View調(diào)用requestDisallowInterceptTouchEvent方法并不能影響 ViewGroup 對ACTION_DOWN事件的處理

  • 從上面分析我們可以總結(jié)出兩點：

    • onInterceptTouchEvent 不是每次事件都會被調(diào)用，如果我們想在當(dāng)前的 ViewGroup 處理所有的點擊事件，就要選擇onInterceptTouchEvent方法中處理，只有這個方法能確保每次都被調(diào)用
    • FLAG_DISALLOW_INTERCEPT 給我們提供了另一種思路去解決滑動沖突的方法：在子 View 攔截處理

接下來我們看 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;
    }

    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);
    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;
    }

    // The accessibility focus didn't handle the event, so clear
    // the flag and do a normal dispatch to all children.
    ev.setTargetAccessibilityFocus(false);
}

  • 如上面源碼所示，首先操作的是遍歷 ViewGroup 的所有子元素，然后判斷是否能夠接收到點擊事件。是否能夠接收點擊事件主要有兩點判斷：

    • 子元素是否在播放動畫
    • 點擊事件的坐標(biāo)是否在子元素坐標(biāo)區(qū)域內(nèi)
      可以看到他調(diào)用了dispatchTransformedTouchEvent方法來傳遞事件，所以我們來看看該方法
      ViewGroup#dispatchTransformedTouchEvent 
     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);
          }
          event.setAction(oldAction);
          return handled;
      }
      
  ........
}
    • 可以看到在該方法里如果 傳遞的 child 不是 null 他會直接調(diào)用的是子元素的 dispatchTouchEvent 方法來把事件傳遞給子元素

  • 再回到 遍歷 ViewGroup 的所有子元素的方法中，可以看到在循環(huán)的最后過程中，判斷如果子元素的 dispatchTouchEvent 返回 true ，那么這個 ViewGroup 就暫時不考慮事件在子元素內(nèi)部是怎么分發(fā)的，而且 mFirstTouchTarget 就會被賦值同時跳出 for 循環(huán)，如下所示：
    代碼位置

    newTouchTarget = addTouchTarget(child, idBitsToAssign);
alreadyDispatchedToNewTouchTarget = true;
break;
    • 在這里完成了mFirstTouchTarget的賦值并且終止了對子元素的遍歷。其實對mFirstTouchTarget的賦值是在addTouchTarget方法里完成的:
      ViewGroup#addTouchTarget 
       private TouchTarget addTouchTarget(@NonNull View child, int pointerIdBits) {
     final TouchTarget target = TouchTarget.obtain(child, pointerIdBits);
     target.next = mFirstTouchTarget;
     mFirstTouchTarget = target;
     return target;
 }
    • mFirstTouchTarget 其實是一種單鏈表結(jié)構(gòu)，他是否被賦值將直接影響到 ViewGroup 對事件的攔截策略，若果mFirstTouchTarget 為 null ，那么 ViewGroup 就默認(rèn)攔截接下來同一序列中所有的點擊事件

  • 如果遍歷所有的子元素后事件都沒有被合適處理，這里包含兩種情況：

    • ViewGroup 沒有子元素
    • 子元素處理了點擊事件，但是在 dispatchTouchEvent 中返回了 false （這一般是因為子元素在 onTouch中返回了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);
 }

View對點擊事件的分發(fā)過程

  • View 對點擊事件的處理稍微簡單點，首先看他的 dispatchTouchEvent 方法
    View#dispatchTouchEvent

    public boolean dispatchTouchEvent(MotionEvent event) {
  ......
  if (onFilterTouchEventForSecurity(event)) {
      if ((mViewFlags & ENABLED_MASK) == ENABLED && handleScrollBarDragging(event)) {
      result = true;
      }
       //noinspection SimplifiableIfStatement
       ListenerInfo li = mListenerInfo;
      if (li != null && li.mOnTouchListener != null
      && (mViewFlags & ENABLED_MASK) == ENABLED
      && li.mOnTouchListener.onTouch(this, event)) {
      result = true;
      }

      if (!result && onTouchEvent(event)) {
      result = true;
  }
}
    • 由于 View 不包含子元素，所以他無法傳遞事件只能自己處理。從上面的源碼可以看出，View 對事件的處理首先會判斷有沒有設(shè)置 OnTouchListener如果設(shè)置了且 OnTouchListener中的 onTouch放回 true，那么 View 的 onTouchEvent 就不會被調(diào)用。由此可見 OnTouchListener 的優(yōu)先級高于 onTouchEvent

  • 接著我們再看onTouchEvent的實現(xiàn)。先看當(dāng) View 處于不可用狀態(tài)下的點擊事件處理過程：
    View#onTouchEvent

    if ((viewFlags & ENABLED_MASK) == DISABLED) {
   if (event.getAction() == 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));
}
    • 很明顯：不可用狀態(tài)下的 View 照樣會消耗點擊事件，盡管它看起來不可用

  • 接著onTouchEvent，如果 View 設(shè)置有代理，那么還會執(zhí)行 TouchDelegate 的onTouchEvent方法

    if (mTouchDelegate != null) {
  if (mTouchDelegate.onTouchEvent(event)) {
      return true;
  }
}

  • 再看onTouchEvent中對點擊事件的具體處理：

     if (((viewFlags & CLICKABLE) == CLICKABLE ||
       (viewFlags & LONG_CLICKABLE) == LONG_CLICKABLE)) {
   switch (event.getAction()) {
       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) {
                    // 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)) {
                           performClick();
                       }
                   }
               }
               .....
           }
           break;
   }
   ....
   return true;
}
    • 可以看出只要 View 的 CLICKABLE 和 LONG_CLICKABLE 有一個為 true，那么他就會消耗這個事件，即 onTouchEvent 返回 true，不管他是不是 DISABLE 狀態(tài)。然后在ACTION_UP發(fā)生時會觸發(fā) 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 設(shè)置了 OnClickListener，那么performClick() 方法內(nèi)部會調(diào)用它的onClick方法

End. 到此就結(jié)束了

最后編輯于 ：
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成，瀏覽時請結(jié)合常識與多方信息審慎甄別。
平臺聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點，簡書系信息發(fā)布平臺，僅提供信息存儲服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容