在開發中,我們經常要完成一些稍複雜的功能和交互。而這些交互往往不是觸發型的,僅僅用各種動畫是無法完成的,這時候就需要掌握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來取消按壓狀態,保證用戶看到。
長按事件和單擊事件只能有一個觸發,如果沒有執行長按事件,就移除長按的回調