Android onTouchEvent, onClick及onLongClick的調(diào)

針對(duì)屏幕上的一個(gè)View控件，Android如何區(qū)分應(yīng)當(dāng)觸發(fā)onTouchEvent，還是onClick，亦或是onLongClick事件?

在Android中，一次用戶操作可以被不同的View按次序分別處理，并將完全響應(yīng)了用戶一次UI操作稱之為消費(fèi)了該事件(consume)，那么Android是按什么次序?qū)⑹录鬟f的呢?又在什么情況下判定為消費(fèi)了該事件?

搞清楚這些問(wèn)題對(duì)于編寫(xiě)出能正確響應(yīng)UI操作的代碼是很重要的，尤其當(dāng)屏幕上的不同View需要針對(duì)此次UI操作做出各種不同響應(yīng)的時(shí)候更是如此，一個(gè)典型例子就是用戶在桌面上放置了一個(gè)Widget，那么當(dāng)用戶針對(duì)widget做各種操作時(shí)，桌面本身有的時(shí)候要對(duì)用戶的操作做出響應(yīng)，有時(shí)忽略。只有搞清楚事件觸發(fā)和傳遞的機(jī)制才有可能保證在界面布局非常復(fù)雜的情況下，UI控件仍然能正確響應(yīng)用戶操作。

1. onTouchEvent

onTouchEvent中要處理的最常用的3個(gè)事件就是：ACTION_DOWN、ACTION_MOVE、ACTION_UP。

這三個(gè)事件標(biāo)識(shí)出了最基本的用戶觸摸屏幕的操作，含義也很清楚。雖然大家天天都在用它們，但是有一點(diǎn)請(qǐng)留意，ACTION_DOWN事件作為起始事件，它的重要性是要超過(guò)ACTION_MOVE和ACTION_UP的，如果發(fā)生了ACTION_MOVE或者ACTION_UP，那么一定曾經(jīng)發(fā)生了ACTION_DOWN。

從Android的源代碼中能看到基于這種不同重要性的理解而實(shí)現(xiàn)的一些交互機(jī)制，SDK中也有明確的提及，例如在ViewGroup的onInterceptTouchEvent方法中，如果在ACTION_DOWN事件中返回了true，那么后續(xù)的事件將直接發(fā)給onTouchEvent，而不是繼續(xù)發(fā)給onInterceptTouchEvent。

2. onClick、onLongClick與onTouchEvent

曾經(jīng)看過(guò)一篇帖子提到，如果在View中處理了onTouchEvent，那么就不用再處理onClick了，因?yàn)锳ndroid只會(huì)觸發(fā)其中一個(gè)方法。這個(gè)理解是不太正確的，針對(duì)某個(gè)view，用戶完成了一次觸碰操作，顯然從傳感器上得到的信號(hào)是手指按下和抬起兩個(gè)操作，我們可以理解為一次Click，也可以理解為發(fā)生了一次ACTION_DOWN和ACTION_UP，那么Android是如何理解和處理的呢?

在Android中，onClick、onLongClick的觸發(fā)是和ACTION_DOWN及ACTION_UP相關(guān)的，在時(shí)序上，如果我們?cè)谝粋€(gè)View中同時(shí)覆寫(xiě)了onClick、onLongClick及onTouchEvent的話，onTouchEvent是最先捕捉到ACTION_DOWN和ACTION_UP事件的，其次才可能觸發(fā)onClick或者onLongClick。主要的邏輯在View.java中的onTouchEvent方法中實(shí)現(xiàn)的：

case MotionEvent.ACTION_DOWN:

mPrivateFlags |= PRESSED;

refreshDrawableState();

if ((mViewFlags LONG_CLICKABLE) == LONG_CLICKABLE) {

postCheckForLongClick();

}

break;

case MotionEvent.ACTION_UP:

if ((mPrivateFlags PRESSED) != 0) {

boolean focusTaken = false;

if (isFocusable() isFocusableInTouchMode() !isFocused()) {

focusTaken = requestFocus();

}

if (!mHasPerformedLongPress) {

if (mPendingCheckForLongPress != null) {

removeCallbacks(mPendingCheckForLongPress);

}

if (!focusTaken) {

performClick();

}

}

…

break;

可以看到，Click的觸發(fā)是在系統(tǒng)捕捉到ACTION_UP后發(fā)生并由performClick()執(zhí)行的，performClick里會(huì)調(diào)用先前注冊(cè)的監(jiān)聽(tīng)器的onClick()方法：

public boolean performClick() {

…

if (mOnClickListener != null) {

playSoundEffect(SoundEffectConstants.CLICK);

mOnClickListener.onClick(this);

return true;

}

return false;

}

LongClick的觸發(fā)則是從ACTION_DOWN開(kāi)始，由postCheckForLongClick()方法完成：

private void postCheckForLongClick() {

mHasPerformedLongPress = false;

if (mPendingCheckForLongPress == null) {

mPendingCheckForLongPress = new CheckForLongPress();

}

mPendingCheckForLongPress.rememberWindowAttachCount();

postDelayed(mPendingCheckForLongPress, ViewConfiguration.getLongPressTimeout());

}

可以看到，在ACTION_DOWN事件被捕捉后，系統(tǒng)會(huì)開(kāi)始觸發(fā)一個(gè)postDelayed操作，delay的時(shí)間在Eclair2.1上為500ms，500ms后會(huì)觸發(fā)CheckForLongPress線程的執(zhí)行：

class CheckForLongPress implements Runnable {

…

public void run() {

if (isPressed() (mParent != null)

mOriginalWindowAttachCount == mWindowAttachCount) {

if (performLongClick()) {

mHasPerformedLongPress = true;

}

}

}

…

}

如果各種條件都滿足，那么在CheckForLongPress中執(zhí)行performLongClick()，在這個(gè)方法中將調(diào)用onLongClick()：

public boolean performLongClick() {

…

if (mOnLongClickListener != null) {

handled = mOnLongClickListener.onLongClick(View.this);

}

…

}

從實(shí)現(xiàn)中可以看到onClick()和onLongClick()方法是由ACTION_DOWN和ACTION_UP事件捕捉后根據(jù)各種情況最終確定是否觸發(fā)的，也就是說(shuō)如果我們?cè)谝粋€(gè)Activity或者View中同時(shí)監(jiān)聽(tīng)或者覆寫(xiě)了onClick(),onLongClick()和onTouchEvent()方法，并不意味著只會(huì)發(fā)生其中一種。

下面是一個(gè)onClick被觸發(fā)的基本時(shí)序的Log：

04-05 05:57:47.123: DEBUG/TSActivity(209): onTouch ACTION_DOWN

04-05 05:57:47.263: DEBUG/TSActivity(209): onTouch ACTION_UP

04-05 05:57:47.323: DEBUG/TSActivity(209): onClick

可以看出是按ACTION_DOWN -> ACTION_UP -> onClick的次序發(fā)生的。

下面是一個(gè)onLongClick被觸發(fā)的基本時(shí)序的Log：

04-05 06:00:04.133: DEBUG/TSActivity(248): onTouch ACTION_DOWN

04-05 06:00:04.642: DEBUG/TSActivity(248): onLongClick

04-05 06:00:05.083: DEBUG/TSActivity(248): onTouch ACTION_UP

可以看到，在保持按下的狀態(tài)一定時(shí)間后會(huì)觸發(fā)onLongClick,之后抬起手才會(huì)發(fā)生ACTION_UP。

3. onClick和onLongClick能同時(shí)發(fā)生嗎?

要弄清楚這個(gè)問(wèn)題只要理解Android對(duì)事件處理的所謂消費(fèi)(consume)概念即可，一個(gè)用戶的操作會(huì)被傳遞到不同的View控件和同一個(gè)控件的不同監(jiān)聽(tīng)方法處理，任何一個(gè)接收并處理了該次事件的方法如果在處理完后返回了true，那么該次event就算被完全處理了，其他的View或者監(jiān)聽(tīng)方法就不會(huì)再有機(jī)會(huì)處理該event了。

onLongClick的發(fā)生是由單獨(dú)的線程完成的，并且在ACTION_UP之前，而onClick的發(fā)生是在ACTION_UP后，因此同一次用戶touch操作就有可能既發(fā)生onLongClick又發(fā)生onClick。這樣是不是不可思議?所以及時(shí)向系統(tǒng)表示“我已經(jīng)完全處理(消費(fèi))了用戶的此次操作”，是很重要的事情。例如，我們?nèi)绻趏nLongClick()方法的最后return true，那么onClick事件就沒(méi)有機(jī)會(huì)被觸發(fā)了。

下面的Log是在onLongClick()方法return false的情況下，一次觸碰操作的基本時(shí)序：

04-05 06:00:53.023: DEBUG/TSActivity(277): onTouch ACTION_DOWN

04-05 06:00:53.533: DEBUG/TSActivity(277): onLongClick

04-05 06:00:55.603: DEBUG/TSActivity(277): onTouch ACTION_UP

04-05 06:00:55.663: DEBUG/TSActivity(277): onClick

可以看到，在ACTION_UP后仍然觸發(fā)了onClick()方法。