近日连续看了两篇讲触摸事件的，心里不禁产生了一个疑问，故这篇文章也是因为这个疑问而写的。这个疑问就是：“为什么会View类里面会同时有onTouch和onTouchEvent两个触摸相关的方法？”如果你心里已经有答案了，这篇文章可跳过，如果有跟我一样懵逼的，不妨你们也仔细回忆下到底为什么？
有了这个疑问在，我们的目的性就很明确了。还是先来看看它们在代码中的具体用法吧。
//...
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;
}
//...
系统先进行mOnTouchListener及onTouch返回值等相关条件的判断，不满足的话再执行onTouchEvent。，两个都是触摸相关的，不同的是onTouch方法比onTouchEvent方法多接收了一个参数。这又是为何？
我们继续看系统关于onTouch方法的说明：
/**
* Interface definition for a callback to be invoked when a touch event is
* dispatched to this view. The callback will be invoked before the touch
* event is given to the view.
*/
public interface OnTouchListener {
/**
* Called when a touch event is dispatched to a view. This allows listeners to
* get a chance to respond before the target view.
*
* @param v The view the touch event has been dispatched to.
* @param event The MotionEvent object containing full information about
* the event.
* @return True if the listener has consumed the event, false otherwise.
*/
boolean onTouch(View v, MotionEvent event);
}
注释说OnTouchListener是一个接口回调，当触摸事件分发到该View时它会被调用。
emm.从字面意思好像明白点什么
接着看onTouchEvent的：
/**
* Implement this method to handle touch screen motion events.
* <p>
* If this method is used to detect click actions, it is recommended that
* the actions be performed by implementing and calling
* {@link #performClick()}. This will ensure consistent system behavior,
* including:
* <ul>
* <li>obeying click sound preferences
* <li>dispatching OnClickListener calls
* <li>handling {@link AccessibilityNodeInfo#ACTION_CLICK ACTION_CLICK} when
* accessibility features are enabled
* </ul>
*
* @param event The motion event.
* @return True if the event was handled, false otherwise.
*/
public boolean onTouchEvent(MotionEvent event) {
//...
}
实现这个用法用来处理触摸屏幕的一些事件动作，如果这个方法用来检测点击动作，通常建议该动作由实现performClick方法发出。
从以上两段注释来看，姑且可以给个总结：
onTouch方法用来在进行真正的触摸事件处理之前可以做些额外的事情。
好像有点拦截的味道。那到底拦截触摸事件干嘛呢？触摸事件之前还有什么要优先处理的呢？
再读遍上面的总结，其实核心在于 “拦截触摸事件处理”。那触摸事件到底在处理什么呢，我们再仔细看看onTouchEvent的源码：
public boolean onTouchEvent(MotionEvent event) {
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;
}
//...
方法开始就进行了clickable变量的判断，如果是DISABLED的直接后面方法不执行了，这个变量作用可太大了，再看其名字，有click字样，莫非跟点击事件有关，继续往后看：
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)) {
performClickInternal();
}
}
果然看到了熟悉的performClick.里面就是很普通的click回调了：
public boolean performClick() {
//...
final ListenerInfo li = mListenerInfo;
if (li != null && li.mOnClickListener != null) {
playSoundEffect(SoundEffectConstants.CLICK);
li.mOnClickListener.onClick(this);
//...
}
结论：
所以onTouchEvent的重要性不言而喻了，那点击触摸都有它处理了，onTouch又有什么用呢？回忆上面的代码，点击事件嵌入在onTouchEvent里，比如我们有个控件只想要触摸监听，不需要点击事件，那单纯的onTouchEvent方法显然没法满足我们的需求，此时onTouch方法就派上用场了。在它里面处理，结果返回true，直接绕过了onTouchEvent里众多复杂流程，岂不快哉！
