原文链接简简单单讲清楚android事件分发。什么叫事件分发机制 ?事件分发是:当发生了一个事件时,在屏幕上找到一个合适的控件来处理这个事件的过程。因为一个界面上控件如此之多,发生一个事件后总要寻找一个合适来处理事件吧。这个过程就叫做事件分发的机制。常见事件那么屏幕上都会发生什么事件呢?来看下经常要处理的4种事件(这些事件在android中会被封装成 MotionEvent 对象):事件简介ACTION_DOWN手指 初次接触到屏幕 时触发。ACTION_MOVE手指 在屏幕上滑动 时触发,会会多次触发。ACTION_UP手指 离开屏幕 时触发。ACTION_CANCEL事件 被上层拦截 时触发。屏幕中的控件原文链接为了在屏幕中如何寻找合适的处理事件的控件,我们先来看下屏幕中都有什么控件。假设我们写了如下的一个布局:<com.xyl.touchevent.test.RootView xmlns:android=“http://schemas.android.com/apk/res/android" xmlns:tools=“http://schemas.android.com/tools" android:layout_width=“match_parent” android:layout_height=“300dp” android:background="#4E5268” android:layout_margin=“20dp” tools:context=“com.xyl.touchevent.MainActivity”> <com.xyl.touchevent.test.ViewGroupA android:background="#95C3FA” android:layout_width=“200dp” android:layout_height=“200dp”> <com.xyl.touchevent.test.View1 android:background="#BDDA66" android:layout_width=“130dp” android:layout_height=“130dp”/> </com.xyl.touchevent.test.ViewGroupA> <com.xyl.touchevent.test.View2 android:layout_alignParentRight=“true” android:background="#BDDA66" android:layout_width=“80dp” android:layout_height=“80dp”/></com.xyl.touchevent.test.RootView>View结构:原文链接上面的代码运行到界面上由图中这几部分组成:可以看到在上面的View结构中莫名多出来的两个东西,PhoneWindow 和 DecorView ,这两个我们并没有在Layout文件中定义过,但是为什么会存在呢?1. PhoneWindowPhoneWindow是 Window 的唯一实现类,是所有视图的最顶层容器,视图的外观和行为都归他管,不论是背景显示,标题栏还是事件处理都是他管理的范畴。2. DecorViewDecorView是 PhoneWindow 的一个内部类,就是跟在 PhoneWindow 身边专业为 PhoneWindow 服务的,除了自己要干活之外,也负责消息的传递,PhoneWindow 的指示通过 DecorView 传递给下面的 View,而下面 View 的信息也通过 DecorView 回传给 PhoneWindow。事件分发流程在如上图View的树形结构中,事件发生时,最先由Activity接收,然后再一层层的向下层传递,直到找到合适的处理控件。大致如下:Activity -> PhoneWindow -> DecorView -> ViewGroup -> … -> View但是如果事件传递到最后的View还是没有找到合适的View消费事件,那么事件就会向相反的方向传递,最终传递给Activity,如果最后 Activity 也没有处理,本次事件才会被抛弃:Activity <- PhoneWindow <- DecorView <- ViewGroup <- … <- ViewAndroid中事件具体是怎样进行分发的原文链接当事件发生时,ViewGroup会在dispatchTouchEvent方法中先看自己能否处理事件,如果不能再去遍历子View查找合适的处理控件。如果到最后result还是false,表示所有的子View都不能处理,才会调用自身的onTouchEvent来处理。根据上面提到的原理,ViewGroup事件传递的伪代码如下:public boolean dispatchTouchEvent(MotionEvent ev) { boolean result = false; // 默认状态为没有消费过 if (!onInterceptTouchEvent(ev)) { // 如果没有拦截交给子View result = child.dispatchTouchEvent(ev); } if (!result) { // 如果事件没有被消费,询问自身onTouchEvent result = onTouchEvent(ev); } return result;}为了方便理解,这里贴出一张网上的别人的一张图:红色箭头方向表示事件分发方向。绿色箭头方向表示事件回传方向。上面的流程中存在部分不合理内容,请大家选择性接受。事件返回时 dispatchTouchEvent 直接指向了父View的 onTouchEvent 这一部分是不合理的,实际上它仅仅是给了父View的 dispatchTouchEvent 一个 false 返回值,父View根据返回值来调用自身的 onTouchEvent。ViewGroup 是根据 onInterceptTouchEvent 的返回值来确定是调用子View的 dispatchTouchEvent 还是自身的 onTouchEvent, 并没有将调用交给 onInterceptTouchEvent。如果在遍历过程中,发现了有可以处理事件的控件,就停止事件的传递,事件被消耗。本文参考资料:http://www.gcssloop.com/customview/dispatch-touchevent-theoryhttps://juejin.im/entry/58df5b33570c35005798493chttps://juejin.im/entry/580042082e958a0055b6cbbchttps://blog.csdn.net/carson_ho/article/details/54136311https://www.jianshu.com/p/31e20def82c2https://segmentfault.com/a/1190000004981942https://zhuanlan.zhihu.com/p/27608989http://gityuan.com/2015/09/19/android-touch/http://wuxiaolong.me/2015/12/19/MotionEvent/推荐阅读:推荐阅读: Android开发艺术探索