触摸事件之事件分发

上篇文章中，分析了我之前关于触摸事件的一点疑问，感兴趣的，可点击触摸事件之onTouch和onTouchEvent查看

趁着热乎劲儿，继续再来巩固下完整的事件分发流程吧。
先不回忆细节，单纯从最简单的角度来看，事件分发无非就3步：事件产生->事件传递->事件处理。就跟春晚小品宋丹丹问赵大叔把大象放进冰箱分几步一个道理。从最原始的角度出发来看待这个问题，中间的过程再逐步细化，这样大脑中有个清晰的流程，分析问题也会顺畅的多。

从手指触摸屏幕的那一刻，触摸事件便产生了，抛开硬件层面的电容电流感应，到应用层的APP层面，最先肯定是由Activity接收到事件，咱们来瞧瞧Activity里面的处理过程；

 public boolean dispatchTouchEvent(MotionEvent ev) {
        //...
        if (getWindow().superDispatchTouchEvent(ev)) {
            return true;
        }
        return onTouchEvent(ev);
    }

里面有行代码很关键，“getWindow().superDispatchTouchEvent(ev)”，事件由window分发，如果返回true,后面的onTouchEvent将不执行，怎么感觉这句话很熟悉？？原来上篇文章刚分析过类似的。继续追查这个window是什么，原来是：

mWindow = new PhoneWindow(this, window, activityConfigCallback);

熟悉安卓界面加载的都知道，phoneWindow跟DecorView密切相关，莫非window将事件传给了DecorView，继续看源码：

 @Override
public boolean superDispatchTouchEvent(MotionEvent event) {
    return mDecor.superDispatchTouchEvent(event);
}

果然，一切尽在预料之中啊，这种感觉很爽。DecorView中分发过程也很简单，

    public boolean superDispatchTouchEvent(MotionEvent event) {
        return super.dispatchTouchEvent(event);
    }

DecorView是一个FrameLayout布局，它由上下两部分组成，上面是actionBar，下面是我们最最亲爱的在setContentView（）方法中传进xml布局文件，生成的视图组。上面的事件已经分发至DecorView了，现在我们将样式设为为noActionBar，那么DecorView布局中就只有一个contentView布局。在上面的方法中，由于FrameLayout没有重写分发方法，所以会接着向上查找分发方法，最终找到ViewGroup中的dispatchTouchEvent方法，而这个viewGroup中的第一个子view就是contentView生成的视图组。接下来看看viewGroup中的分发方法。

for (int i = childrenCount - 1; i >= 0; i--) {
//...
        if (dispatchTransformedTouchEvent(ev, false, child, idBitsToAssign)) {
             // Child wants to receive touch within its bounds.
             mLastTouchDownTime = ev.getDownTime();
        }
//...
}

代码很长，挑关键的看，看到for循环，知道重头戏来了，我们知道DecorView作为所有Activity根视图的外层容器，一个Activity界面就是有一个个ViewGroup不断包含子View构成的，在ViewGroup里对所有子view进行遍历，肯定也会遍历传递处理触摸事件，我们找child和touchEvent两个关键字，找到一个方法
“dispatchTransformedTouchEvent”，进去看一下：

    private boolean dispatchTransformedTouchEvent(MotionEvent event, boolean cancel,
            View child, int desiredPointerIdBits) {
        final boolean handled;

        // Canceling motions is a special case.  We don't need to perform any transformations
        // or filtering.  The important part is the action, not the contents.
        final int oldAction = event.getAction();
        if (cancel || oldAction == MotionEvent.ACTION_CANCEL) {
            event.setAction(MotionEvent.ACTION_CANCEL);
            if (child == null) {
                handled = super.dispatchTouchEvent(event);
            } else {
                handled = child.dispatchTouchEvent(event);
            }
            event.setAction(oldAction);
            return handled;
        }
       //...
}

期待已久的child.dispatchTouchEvent(event)出现了！！出现了！！截止到目前为止，根据我们所掌握的信息，可以很肯定的是，

根据child类型的不同，dispatchTouchEvent实现肯定也不同，view类型的不细说了，直接贴代码吧：

public boolean dispatchTouchEvent(MotionEvent event) {
//...
            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;
            }
//...
}

ViewGroup相比于View肯定要复杂些，其内部多了要处理子view的情况，在这里贴上一位网友制作的图，个人认为很不错：

ViewGroup分发流程

途中很清晰的描绘了viewgroup是如何把事件传递给子view的，onInterceptTouchEvent是viewGroup中独有的方法，它的返回值直接决定了是否会将事件传递给子view处理。如果子 View 不处理，这个“锅”就得 ViewGroup 自己担着。所以事件会传递到 super.dispatchTouchEvent()。ViewGroup 类继承自 View 类，也就是进入了前文说的 View 事件分发流程，就相当于询问当前 ViewGroup 自己是否处理这个事件，细节这里就不重复了。如果当前 ViewGroup自己处理了，对于上级 ViewGroup 而言，还是找到了 target，如果当前 ViewGroup 不处理，这个“锅”继续抛给上级 ViewGroup。

当最外层的子view接收到分发事件时，会进入它自身的dispatchTouchEvent方法，当它不拦截时，事件会继续进入到onTouchEvent方法中处理，然后再一级一级向上传递返回值。

以上就是触摸事件分发流程的简要分析，源码也一直在更新。掌握了主要的流程，任他怎么改，也能做到心中有数。

参考：
通过流程图来分析Android事件分发

触摸事件之事件分发

你可能感兴趣的:(触摸事件之事件分发)