最近有不少同學問我onTouch(View view, MotionEvent event)和onTouchEvent(MotionEvent event)的區(qū)別。看過網(wǎng)上的很多文章恍风，不少文章對此僅是泛泛而談，浮于表面歇由，無法讓讀者深入地理解其本質(zhì)夺谁。其實，這個問題便牽涉到了Android中的一個重要機制－事件分發(fā)機制青抛，Android的事件分發(fā)機制包括兩部分，一部分是View的事件分發(fā)機制酬核，另一部分是ViewGroup的事件分發(fā)機制蜜另，剛剛所說的onTouch和onTouchEvent的區(qū)別就涉及到View的事件分發(fā)機制。今天嫡意，我將帶領大家從源代碼的級別深入地剖析View的事件分發(fā)機制举瑰，盡可能地讓大家對View的事件分發(fā)機制有一個透徹的理解，不僅知其然蔬螟，更知其所以然此迅，好了，話不多說旧巾，就讓我們開始今天美妙的探索之旅吧_
假設我們當前有一個MainActivity耸序，在MainActivity中有一個按鈕btn，首先鲁猩，我們給按鈕設置一個Click事件坎怪，代碼如下：
btn.setOnClickListener(new OnClickListener(){
@Override
public void onClick(View view) {
Log.v("TAG","onClick execute!");
}
});
其次，再給按鈕設置一個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;
}
});
運行程序搅窿，點擊按鈕，我們觀察到如下輸出：
可以看到隙券，onTouch是優(yōu)先于onClick被執(zhí)行的并且onTouch被執(zhí)行了兩次男应，一次是ACTION_DOWN，一次是ACTION_UP（如果手抖了一下娱仔，可能還有多次ACTION_MOVE的執(zhí)行）沐飘，所以事件傳遞的順序是先經(jīng)過onTouch,再經(jīng)過onClick。
我們注意到onTouch中是有返回值的拟枚，將這個返回值改為true后薪铜，輸出如下：
比較兩次的輸出結(jié)果，我們發(fā)現(xiàn)恩溅，這回隔箍，Click事件竟然沒有執(zhí)行！我們暫時可以認為在onTouch中返回了true脚乡，onTouch就會將這個事件消費掉蜒滩，事件便不會繼續(xù)向下傳遞滨达。
但是，上面的認知僅僅是一個淺層次的認知俯艰，onTouch中返回了true時底層到底發(fā)生了什么捡遍？為什么在onTouch中返回了true，事件便不會繼續(xù)向下傳遞了竹握？onTouch和onTouchEvent的區(qū)別到底在哪里画株？看來，為了解決我們心中的疑惑啦辐，我們必須去深入分析相關的源代碼了谓传。
其實，在Android中芹关，只要我們觸摸到了任意一個控件续挟，都會去調(diào)用這個控件的dispatchTouchEvent(MotionEvent event)方法,當我們?nèi)c擊某個Button時，也會去調(diào)用相應Button的dispatchTouchEvent方法侥衬，我們發(fā)現(xiàn)Button中是沒有這個方法的诗祸，那么去它的父類TextView中找一找，我們發(fā)現(xiàn)TextView中也沒有這個方法轴总，那么再去TextView的父類View中找一找直颅，終于，我們在View中發(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方法中，會先進入一個判斷漂佩，第一個條件是mOnTouchListener != null脖含，那么我們的mOnTouchListener是在什么地方被賦值的呢？在View中我們發(fā)現(xiàn)了如下方法：
public void setOnTouchListener(OnTouchListener l) {
mOnTouchListener = l;
}
也就是說投蝉，只要給我們的控件設置了Touch事件养葵，mOnTouchListener就自然被賦值了。
我們繼續(xù)去看第二個判斷條件(mViewFlags & ENABLED_MASK) == ENABLED 瘩缆，這個條件是用來判斷控件是否是enabled,我們的Button默認是enabled关拒，所以這個條件為true。
在前兩個判斷條件為true的情況下庸娱，我們能否進入這個if語句着绊，就取決于我們第三個判斷條件了，第三個判斷條件為 mOnTouchListener.onTouch(this, event),其實就是去回調(diào)我們給控件設置Touch事件時的onTouch方法熟尉。如果在onTouch方法中返回了true,就會導致我們的三個判斷條件都為true归露，之后便會執(zhí)行if語句中的**return true **,我們整個的dispatchTouchEvent方法也直接返回true了。如果在onTouch方法中返回了false,便不會進入到if語句中斤儿，此時會繼續(xù)向下執(zhí)行onTouchEvent方法剧包，并將onTouchEvent方法的返回值作為整個dispatchTouchEvent方法的返回值恐锦。
這里還要注意一點，如果我們沒有給控件設置Touch事件或者控件本身不是enabled疆液，那么后面便不會再去判斷onTouch方法的返回值了一铅，接著便會直接去執(zhí)行onTouchEvent方法并且將其返回值作為整個dispatchTouchEvent方法的返回值。
結(jié)合上面我們給Button設置Click事件和Touch事件的代碼分析堕油，當我們在onTouch方法中返回了false時潘飘，執(zhí)行完onTouch方法后還會去執(zhí)行onTouchEvent方法，而當我們在onTouch方法中返回了true時,執(zhí)行完onTouch方法后整個dispatchTouchEvent方法便會直接返回true掉缺。由此便能很好地解釋我們之前的輸出結(jié)果了福也。同時，我們可以推斷出攀圈，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的凯傲，便會進入到下面的switch分支選擇中犬辰，我們重點去看當前action為MotionEvent.ACTION_UP的情況，在action為MotionEvent.ACTION_UP的情況中冰单，經(jīng)過一系列的if判斷幌缝，最終會執(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()方法中诫欠，首先會去判斷mOnClickListener是否為null,如果mOnClickListener不為null涵卵，便會去調(diào)用它的onClick方法。那么mOnClickListener是在何處被賦值的呢荒叼？推測一下轿偎，應該是在setOnClickListener方法中被賦值的，我們趕緊去看一下setOnClickListener方法：
public void setOnClickListener(OnClickListener l) {
if (!isClickable()) {
setClickable(true);
}
mOnClickListener = l;
}
在setOnClickListener方法中被廓，首先會去判斷當前控件是否是Clickable的坏晦，如果不是Clickable的，則將當前控件設置為Clickable的嫁乘。之后將傳入的OnClickListener對象賦給 mOnClickListener昆婿。
我們回過頭來對之前的給Button設置Click事件和Touch事件的代碼進行更加詳盡的分析。當onTouch中返回false時蜓斧，第一次傳入dispatchTouchEvent的MotionEvent是ACTION_DOWN,首先會去執(zhí)行onTouch方法仓蛆，輸出“onTouch execute,action is 0”。之后再去執(zhí)行onTouchEvent,沒有任何輸出挎春。第二次傳入dispatchTouchEvent的MotionEvent是ACTION_UP多律，首先會去執(zhí)行onTouch方法痴突，輸出“onTouch execute,action is 1”。之后再去執(zhí)行onTouchEvent,輸出"onClick execute!"狼荞。當onTouch中返回true時,第一次傳入dispatchTouchEvent的MotionEvent是ACTION_DOWN,首先會去執(zhí)行onTouch方法辽装，輸出“onTouch execute,action is 0”,之后dispatchTouchEvent方法直接返回true。第二次傳入dispatchTouchEvent的MotionEvent是ACTION_UP相味，首先會去執(zhí)行onTouch方法拾积，輸出“onTouch execute,action is 1”。之后dispatchTouchEvent方法直接返回true丰涉。
到這里拓巧，我們已經(jīng)完全理解了給Button設置Click事件和Touch事件的代碼的輸出結(jié)果了。但是一死，我們的探索之旅還遠遠沒有結(jié)束肛度。
下面給大家介紹的是View事件分發(fā)中一個很重要的知識點－Touch事件的層級傳遞。
當我們給某個控件設置了Touch事件投慈，當點擊該控件時承耿，會觸發(fā)一系列的事件，如ACTION_DOWN,ACTION_MOVE,ACTION_UP伪煤。dispatchTouchEvent在進行事件分發(fā)時加袋，如果某個ACTION返回了false,那么后面的ACTION都將得不到執(zhí)行。也就是說抱既，只有前一個ACTION返回true职烧，后一個的ACTION才會得到執(zhí)行。
觀察我們的onTouchEvent方法防泵，通過細致的分析我們發(fā)現(xiàn)蚀之，當控件為CLICKABLE或LONG_CLICKABLE時，onTouchEvent方法一定會返回true捷泞，從而導致dispatchTouchEvent返回true恬总。當控件不是CLICKABLE或LONG_CLICKABLE時，onTouchEvent方法會返回false肚邢，從而導致dispatchTouchEvent返回false壹堰。
我們舉一個例子來驗證一下：
ImageView在默認情況下不是CLICKABLE的。我們給ImageView對象設置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í)行。
這回我們采用先預測結(jié)果响蕴，再進行實驗的模式谆焊。當onTouch中返回false時，第一次傳入dispatchTouchEvent的MotionEvent是ACTION_DOWN,首先會去執(zhí)行onTouch方法浦夷，輸出“onTouch execute,action is 0”辖试。之后再去執(zhí)行onTouchEvent,因為ImageView 默認情況下不是CLICKABLE或LONG_CLICKABLE的辜王，onTouchEvent會返回false，從而導致dispatchTouchEvent也會返回false,事件便不會傳遞到下一個ACTION中罐孝。由此呐馆，我們預測，在onTouch中返回false時莲兢，只會輸出一句“onTouch execute,action is 0”汹来。
進行實驗，輸出結(jié)果如下：
下面我們在onTouch中返回true改艇，使onTouchEvent得不到執(zhí)行收班。
這回還是采用先預測結(jié)果，再進行實驗的模式谒兄。當onTouch中返回true時摔桦，第一次傳入dispatchTouchEvent的MotionEvent是ACTION_DOWN,首先會去執(zhí)行onTouch方法，輸出“onTouch execute,action is 0”承疲。之后dispatchTouchEvent直接返回true邻耕。第二次傳入dispatchTouchEvent的MotionEvent是ACTION_UP,首先會去執(zhí)行onTouch方法，輸出“onTouch execute,action is 1”纪隙。之后dispatchTouchEvent直接返回true。由此扛或，我們預測绵咱，在onTouch中返回true時，首先會輸出“onTouch execute,action is 0”熙兔，之后會輸出“onTouch execute,action is 1”悲伶。
進行實驗，輸出結(jié)果如下：
接下來住涉，我們給ImageView對象新增一個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é)果：
看到這里，不少同學可能都心生疑惑舆声，為什么給ImageView增加Click事件之后花沉，結(jié)果就發(fā)生了驚天大逆轉(zhuǎn)，ImageView居然表現(xiàn)地和Button一樣了媳握？碱屁！
其實，細細思量蛾找，這樣的結(jié)果也在意料之中娩脾。回顧我們之前的setOnClickListener方法打毛，它先會去判斷當前控件是否是Clickable的柿赊，如果不是Clickable的俩功，則將當前控件設置為Clickable的。當我們調(diào)用了ImageView對象的setOnClickListener方法后碰声，ImageView對象就已經(jīng)變成了Clickable的诡蜓，所以其表現(xiàn)和Button一致也是自然的。
View的事件分發(fā)機制到這里已經(jīng)接近尾聲了奥邮，最后万牺，我們對開篇的問題－onTouch和onTouchEvent的區(qū)別作出一個較完善的回答：onTouch和onTouchEvent都是在dispatchTouchEvent方法中被調(diào)用的方法，onTouch會優(yōu)先于onTouchEvent被執(zhí)行洽腺，如果onTouch通過返回true將事件消費掉脚粟，事件便不會傳遞到onTouchEvent中。特別要強調(diào)的一點是蘸朋，只有當mOnTouchListener不為null并且控件是enabled,onTouch方法才會得到執(zhí)行核无，如果某個控件不是enabled，我們只能通過重寫其onTouchEvent方法來監(jiān)聽相應的Touch事件藕坯。
