Android System——事件传递(一) View
Android开发中，在很多的滑动控件嵌套的情况下经常会出现滑动事件冲突等等。以及在自定义控件的时候，需要处理触摸、点击、滑动等事件。需要考虑父容器的这些事件的冲突问题，所以在面对这些问题的时候我们就需要了解Android的事件传递机制，了解系统的机制方面的问题，最有效的方式就是研究系统的实现源码。这篇我们就参照源码来分析Android中的事件传递机制。
在Android中的事件 大量存在于Activity View ViewGroup Key 我们这里主要研究的是View和ViewGroup的事件传递
View的事件传递机制
我们先从一个栗子讲起，先创建一个布局，界面很简单，只有一个按钮，我们通过观察这个按钮的点击事件的日志输出来观察事件的传递
- activity.xml
<?xml version="1.0" encoding="utf-8"?>
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:app="http://schemas.android.com/apk/res-auto"
xmlns:tools="http://schemas.android.com/tools"
android:id="@+id/rl"
android:layout_width="match_parent"
android:layout_height="match_parent"
tools:context=".MainActivity">
<Button
android:id="@+id/btn"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:text="BUTTON" />
</RelativeLayout>
然后我们在activity中对父布局的RelativeLayout和Button的touch事件和点击click事件进行监听，RelativeLayout继承自ViewGroup，Button继承自View所有两个控件都有TouchEvent和Click事件，并分别输出对应的log日志
- MainActivity.java
public class MainActivity extends AppCompatActivity implements View.OnTouchListener, View.OnClickListener {
private static final String TAG = "PROBUING";
private RelativeLayout rl;
private Button btn;
@SuppressLint("ClickableViewAccessibility")
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
rl = ((RelativeLayout) findViewById(R.id.rl));
btn = ((Button) findViewById(R.id.btn));
rl.setOnTouchListener(this);
rl.setOnClickListener(this);
btn.setOnTouchListener(this);
btn.setOnClickListener(this);
}
@Override
public boolean onTouch(View v, MotionEvent event) {
Log.d(TAG, "onTouch: event----" + event.getAction() + "view----" + v);
return false;
}
@Override
public void onClick(View v) {
Log.d(TAG, "onClick: view" + v);
}
}
我们运行起来项目。点击按钮，查看log日志输出
log日志输出
我们可以看到OnTouchListener首先响应了事件，分别执行了按下事件和松开事件。然后才执行了Button的点击事件onClick事件，触摸事件先响应然后才响应onClick事件，而且是当松开按钮的时候才响应触摸事件，如果持续保持按压状态，则按钮不会响应按钮的onClick事件
然后，我们将onTouch的返回值改为true。再次观察一下log输出
@Override
public boolean onTouch(View v, MotionEvent event) {
Log.d(TAG, "onTouchListener: event----" + event.getAction() + "view----" + v);
return true;
}
log输出
所以我们发现：在当onTouch返回为true的时候，阻止了onClick的事件传递，我们在前面已经测试发现，只有在按钮松开后才会响应onClick，也就是响应了ACTION_UP事件才会执行。也可以说在onTouch返回true后，ACTION_UP事件没有传递。这是怎么一回事呢？
我们需要先了解一下View的事件分发
View的事件分发
View的事件分发我们需要看一个方法 。我们通过View的事件分发的实现源码来分析分发流程
首先，View的事件分发流程是：由dispatchTouchEvent方法分发到对应的onTouchListener的onTouch方法，然后再分发到View自己的onTouchEvent，最后到onClick()
在view的dispathcTouchEvent方法的注释中，对于返回值的解释是
/**
* Pass the touch screen motion event down to the target view, or this
* view if it is the target.
*
* @param event The motion event to be dispatched.
* @return True if the event was handled by the view, false otherwise.
*/
public boolean dispatchTouchEvent(MotionEvent event) {
也就是说如果返回true表示view接受处理这个事件，如果返回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;
}
}
源码分析 API28
其中ListenerInfo是View的内部类，这个类定义了各种的监听以及事件，包括焦点变化监听，滚动变化监听，点击事件监听等。
这里的判断逻辑就是，如果存在相关监听的事件也就是在之前setListener，并且view的flag状态是ENABLED也就是可以响应事件的，还有 onTouch方法返回true，则改变result为true dispathcTouchEvent则返回true表示这个view需要处理这个事件。
在往下看，如果上面的这些条件都不满足，此时result为false,那么下面的判断，如果View自身的onTouchEvent返回为true则也会将result=true也表示View需要处理事件。
这里我们也能看出，如果在第一个if判断中设置了onTouchListener，并且onTouchListener的onTouch方法返回true，那么view自身的onTouchEvent就不会再被调用了
所以我们可以看出view的事件分发顺序就是
dispathcTouchEvent-->onTouchListener--->return false ---> onTouchEvent
如果view的事件响应设置为disable，则不会执行onTouchListener的onTouch方法。但是会执行View自身的onTouchEvent方法
但是我们没有发现view的onClick方法的调用，其实onClick在中，在判断事件类型的swithc中，我们看ACTION_DOWN按下的事件，这里的逻辑是保存一些状态，记录一些按钮的信息，以及延迟一些反馈(感觉像5.0版本以上的水波纹效果)，
在ACTION_UP抬起的事件中，我们看到这样的代码
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)) {
performClickInternal();
}
}
}
在performClickInternal中调用了 performClick()方法，就是在这个方法中执行了view的onClick方法
/**
* Entry point for {@link #performClick()} - other methods on View should call it instead of
* {@code performClick()} directly to make sure the autofill manager is notified when
* necessary (as subclasses could extend {@code performClick()} without calling the parent's
* method).
*/
private boolean performClickInternal() {
// Must notify autofill manager before performing the click actions to avoid scenarios where
// the app has a click listener that changes the state of views the autofill service might
// be interested on.
notifyAutofillManagerOnClick();
return performClick();
}
在performClick中，可以看到如果设置了监听的话就会调用view的onClick方法。
public boolean performClick() {
// We still need to call this method to handle the cases where performClick() was called
// externally, instead of through performClickInternal()
notifyAutofillManagerOnClick();
final boolean result;
final ListenerInfo li = mListenerInfo;
if (li != null && li.mOnClickListener != null) {
playSoundEffect(SoundEffectConstants.CLICK);
li.mOnClickListener.onClick(this);
result = true;
} else {
result = false;
}
sendAccessibilityEvent(AccessibilityEvent.TYPE_VIEW_CLICKED);
notifyEnterOrExitForAutoFillIfNeeded(true);
return result;
}
所以我们可以得出一个初步的结论。也就是说在view的onTouchEventListener中的onTouch()如果返回了true，表示此次事件被处理，也就是按下的ACTION_DOWN事件被消耗，但是ACTION_UP事件无法传递执行，所以onClick不会执行。
如果onTouchEventListener中的onTouch返回false。则会执行View自身的onTouchEvent方法，表示onTouch不会消耗事件，所以onClick点击事件会响应。
View事件分发调用顺序
我们在了解了View的源码事件分发的基本情况后，那么我们需要验证一下事件的分发顺序是否和我们观测到的是一致的呢，我们使用一个自定义的控件来验证一下猜想
- MyButton.java
/**
* @author wxblack-mac
* @DESCRIBE:
* @DATE 2019/3/27 18:25
* GOOD LUCK
*/
@SuppressLint("AppCompatCustomView")
public class MyButton extends Button {
public MyButton(Context context, AttributeSet attrs) {
super(context, attrs);
}
@Override
public boolean dispatchTouchEvent(MotionEvent event) {
Log.d(TAG, "dispatchTouchEvent: dispatchTouch" + event.getAction());
return super.dispatchTouchEvent(event);
}
@Override
public boolean onTouchEvent(MotionEvent event) {
Log.d(TAG, "onTouchEvent: action:" + event.getAction());
return super.onTouchEvent(event);
}
}
然后再修改布局文件
- activity_main.xml
<com.d9ing.toucheventlsn.MyButton
android:id="@+id/btn"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:text="BUTTON" />
onTouch返回true
我们先将onTouchEventListener的onTouch方法返回true看点击事件click是否执行,以及执行顺序
log输出
我们看到按钮点击后的日志打印是：
dispathcTouchEvent---->onTouch
没有看到onTouchEvent执行，也没有onClick执行。所以当onTouchEventListener的onTouch返回为true的时候事件会被消费，所以不会执行onTouchEvent方法。不会响应点击事件。
onTouch返回false
我们再将onTouchEventListener的onTouch方法返回false看一下事件的分发顺序以及响应：
log输出
我们可以看到，事件的传递顺序是：
dispatchTouchEvent---->onTouchListener的onTouch---->onTouchEvent---->onClick
从上面的执行顺序来看和我们的猜想是一致的。
onTouchEvent 返回true
接下来我们将MyButton的onTouchEvent的返回结果改为true看一下结果
log输出
我们看到onClick事件没有响应了，DOWN事件消费了，UP事件也分发了但是没有执行onClick，这种结果是怎么出现的呢？
通过刚才我们分析源码得知，事件的响应和调用事件方法是在View的onTouchEvent方法，可我们重写了View的onTouchEvent方法后，但没有执行父类View的事件处理方法，这样的话就不会有任何的事件被响应。在dispathcTouchEvent中调用了onTouchEvent后，执行我们自定义的方法 返回了true，所以不会有onClick执行。
那么，我们在返回true之前调用super.onTouchEvent呢？
@Override
public boolean onTouchEvent(MotionEvent event) {
Log.d(TAG, "onTouchEvent: action:" + event.getAction());
super.onTouchEvent(event);
return true;
}
log输出
我们看到执行就正常了，所以我们重写onTouchEvent需要执行super的onTouchEvent方法，才能将事件响应。
onTouchEvent 返回false
那么我们将onTouchEvent的返回false是什么情况呢？
log输出
我们看到在按下事件DOWN方法被消费，但是后续的UP事件被父类消费了，这是为什么呢？
这就是
- 如果onTouchEvent返回true表示View会消费DOWN按下事件以及以后的事件。
- 如果onTouchEvent返回false表示View会消费DOWN事件，并不在响应后续的事件。自己不消耗后续的事件后会向父控件传递事件。
关于父控件的，会在下一个篇章中说明
dispatchTouchEvent 返回true
如果我们将MyButton的dispatchTouchEvent返回true,会发生什么情况呢？
@Override
public boolean dispatchTouchEvent(MotionEvent event) {
Log.d(TAG, "dispatchTouchEvent: dispatchTouch" + event.getAction());
super.dispatchTouchEvent(event);
return true;
}
这里和onTouchEvent一样，需要调用父类的dispatchTouchEvent，来保证父类的逻辑执行。
log输出
我们可以看到事件分发执行正常为：
dispatchTouchEvent--->onTouch--->onTouchEvent---->onClick
事件DOWN和UP都被MyButton消费
其实在源码中已经解释了，会默认返回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;
}
dispatchTouchEvent返回false
@Override
public boolean dispatchTouchEvent(MotionEvent event) {
Log.d(TAG, "dispatchTouchEvent: dispatchTouch" + event.getAction());
super.dispatchTouchEvent(event);
return false;
}
log输出
可以看到，DOWN事件MyButton没有消费，直接发给了父类容器。后续的事件都发给了父容器
所以我们可以知道dispatchTouchEvent默认返回true
-
如果在某个控件的dispatchTouchEvent 返回true消费终结事件，那么收到ACTION_DOWN 的函数也能收到ACTION_MOVE和ACTION_UP。
-
在哪个View的onTouchEvent 返回true，那么ACTION_MOVE和ACTION_UP的事件从上往下传到这个View后就不再往下传递了，而直接传给自己的onTouchEvent 并结束本次事件传递过程。
-
ACTION_DOWN事件在哪个控件消费了（return true）， 那么ACTION_MOVE和ACTION_UP就会从上往下（通过dispatchTouchEvent）做事件分发往下传，就只会传到这个控件，不会继续往下传
-
如果ACTION_DOWN事件是在dispatchTouchEvent消费，那么事件到此为止停止传递
-
如果ACTION_DOWN事件是在onTouchEvent消费的，那么会把ACTION_MOVE或ACTION_UP事件传给该控件的onTouchEvent处理并结束传递。
