對事件分發的探討

        在開發中,我們經常要完成一些稍複雜的功能和交互。而這些交互往往不是觸發型的,僅僅用各種動畫是無法完成的,這時候就需要掌握View的一個核心知識:事件分發機制。這個比較重要也比較難,但實際上我們基本上每天都在直接或間接的跟它打交道。

       
1.點擊事件的傳遞
      事件的產生來源於我們的手指在屏幕上的動作。典型的事件類型:按下、移動鬆開,以及實時產生的座標值都被封裝到了一個類中:MotionEvent。
      當事件產生後,系統就會按照一定的規則傳遞給一個View,這就是事件的分發。其中有三個很重要的方法:dispatchTouchEvent、onInterceptTouchEvent、onTouchEvent。
      dispatchTouchEvent方法用於傳遞事件,定義在View類中,ViewGroup類重寫了該方法。onInterceptTouchEvent方法定義在ViewGroup類中,用於攔截事件。onTouchEvent方法定義在View類中,因爲事件的消費最終都會落在一個具體的View上。三者的關係借用《Android開發藝術探索》中的僞代碼表示:
    public boolean dispatchTouchEvent(MotionEvent ev) {
        boolean consume = false;
        if (onInterceptTouchEvent(ev)) {
            consume = onTouchEvent(ev);
        } else {
            consume = child.dispatchTouchEvent(ev);
        }
        return consume;
    }
      也就是說,一個ViewGroup調用自身的dispatchTouchEvent方法分發事件,如果自己要攔截,就交由自己的onTouchEvent方法處理事件,否則就讓子View調用他們的dispatchTouchEvent繼續分發,直到最終消費了事件。這種關係有點像遞歸。實際上,當事件傳遞到最終的子View上,還要看onTouchEvent的返回值,如果返回false則並不消費事件,繼續又返回給上一級View消費。這種關係按照Activity -> Window -> View的順序傳遞,可以用下圖描述:


2.事件傳遞的規則
    2.1 ViewGroup的dispatchTouchEvent方法,內部是倒序遍歷子元素。以FrameLayout爲例,事件會先傳遞到上層的子元素。這也是爲什麼一般點擊響應的是可見元素。
    2.2 一般而言,同一個事件序列中的事件不能由兩個View同時處理。但實際上,在ViewGroup中某個View在處理事件時仍然可以調用同級View的onTouchEvent方法,強制交由該View消費事件。
    2.3 重寫某個View的onTouchEvent方法,如果一直返回false.那麼雖然ACTION_MOVE和ACTION_UP不會消耗,但是從打印的日誌看,該View的ACTION_DOWN還是消耗了的,只是後續的動作不會被捕捉到。會交給父容器處理,以此類推。
    2.4 View只要是可點擊的,onTouchEvent默認都會返回true。Button的clickable屬性默認爲true,而TextView的默認爲false。但TextView監聽點擊事件時還是可以正常獲取,是因爲在set 只有setClickable(true)才具備點擊事件.此時的Down,Move,Up都消費了點擊事件,會走一次dispatchTouchEvent()
    2.5 ViewGroup的onInterceptTouchEvent方法默認返回false,即不攔截事件。View沒有該方法
    2.6 ViewGroup實現了ViewParent接口,其中有個方法requestDisallowInterceptTouchEvent。通過該方法可以實現在子元素中干預父元素除ACTION_DOWN之外的事件分發

3.Activity的事件分發
    一般來說,Activity類中也有自己的dispatchTouchEvent進行事件派發,具體由內部的Window(唯一實現類PhoneWindow)來完成的。默認也是返回false(沒有子類消費事件)。實際上是調用了DecorView的superDispatchTouchEvent方法,在這裏事件就已經傳遞給了頂級View,也叫根View,就是最常見的在Activity中通過setContentView所設置的View.
   
4.頂級View的事件分發
    一般就理解爲ViewGroup,因爲我們以xml形式定義的佈局都是繼承自ViewGroup。對事件的分發主要體現在dispatchTouchEvent方法中。ViewGroup中的這個方法有點讓人暈,也是配合着《Android開發藝術探索》梳理了大概。
// 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;
            }
    這段代碼描述了是否攔截當前事件。mFirstTouchTouchTarget在ViewGroup的子元素成功處理事件時會被賦值並指向子元素,也就是說一旦ViewGroup攔截當前事件那麼mFirstTouchTarget就爲null。這樣當ACTION_MOVE和ACTION_UP事件到來時,不滿足判斷條件中的任何一個,也就不會再調用onInterceptTouchEvent方法。就是說一旦開始攔截了事件,後續的攔截方法就不會再調用。
    但是其中有一個特殊的成員變量FLAG_DISALLOW_INTERCEPT,當被重置時,ViewGroup不再攔截該事件(除了ACTION_DOWN),相當於一個標記位。我們通過requestDisallowInterceptTouchEvent方法設置。實際上,在ACTION_DOWN進來時總會調用resetTouchState重置狀態,使得mGroupFlags&FLAG_DISALLOW_INTERCEPT爲0,從而調用onInterceptTouchEvent方法。
    經歷了一系列的判斷,如果事件既沒有被取消也沒有被攔截,事件會向下分發。
 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);
                        }
   倒序遍歷所有子元素,這也驗證了前面的說法。先判斷如果子元素接受不到事件或者事件座標超出區域,則跳過本次循環。如果滿足,則調用dispatchTransformedTouchEvent方法。跟蹤這個方法發現多次調用,也就是決定其返回值的是以下代碼:
if (child == null) {
            handled = super.dispatchTouchEvent(transformedEvent);
        } else {
            handled = child.dispatchTouchEvent(transformedEvent);
        }
    可以看到最終調用的都是View的dispatchTouchEvent方法,如果返回true那麼就跳出for循環,結束本次事件分發,並且會調用addTouchTarget方法爲mFirstTouchTarget賦值。如果ViewGroup沒有子元素,或者子元素處理事件時返回false,那麼mFirstTouchTarget爲null:
// 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);
            }
    因爲第三個參數(child)爲null,會調用super.dispatchTouchEvent,也就是說,最終將事件交給了View處理。


5.View的事件處理過程
    到這裏處理事件就比之前簡單一些。因爲這裏的View是單一元素,沒有子元素再往下傳遞事件。先看一下View的dispatchTouchEvent的部分方法:
public boolean dispatchTouchEvent(MotionEvent event) {
        boolean result = false;
        ...

        final int actionMasked = event.getActionMasked();
        if (actionMasked == MotionEvent.ACTION_DOWN) {
            // Defensive cleanup for new gesture
            stopNestedScroll();
        }

        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;
            }
        }
       ...
        // Clean up after nested scrolls if this is the end of a gesture;
        // also cancel it if we tried an ACTION_DOWN but we didn't want the rest
        // of the gesture.
        if (actionMasked == MotionEvent.ACTION_UP ||
                actionMasked == MotionEvent.ACTION_CANCEL ||
                (actionMasked == MotionEvent.ACTION_DOWN && !result)) {
            stopNestedScroll();
        }

        return result;
    }
    這裏可以看到View在分發事件時,事件類型爲ACTION_DOWN或者在本次事件結束時,則停止嵌套滾動(如果有的話)。比較關鍵的一點是會先判斷有沒有設置OnTouchListener,如果其中的onTouch回調方法返回true(一般是外部調用),那麼result=true,邏輯判斷onTouchEvent不會調用。也就是說,OnTouchListener的優先級高於onTouchEvent。現在看onTouchEvent方法:
final float x = event.getX();
        final float y = event.getY();
        final int viewFlags = mViewFlags;
        final int action = event.getAction();

        final boolean clickable = ((viewFlags & CLICKABLE) == CLICKABLE
                || (viewFlags & LONG_CLICKABLE) == LONG_CLICKABLE)
                || (viewFlags & CONTEXT_CLICKABLE) == CONTEXT_CLICKABLE;

        if ((viewFlags & ENABLED_MASK) == DISABLED) {
            if (action == MotionEvent.ACTION_UP && (mPrivateFlags & PFLAG_PRESSED) != 0) {
                setPressed(false);
            }
            mPrivateFlags3 &= ~PFLAG3_FINGER_DOWN;
            // A disabled view that is clickable still consumes the touch
            // events, it just doesn't respond to them.
            return clickable;
        }
    每次回調該方法時,都會先獲取事件的相對座標、View的狀態、事件類型、View是否可點擊。並且,即使View的enable屬性爲false,仍然不影響點擊事件的消耗,而且clickable和longClickable只要有一個屬性爲true則onTouchEvent返回true,但是會將View的內部pressed狀態置爲false。比如一個Button正常按下時顏色變深,此處會沒有效果。再看看對點擊事件的具體處理:
 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)) {
                                    performClick();
                                }
                            }
                        }
    這一段代碼是在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);

        notifyEnterOrExitForAutoFillIfNeeded(true);

        return result;
    }
    可以看出,如果View設置了OnClickListener,那麼最終會調用其onClick方法,也就是平時我最熟悉的點擊事件。因此如果我們在頁面初始化的時候需要不經動作觸發,而執行一次點擊事件,通常都會調用performClick方法,實現一次我們在onClick回調裏面定義的行爲。

6,有關View的onTouchEvent方法的事件類型
   1,Down:向上一直找父View,判斷自身是否在一個可以滾動的容器內(例如ScrollView, ListView).
     如果是,添加臨時的按壓狀態,延遲按壓事件(Down)在很短的時間後執行,防止這個動作其實是一個滑動.再過500ms減去這一段很短的時間(API23中是100ms)後,回調長按的動作。
     如果不是,直接設置按壓狀態,並且啓動長按計時
   2.Move : mTouchSlop  最小滑動距離 不同手機值不一樣,dpi越高越大.一般爲8
      取消按壓狀態         取消長按狀態
   3,Up:先判斷當前是否包含臨時按壓狀態:Down後沒有Move或者滑動沒有超過mTouchSlop
     如果是,setPressed(true) ,因爲臨時按壓不會繪製,強行繪製一次,保證用戶能看到自己點擊的效果.並且延遲64ms來取消按壓狀態,保證用戶看到。
     長按事件和單擊事件只能有一個觸發,如果沒有執行長按事件,就移除長按的回調


發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章