最近有不少同學(xué)問我onTouch(View view, MotionEvent event)和onTouchEvent(MotionEvent event)的區(qū)別。看過網(wǎng)上的很多文章，不少文章對(duì)此僅是泛泛而談，浮于表面，無法讓讀者深入地理解其本質(zhì)。其實(shí)，這個(gè)問題便牽涉到了Android中的一個(gè)重要機(jī)制－事件分發(fā)機(jī)制，Android的事件分發(fā)機(jī)制包括兩部分，一部分是View的事件分發(fā)機(jī)制，另一部分是ViewGroup的事件分發(fā)機(jī)制，剛剛所說的onTouch和onTouchEvent的區(qū)別就涉及到View的事件分發(fā)機(jī)制。今天，我將帶領(lǐng)大家從源代碼的級(jí)別深入地剖析View的事件分發(fā)機(jī)制，盡可能地讓大家對(duì)View的事件分發(fā)機(jī)制有一個(gè)透徹的理解，不僅知其然，更知其所以然，好了，話不多說，就讓我們開始今天美妙的探索之旅吧_
假設(shè)我們當(dāng)前有一個(gè)MainActivity，在MainActivity中有一個(gè)按鈕btn，首先，我們給按鈕設(shè)置一個(gè)Click事件，代碼如下：
btn.setOnClickListener(new OnClickListener(){
@Override
public void onClick(View view) {
Log.v("TAG","onClick execute!");
}
});
其次，再給按鈕設(shè)置一個(gè)Touch事件，代碼如下：
btn.setOnTouchListener(new OnTouchListener(){
@Override
public boolean onTouch(View view, MotionEvent event) {
// TODO Auto-generated method stub
Log.v("TAG","onTouch execute,"+"action is "+event.getAction());
return false;
}
});
運(yùn)行程序，點(diǎn)擊按鈕，我們觀察到如下輸出：
可以看到，onTouch是優(yōu)先于onClick被執(zhí)行的并且onTouch被執(zhí)行了兩次，一次是ACTION_DOWN，一次是ACTION_UP（如果手抖了一下，可能還有多次ACTION_MOVE的執(zhí)行），所以事件傳遞的順序是先經(jīng)過onTouch,再經(jīng)過onClick。
我們注意到onTouch中是有返回值的，將這個(gè)返回值改為true后，輸出如下：
比較兩次的輸出結(jié)果，我們發(fā)現(xiàn)，這回，Click事件竟然沒有執(zhí)行！我們暫時(shí)可以認(rèn)為在onTouch中返回了true，onTouch就會(huì)將這個(gè)事件消費(fèi)掉，事件便不會(huì)繼續(xù)向下傳遞。
但是，上面的認(rèn)知僅僅是一個(gè)淺層次的認(rèn)知，onTouch中返回了true時(shí)底層到底發(fā)生了什么？為什么在onTouch中返回了true，事件便不會(huì)繼續(xù)向下傳遞了？onTouch和onTouchEvent的區(qū)別到底在哪里？看來，為了解決我們心中的疑惑，我們必須去深入分析相關(guān)的源代碼了。
其實(shí)，在Android中，只要我們觸摸到了任意一個(gè)控件，都會(huì)去調(diào)用這個(gè)控件的dispatchTouchEvent(MotionEvent event)方法,當(dāng)我們?nèi)c(diǎn)擊某個(gè)Button時(shí)，也會(huì)去調(diào)用相應(yīng)Button的dispatchTouchEvent方法，我們發(fā)現(xiàn)Button中是沒有這個(gè)方法的，那么去它的父類TextView中找一找，我們發(fā)現(xiàn)TextView中也沒有這個(gè)方法，那么再去TextView的父類View中找一找，終于，我們?cè)赩iew中發(fā)現(xiàn)了dispatchTouchEvent方法，dispatchTouchEvent方法的代碼如下：
public boolean dispatchTouchEvent(MotionEvent event) {
if (mOnTouchListener != null && (mViewFlags & ENABLED_MASK) == ENABLED &&
mOnTouchListener.onTouch(this, event)) {
return true;
}
return onTouchEvent(event);
}
可以看到，在dispatchTouchEvent方法中，會(huì)先進(jìn)入一個(gè)判斷，第一個(gè)條件是mOnTouchListener != null，那么我們的mOnTouchListener是在什么地方被賦值的呢？在View中我們發(fā)現(xiàn)了如下方法：
public void setOnTouchListener(OnTouchListener l) {
mOnTouchListener = l;
}
也就是說，只要給我們的控件設(shè)置了Touch事件，mOnTouchListener就自然被賦值了。
我們繼續(xù)去看第二個(gè)判斷條件(mViewFlags & ENABLED_MASK) == ENABLED ，這個(gè)條件是用來判斷控件是否是enabled,我們的Button默認(rèn)是enabled，所以這個(gè)條件為true。
在前兩個(gè)判斷條件為true的情況下，我們能否進(jìn)入這個(gè)if語句，就取決于我們第三個(gè)判斷條件了，第三個(gè)判斷條件為 mOnTouchListener.onTouch(this, event),其實(shí)就是去回調(diào)我們給控件設(shè)置Touch事件時(shí)的onTouch方法。如果在onTouch方法中返回了true,就會(huì)導(dǎo)致我們的三個(gè)判斷條件都為true，之后便會(huì)執(zhí)行if語句中的**return true **,我們整個(gè)的dispatchTouchEvent方法也直接返回true了。如果在onTouch方法中返回了false,便不會(huì)進(jìn)入到if語句中，此時(shí)會(huì)繼續(xù)向下執(zhí)行onTouchEvent方法，并將onTouchEvent方法的返回值作為整個(gè)dispatchTouchEvent方法的返回值。
這里還要注意一點(diǎn)，如果我們沒有給控件設(shè)置Touch事件或者控件本身不是enabled，那么后面便不會(huì)再去判斷onTouch方法的返回值了，接著便會(huì)直接去執(zhí)行onTouchEvent方法并且將其返回值作為整個(gè)dispatchTouchEvent方法的返回值。
結(jié)合上面我們給Button設(shè)置Click事件和Touch事件的代碼分析，當(dāng)我們?cè)趏nTouch方法中返回了false時(shí)，執(zhí)行完onTouch方法后還會(huì)去執(zhí)行onTouchEvent方法，而當(dāng)我們?cè)趏nTouch方法中返回了true時(shí),執(zhí)行完onTouch方法后整個(gè)dispatchTouchEvent方法便會(huì)直接返回true。由此便能很好地解釋我們之前的輸出結(jié)果了。同時(shí)，我們可以推斷出，onClick方法的執(zhí)行一定是在onTouchEvent中的！我們繼續(xù)去看onTouchEvent的源碼：
public boolean onTouchEvent(MotionEvent event) {
final int viewFlags = mViewFlags;
if ((viewFlags & ENABLED_MASK) == DISABLED) {
// 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));
}
if (mTouchDelegate != null) {
if (mTouchDelegate.onTouchEvent(event)) {
return true;
}
}
if (((viewFlags & CLICKABLE) == CLICKABLE ||
(viewFlags & LONG_CLICKABLE) == LONG_CLICKABLE)) {
switch (event.getAction()) {
case MotionEvent.ACTION_UP:
boolean prepressed = (mPrivateFlags & PREPRESSED) != 0;
if ((mPrivateFlags & 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 (!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();
}
}
}
if (mUnsetPressedState == null) {
mUnsetPressedState = new UnsetPressedState();
}
if (prepressed) {
mPrivateFlags |= PRESSED;
refreshDrawableState();
postDelayed(mUnsetPressedState,
ViewConfiguration.getPressedStateDuration());
} else if (!post(mUnsetPressedState)) {
// If the post failed, unpress right now
mUnsetPressedState.run();
}
removeTapCallback();
}
break;
case MotionEvent.ACTION_DOWN:
if (mPendingCheckForTap == null) {
mPendingCheckForTap = new CheckForTap();
}
mPrivateFlags |= PREPRESSED;
mHasPerformedLongPress = false;
postDelayed(mPendingCheckForTap, ViewConfiguration.getTapTimeout());
break;
case MotionEvent.ACTION_CANCEL:
mPrivateFlags &= ~PRESSED;
refreshDrawableState();
removeTapCallback();
break;
case MotionEvent.ACTION_MOVE:
final int x = (int) event.getX();
final int y = (int) event.getY();
// Be lenient about moving outside of buttons
int slop = mTouchSlop;
if ((x < 0 - slop) || (x >= getWidth() + slop) ||
(y < 0 - slop) || (y >= getHeight() + slop)) {
// Outside button
removeTapCallback();
if ((mPrivateFlags & PRESSED) != 0) {
// Remove any future long press/tap checks
removeLongPressCallback();
// Need to switch from pressed to not pressed
mPrivateFlags &= ~PRESSED;
refreshDrawableState();
}
}
break;
}
return true;
}
return false;
}
onTouchEvent的源碼較長，我們挑其中重要的看。首先看到 if (((viewFlags & CLICKABLE) == CLICKABLE || (viewFlags & LONG_CLICKABLE) == LONG_CLICKABLE))這一句，如果我們的控件是CLICKABLE的或LONG_CLICKABLE的，便會(huì)進(jìn)入到下面的switch分支選擇中，我們重點(diǎn)去看當(dāng)前action為MotionEvent.ACTION_UP的情況，在action為MotionEvent.ACTION_UP的情況中，經(jīng)過一系列的if判斷，最終會(huì)執(zhí)行到performClick()方法，performClick()方法的源代碼如下：
public boolean performClick() {
sendAccessibilityEvent(AccessibilityEvent.TYPE_VIEW_CLICKED);
if (mOnClickListener != null) {
playSoundEffect(SoundEffectConstants.CLICK);
mOnClickListener.onClick(this);
return true;
}
return false;
}
在performClick()方法中，首先會(huì)去判斷mOnClickListener是否為null,如果mOnClickListener不為null，便會(huì)去調(diào)用它的onClick方法。那么mOnClickListener是在何處被賦值的呢？推測一下，應(yīng)該是在setOnClickListener方法中被賦值的，我們趕緊去看一下setOnClickListener方法：
public void setOnClickListener(OnClickListener l) {
if (!isClickable()) {
setClickable(true);
}
mOnClickListener = l;
}
在setOnClickListener方法中，首先會(huì)去判斷當(dāng)前控件是否是Clickable的，如果不是Clickable的，則將當(dāng)前控件設(shè)置為Clickable的。之后將傳入的OnClickListener對(duì)象賦給 mOnClickListener。
我們回過頭來對(duì)之前的給Button設(shè)置Click事件和Touch事件的代碼進(jìn)行更加詳盡的分析。當(dāng)onTouch中返回false時(shí)，第一次傳入dispatchTouchEvent的MotionEvent是ACTION_DOWN,首先會(huì)去執(zhí)行onTouch方法，輸出“onTouch execute,action is 0”。之后再去執(zhí)行onTouchEvent,沒有任何輸出。第二次傳入dispatchTouchEvent的MotionEvent是ACTION_UP，首先會(huì)去執(zhí)行onTouch方法，輸出“onTouch execute,action is 1”。之后再去執(zhí)行onTouchEvent,輸出"onClick execute!"。當(dāng)onTouch中返回true時(shí),第一次傳入dispatchTouchEvent的MotionEvent是ACTION_DOWN,首先會(huì)去執(zhí)行onTouch方法，輸出“onTouch execute,action is 0”,之后dispatchTouchEvent方法直接返回true。第二次傳入dispatchTouchEvent的MotionEvent是ACTION_UP，首先會(huì)去執(zhí)行onTouch方法，輸出“onTouch execute,action is 1”。之后dispatchTouchEvent方法直接返回true。
到這里，我們已經(jīng)完全理解了給Button設(shè)置Click事件和Touch事件的代碼的輸出結(jié)果了。但是，我們的探索之旅還遠(yuǎn)遠(yuǎn)沒有結(jié)束。
下面給大家介紹的是View事件分發(fā)中一個(gè)很重要的知識(shí)點(diǎn)－Touch事件的層級(jí)傳遞。
當(dāng)我們給某個(gè)控件設(shè)置了Touch事件，當(dāng)點(diǎn)擊該控件時(shí)，會(huì)觸發(fā)一系列的事件，如ACTION_DOWN,ACTION_MOVE,ACTION_UP。dispatchTouchEvent在進(jìn)行事件分發(fā)時(shí)，如果某個(gè)ACTION返回了false,那么后面的ACTION都將得不到執(zhí)行。也就是說，只有前一個(gè)ACTION返回true，后一個(gè)的ACTION才會(huì)得到執(zhí)行。
觀察我們的onTouchEvent方法，通過細(xì)致的分析我們發(fā)現(xiàn)，當(dāng)控件為CLICKABLE或LONG_CLICKABLE時(shí)，onTouchEvent方法一定會(huì)返回true，從而導(dǎo)致dispatchTouchEvent返回true。當(dāng)控件不是CLICKABLE或LONG_CLICKABLE時(shí)，onTouchEvent方法會(huì)返回false，從而導(dǎo)致dispatchTouchEvent返回false。
我們舉一個(gè)例子來驗(yàn)證一下：
ImageView在默認(rèn)情況下不是CLICKABLE的。我們給ImageView對(duì)象設(shè)置Touch事件，代碼如下：
imageView.setOnTouchListener(new OnTouchListener(){
@Override
public boolean onTouch(View v, MotionEvent event) {
// TODO Auto-generated method stub
Log.v("TAG","onTouch execute,"+"action is "+event.getAction());
return false;
}
});
我們先在onTouch中返回false，使onTouchEvent能夠得到執(zhí)行。
這回我們采用先預(yù)測結(jié)果，再進(jìn)行實(shí)驗(yàn)的模式。當(dāng)onTouch中返回false時(shí)，第一次傳入dispatchTouchEvent的MotionEvent是ACTION_DOWN,首先會(huì)去執(zhí)行onTouch方法，輸出“onTouch execute,action is 0”。之后再去執(zhí)行onTouchEvent,因?yàn)镮mageView 默認(rèn)情況下不是CLICKABLE或LONG_CLICKABLE的，onTouchEvent會(huì)返回false，從而導(dǎo)致dispatchTouchEvent也會(huì)返回false,事件便不會(huì)傳遞到下一個(gè)ACTION中。由此，我們預(yù)測，在onTouch中返回false時(shí)，只會(huì)輸出一句“onTouch execute,action is 0”。
進(jìn)行實(shí)驗(yàn)，輸出結(jié)果如下：
下面我們?cè)趏nTouch中返回true，使onTouchEvent得不到執(zhí)行。
這回還是采用先預(yù)測結(jié)果，再進(jìn)行實(shí)驗(yàn)的模式。當(dāng)onTouch中返回true時(shí)，第一次傳入dispatchTouchEvent的MotionEvent是ACTION_DOWN,首先會(huì)去執(zhí)行onTouch方法，輸出“onTouch execute,action is 0”。之后dispatchTouchEvent直接返回true。第二次傳入dispatchTouchEvent的MotionEvent是ACTION_UP,首先會(huì)去執(zhí)行onTouch方法，輸出“onTouch execute,action is 1”。之后dispatchTouchEvent直接返回true。由此，我們預(yù)測，在onTouch中返回true時(shí)，首先會(huì)輸出“onTouch execute,action is 0”，之后會(huì)輸出“onTouch execute,action is 1”。
進(jìn)行實(shí)驗(yàn)，輸出結(jié)果如下：
接下來，我們給ImageView對(duì)象新增一個(gè)Click事件，代碼如下：
imageView.setOnClickListener(new OnClickListener(){
@Override
public void onClick(View arg0) {
// TODO Auto-generated method stub
Log.v("TAG","onClick execute!");
}
});
imageView.setOnTouchListener(new OnTouchListener(){
@Override
public boolean onTouch(View v, MotionEvent event) {
// TODO Auto-generated method stub
Log.v("TAG","onTouch execute,"+"action is "+event.getAction());
return false;
}
});
這次我們先看執(zhí)行結(jié)果：
看到這里，不少同學(xué)可能都心生疑惑，為什么給ImageView增加Click事件之后，結(jié)果就發(fā)生了驚天大逆轉(zhuǎn)，ImageView居然表現(xiàn)地和Button一樣了？！
其實(shí)，細(xì)細(xì)思量，這樣的結(jié)果也在意料之中?；仡櫸覀冎暗膕etOnClickListener方法，它先會(huì)去判斷當(dāng)前控件是否是Clickable的，如果不是Clickable的，則將當(dāng)前控件設(shè)置為Clickable的。當(dāng)我們調(diào)用了ImageView對(duì)象的setOnClickListener方法后，ImageView對(duì)象就已經(jīng)變成了Clickable的，所以其表現(xiàn)和Button一致也是自然的。
View的事件分發(fā)機(jī)制到這里已經(jīng)接近尾聲了，最后，我們對(duì)開篇的問題－onTouch和onTouchEvent的區(qū)別作出一個(gè)較完善的回答：onTouch和onTouchEvent都是在dispatchTouchEvent方法中被調(diào)用的方法，onTouch會(huì)優(yōu)先于onTouchEvent被執(zhí)行，如果onTouch通過返回true將事件消費(fèi)掉，事件便不會(huì)傳遞到onTouchEvent中。特別要強(qiáng)調(diào)的一點(diǎn)是，只有當(dāng)mOnTouchListener不為null并且控件是enabled,onTouch方法才會(huì)得到執(zhí)行，如果某個(gè)控件不是enabled，我們只能通過重寫其onTouchEvent方法來監(jiān)聽相應(yīng)的Touch事件。
