這是一個(gè)系列文章，如果沒有責(zé)任鏈設(shè)計(jì)模式的基礎(chǔ)知識(shí)，請(qǐng)移步Android事件分發(fā)流程（一）責(zé)任鏈設(shè)計(jì)模式
接著上文說，員工提交一次請(qǐng)假申請(qǐng)的處理流程，隨著請(qǐng)假天數(shù)的增多請(qǐng)假流程涉及的到相關(guān)角色就會(huì)越來(lái)越多，請(qǐng)假申請(qǐng)的處理流程也就變得復(fù)雜了許多；而責(zé)任鏈設(shè)計(jì)模式，將每個(gè)角色的職責(zé)進(jìn)行抽象，使得各個(gè)角色職責(zé)分明；因此，編碼層面上講，處理流程是清晰明確的。這就是責(zé)任鏈設(shè)計(jì)模式解決此類問題的優(yōu)勢(shì)所在。因此使用責(zé)任鏈設(shè)計(jì)模式實(shí)現(xiàn)Android系統(tǒng)事件分發(fā)機(jī)制是再合適不過的。
事件分發(fā)機(jī)制概述
View的事件分發(fā)機(jī)制是責(zé)任鏈的復(fù)雜場(chǎng)景，原因是上面介紹的請(qǐng)假申請(qǐng)?zhí)幚砹鞒淌菃我徽?qǐng)求事件的分發(fā)處理，而Android的事件分發(fā)機(jī)制則是分發(fā)處理一次從按下到抬起的同一事件序列。
同一事件序列：是指從手指接觸屏幕的那一刻起，到手指離開屏幕的那一刻結(jié)束，在這個(gè)過程中所產(chǎn)生的一系列的事件。這個(gè)事件序列以ACTION_DOWN事件開始，中間含有數(shù)量不定的ACTION_MOVE事件，最后以ACTION_UP事件結(jié)束。
一般來(lái)講，同一事件序列只能被一個(gè)View對(duì)象攔截并消耗。因?yàn)橐粋€(gè)視圖對(duì)象一旦攔截了某次事件，那么同一事件序列的所有事件都會(huì)交給它來(lái)處理，因此同一事件序列不能分別由兩個(gè)View同時(shí)處理。但是，特殊的手段可以做到這一點(diǎn)，比如一個(gè)視圖對(duì)象將本該自己處理的事件通過onTouchEvent方法強(qiáng)行傳遞給其他View對(duì)象處理。
View對(duì)象一旦決定攔截事件，那么同一事件序列的其他事件都只能由它來(lái)處理（如果事件序列能傳遞給它的話），它的onInterceptTouchEvent不會(huì)再次被調(diào)用。原因是因?yàn)楦溉萜鲿?huì)記錄處理該事件序列的視圖對(duì)象，從而優(yōu)化事件分發(fā)流程。這一點(diǎn)稍后能在源碼中看到。
如果視圖對(duì)象一旦開始處理事件，但是不消耗ACTION_DOWN事件（onTouchEvent方法返回false），那么同一事件序列中的其它事件都不會(huì)交給他處理，而是將事件重新交給他的父元素處理（即調(diào)用onTouchEvent事件）。但是如果該視圖對(duì)象只消耗了ACTION_DOWN事件，而不消耗其他事件的話，當(dāng)前View可以持續(xù)受到后續(xù)的事件，最終這些消失的事件會(huì)被Activity處理。
ViewGroup默認(rèn)不攔截任何事件。View沒有onInterceptTouchEvent方法，一旦有點(diǎn)擊事件傳遞給它，那么它的onTouchEvent方法就會(huì)被調(diào)用。View的onTouchEvent方法是默認(rèn)會(huì)消耗事件（返回true），除非它是不可點(diǎn)擊的（即clickable和longClickable同時(shí)為false），View的longClickable屬性默認(rèn)都為false；clickable屬性不同的子類有不同的實(shí)現(xiàn)，如Button的clickable默認(rèn)為true，而TextView的clickable屬性默認(rèn)為false。
View的enable屬性不影響onTouchEvent的默認(rèn)返回值，哪怕一個(gè)View 是disable狀態(tài)，只要它的clickable、longClickable有一個(gè)為true，onTouchEvent就返回true。
點(diǎn)擊事件onClick方法會(huì)被調(diào)用的前提是當(dāng)前View可點(diǎn)擊，并且收到了ACTION_DOWN和ACTION_UP事件。
事件傳遞過程是由外向內(nèi)的，也就是說事件先傳遞給父容器，然后再由父元素分發(fā)給子View；子View可以通過requestDisallowInterceptTouchEvent方法可以在子元素中干預(yù)父容器的事件分發(fā)過程，但是ACTION_DOWN事件除外。
View的事件分發(fā)機(jī)制在安卓開發(fā)中一大難點(diǎn)同時(shí)也是核心知識(shí)點(diǎn)。了解了事件分發(fā)機(jī)制的處理機(jī)制是解決滑動(dòng)沖突和實(shí)現(xiàn)高級(jí)View定制的前置知識(shí)。
以下結(jié)合源碼分析android對(duì)事件分發(fā)機(jī)制的設(shè)計(jì)細(xì)節(jié)。
事件序列傳遞過程
事件傳遞過程傳遞順序如下；
Activity->Window->View
事件總是先傳遞給Activity，Activity再傳遞給Window，然后Window在傳遞給頂級(jí)View處理。頂級(jí)View接收到時(shí)間后就會(huì)安卓事件分發(fā)機(jī)制去分發(fā)事件（著重關(guān)注這部分）。
- Activity對(duì)點(diǎn)擊事件的分發(fā)過程
public boolean dispatchTouchEvent(MotionEvent ev) {
if (ev.getAction() == MotionEvent.ACTION_DOWN) {
onUserInteraction();
}
//如果Window消耗該事件，Activity的onTouchEvent就不會(huì)被調(diào)用
if (getWindow().superDispatchTouchEvent(ev)) {
return true;
}
//如果Window元素沒有處理該事件，Activity去處理
return onTouchEvent(ev);
}
- PhoneWindow對(duì)象的superDispatchTouchEvent方法會(huì)調(diào)用mDector對(duì)象進(jìn)行處理。
我們都知道可以通過((ViewGroup)getWindow().getDecorView().findViewById(android.R.id.content)).getChildAt(0)可以獲取Activity所設(shè)置的contentView視圖，因此可以相信，Window對(duì)象直接交給頂級(jí)View去處理。
@Override
public boolean superDispatchTouchEvent(MotionEvent event) {
return mDecor.superDispatchTouchEvent(event);
}
- 頂級(jí)View對(duì)點(diǎn)擊事件的分發(fā)過程。
事件分發(fā)給頂級(jí)View（一般是ViewGroup）以后會(huì)調(diào)用ViewGroup的dispatchTouchEvent方法。事件分發(fā)機(jī)制的奧秘就在這個(gè)方法中。后續(xù)的介紹都是這部分內(nèi)容。
事件分發(fā)流程中的三個(gè)核心方法
-
dispatchTouchEvent(MotionEvent event)
用來(lái)進(jìn)行事件分發(fā)。如果事件能夠傳遞給當(dāng)前的View，那么該方法一定會(huì)被調(diào)用，該方法的返回值取決于當(dāng)前View的onTouchEvent和下級(jí)View的dispatchTouchEvent方法的影響，表示是否消耗當(dāng)前事件。 -
onInterceptTouchEvent(MotionEvent event)
在上述方法內(nèi)部調(diào)用，用于判斷是否攔截這個(gè)事件，如果當(dāng)前View攔截某個(gè)事件，那么在同一個(gè)事件序列中，不會(huì)再次調(diào)用該方法，返回值表示是否攔截當(dāng)前事件。 -
onTouchEvent(MotionEvent event)
處理當(dāng)前事件的方法，返回值表示是否消耗當(dāng)前事件，如果不消耗，在同一事件序列中，當(dāng)前View無(wú)法再次接受到事件。
下面的偽代碼，可以將三者的關(guān)系表達(dá)清楚；
public boolean dispatchTouchEvent(MotionEvent ev) {
boolean consume=false;
if(onInterceptTouchEvent(ev)){//判斷是否攔截該事件
consume=onTouchEvent(ev);//攔截該事件的話，調(diào)用自己處理事件的方法
} else {
consume=child.dispatchTouchEvent(ev);//不攔截事件，交給子View進(jìn)行事件分發(fā)處理
}
return consume;//返回是否消耗該事件
}
頂級(jí)View的分發(fā)過程
dispatchTouchEvent源碼分析
ViewGroup中的dispatchTouchEvent方法是了解事件分發(fā)過程的非常重要的方法，它是View事件分發(fā)流程的入口方法。研究一個(gè)方法我們關(guān)注的有如下幾點(diǎn)，方法的入?yún)?/strong>，返回值和實(shí)現(xiàn)邏輯。
- 入?yún)?/li>
方法的入?yún)⑹且粋€(gè)MotionEvent對(duì)象，即點(diǎn)擊事件。該對(duì)象常用的有三種狀態(tài)分別是ACTION_DOWN、ACTION_MOVE、ACTION_UP。以這三種狀態(tài)為切入點(diǎn)進(jìn)行解讀，能夠更清晰的理解實(shí)現(xiàn)邏輯。
- 返回值
布爾類型的返回值，表示是否消耗這個(gè)事件。
- 實(shí)現(xiàn)邏輯
參數(shù)表示方法的輸入，返回值表示方法的輸出，而最重要的實(shí)現(xiàn)細(xì)節(jié)，是讀懂源碼的關(guān)鍵。下面由點(diǎn)帶面的進(jìn)行解讀。
當(dāng)方法收到一個(gè)點(diǎn)擊事件，會(huì)做那些工作？
- 點(diǎn)擊事件標(biāo)記為ACTION_DOWN時(shí)執(zhí)行按下事件初始化操作。
主要做的工作，是重置FLAG_DISALLOW_INTERCEPT標(biāo)志位、取消和清除處理觸摸事件的目標(biāo)對(duì)象；
// 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();
}
- 判斷是否攔截當(dāng)前事件
可以看出下面這段邏輯不只是會(huì)在ACTION_DOWN事件產(chǎn)生時(shí)才會(huì)進(jìn)入，當(dāng)mFirstTouchTarget != null時(shí)也會(huì)進(jìn)入。mFirstTouchTarget對(duì)象是何時(shí)被賦值的呢？答案是當(dāng)事件有ViewGroup的子元素成功處理時(shí)該對(duì)象會(huì)被賦值并指向子元素，這一點(diǎn)稍后會(huì)具體分析。由此得知，當(dāng)前點(diǎn)擊事件標(biāo)記不是ACTION_DOWN類型并且事件沒被子元素處理時(shí)才不會(huì)進(jìn)入攔截判斷的邏輯。
// 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不攔截事件的時(shí)候事件會(huì)下發(fā)交由它的子View處理
下面代碼的大致邏輯是，首先遍歷ViewGroup的所有子元素，然后判斷子元素是否能夠接收到點(diǎn)擊事件。能否接收點(diǎn)擊事件的判斷依據(jù)是：子元素可見（VISIBLE狀態(tài)或正在播動(dòng)畫導(dǎo)致的非VISIBLE狀態(tài)）和點(diǎn)擊事件的坐標(biāo)落在子元素的區(qū)域內(nèi)。如果某個(gè)子元素同時(shí)滿足這兩個(gè)條件，那么事件就會(huì)傳遞給它來(lái)處理。
//注：該方法片段位于ViewGroup的dispatchTouchEvent方法中
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;
}
//判斷child元素能否處理該事件用到的兩個(gè)方法；分割線下附有方法詳情介紹
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;
}
}
----------------------------------------分割線--------------------------------------
//判斷child元素能否處理該事件用到的兩個(gè)方法，兩則必須都滿足才能交給該child元素處理
/**
* Returns true if a child view can receive pointer events.
* 判斷視圖能否處理事件的第一個(gè)方法：可見或正在播動(dòng)畫導(dǎo)致的不可見。
* @hide
*/
private static boolean canViewReceivePointerEvents(@NonNull View child) {
return (child.mViewFlags & VISIBILITY_MASK) == VISIBLE
|| child.getAnimation() != null;
}
/**
* Returns true if a child view contains the specified point when transformed
* into its coordinate space.
* Child must not be null.
* 子判斷視圖能否處理事件的第一個(gè)方法：點(diǎn)擊事件的坐標(biāo)是否落在子元素的區(qū)域內(nèi)
* @hide
*/
protected boolean isTransformedTouchPointInView(float x, float y, View child,
PointF outLocalPoint) {
final float[] point = getTempPoint();
point[0] = x;
point[1] = y;
transformPointToViewLocal(point, child);
final boolean isInView = child.pointInView(point[0], point[1]);
if (isInView && outLocalPoint != null) {
outLocalPoint.set(point[0], point[1]);
}
return isInView;
}
dispatchTransformedTouchEvent方法實(shí)際上就是調(diào)用子元素的dispatchTouchEvent方法。其中有一段代碼值得細(xì)看。當(dāng)傳遞的child元素為空時(shí)，直接調(diào)用當(dāng)前對(duì)象的父類（也就是View類）的事件分發(fā)方法進(jìn)行處理。如下。
//注：改代碼片段位于ViewGroup的dispatchTransformedTouchEvent方法中，可能有所刪減
// Perform any necessary transformations and dispatch.
if (child == null) {
//這幾乎容易被忽略，ViewGroup的父類是View所以會(huì)調(diào)用View類的分發(fā)記住進(jìn)行分發(fā)。
//View類的分發(fā)機(jī)制會(huì)在后面進(jìn)行分析。
//聰明的你一定會(huì)發(fā)現(xiàn)，如果不加super的話會(huì)導(dǎo)致死循環(huán)(持續(xù)的遞歸)。
handled = super.dispatchTouchEvent(transformedEvent);
} else {
final float offsetX = mScrollX - child.mLeft;
final float offsetY = mScrollY - child.mTop;
transformedEvent.offsetLocation(offsetX, offsetY);
if (! child.hasIdentityMatrix()) {
transformedEvent.transform(child.getInverseMatrix());
}
handled = child.dispatchTouchEvent(transformedEvent);
}
// Done.
ViewGroup將事件交給child元素處理，如果該事件被child元素成功處理了，就會(huì)通過addTouchTarget完成mFirstTouchTarget的賦值。其實(shí)mFirstTouchTarget是單鏈表結(jié)構(gòu)的實(shí)例。經(jīng)過之前的分析我們知道，mFirstTouchTarget是否為null直接影響了ViewGroup對(duì)事件的攔截策略，這是前面已經(jīng)提到過的。addTouchTarget方法源碼如下。
/**
* Adds a touch target for specified child to the beginning of the list.
* Assumes the target child is not already present.
*/
private TouchTarget addTouchTarget(@NonNull View child, int pointerIdBits) {
final TouchTarget target = TouchTarget.obtain(child, pointerIdBits);
target.next = mFirstTouchTarget;
mFirstTouchTarget = target;
return target;
}
經(jīng)過對(duì)子元素的遍歷之后，如果mFirstTouchTarget依然為null，證明事件沒有被子元素合適地處理。有兩種情況導(dǎo)致這一結(jié)果：
- ViewGroup沒有子元素可以處理事件。
- 子元素處理了點(diǎn)擊事件，但是沒有消耗事件
這個(gè)時(shí)候，ViewGroup會(huì)自己處理點(diǎn)擊事件。這塊邏輯的代碼表示如下。
// 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類事件的處理過程
經(jīng)過對(duì)子元素的遍歷之后，事件沒有被子元素合適地處理，就像上面說到的ViewGroup會(huì)自己處理該事件。這時(shí)，ViewGroup會(huì)調(diào)用它的父類（基類）的dispatchTouchEvent方法進(jìn)行處理，也就是將要分析的這段內(nèi)容。
View類對(duì)點(diǎn)擊事件的處理過程對(duì)比ViewGroup的處理簡(jiǎn)單些，原因是View類型的元素是一個(gè)單獨(dú)的元素而非視圖容器，因此無(wú)需進(jìn)行向下傳遞只能自己處理。
//注：該方法位于View類中，方法體內(nèi)代碼有所刪減
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;
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;
}
View處理事件的優(yōu)先級(jí)
根據(jù)上面的代碼看出，如果View的mOnTouchListener != null 時(shí)會(huì)被優(yōu)先調(diào)用，如果事件被mOnTouchListener消耗，此時(shí)onTouchEvent方法會(huì)被屏蔽；如果mOnTouchListener未被設(shè)置或者已設(shè)置但是當(dāng)前事件沒有被消耗掉，這時(shí)才會(huì)調(diào)用onTouchEvent方法處理當(dāng)前事件。由此可見，onTouchListener的優(yōu)先級(jí)高于onTouchEvent。
onTouchEvent源碼進(jìn)行分段分析，如下。
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);
}
通過上面的代碼能很明顯的看出，處于DISABLED狀態(tài)的View依然可以消耗點(diǎn)擊事件。
接著往下看，如果View元素設(shè)置了TouchDelegrate類型的代理，這時(shí)會(huì)執(zhí)行代理類中的onTouchEvent方法，該類的工作機(jī)制和OnTouchListener類似，這里不深入分析。源碼如下。
if (mTouchDelegate != null) {
if (mTouchDelegate.onTouchEvent(event)) {
return true;
}
}
View類的onTouchEvent方法的具體處理邏輯代碼，如下所示。
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)) {
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:
mHasPerformedLongPress = false;
if (performButtonActionOnTouchDown(event)) {
break;
}
if (isInScrollingContainer) {
```省略部分代碼
} else {
// Not inside a scrolling container, so show the feedback right away
setPressed(true, x, y);
checkForLongClick(0, x, y);
}
break;
case MotionEvent.ACTION_CANCEL:
setPressed(false);
removeTapCallback();
removeLongPressCallback();
mInContextButtonPress = false;
mHasPerformedLongPress = false;
mIgnoreNextUpEvent = false;
break;
case MotionEvent.ACTION_MOVE:
drawableHotspotChanged(x, y);
// Be lenient about moving outside of buttons
if (!pointInView(x, y, mTouchSlop)) {
// Outside button
removeTapCallback();
if ((mPrivateFlags & PFLAG_PRESSED) != 0) {
// Remove any future long press/tap checks
removeLongPressCallback();
setPressed(false);
}
}
break;
}
return true;
}
上面的代碼是略長(zhǎng)的，主要的分析關(guān)注的點(diǎn)是點(diǎn)擊事件和長(zhǎng)按事件的處理過程，涉及到以上的四種類別的事件的處理，相信分析起來(lái)并不困難。
值得提出的一點(diǎn)是，在onTouchEvent方法中如果當(dāng)前設(shè)置了OnClickListener,那么在MotionEvent.ACTION_UP事件處理時(shí)它的onClick方法才會(huì)在performClick方法的內(nèi)部調(diào)用。因此OnClickListener，優(yōu)先級(jí)最低，處于事件傳遞的尾端。
ViewGroup 默認(rèn)的是否攔截事件的判斷
ViewGroup默認(rèn)攔截事件的的方法分析，當(dāng)點(diǎn)擊事件的點(diǎn)擊點(diǎn)，坐落在ScrollbarThumb上的時(shí)候進(jìn)行攔截，否則是默認(rèn)不攔截事件的。
public boolean onInterceptTouchEvent(MotionEvent ev) {
if (ev.isFromSource(InputDevice.SOURCE_MOUSE)
&& ev.getAction() == MotionEvent.ACTION_DOWN
&& ev.isButtonPressed(MotionEvent.BUTTON_PRIMARY)
&& isOnScrollbarThumb(ev.getX(), ev.getY())) {
return true;
}
return false;
}
到此，從Android源碼層面分析事件傳遞過程已經(jīng)分析完了。
后續(xù)文章會(huì)做滑動(dòng)沖突類型的實(shí)例分析。敬期。
