【透镜系列】看穿 > 触摸事件分发 >

（转载请注明做者：RubiTree，地址：blog.rubitree.com ）

引子

事件分发，我想大部分人都能说几句，哦，三大方法，哦，那段经典伪代码，哦，责任链... 但若是要让你完完整整捋一遍，你可能就开始支支吾吾了，只能想到啥说啥

这块的东西确实麻烦，说出来不怕吓到你，事件流到底怎么流与这些因素都有关系：是什么事件类型（DOWN/MOVE/UP/CANCEL）、在哪一个视图层次（Activity/ViewGroup/View）、在哪一个回调方法（dispatch()/onIntercept()/onTouch()）、回调方法给不一样的返回值（true/false/super.xxx），甚至对当前事件的不一样处理还会对同一事件流中接下来的事件形成不一样影响

好比我能够问：重写某个ViewGroup里的dispatchTouchEvent方法，对MOVE事件返回false，整个事件分发过程会是什么样的？

因而就有人对这些状况分门别类进行总结，获得了不少规律，也画出了纷繁复杂的事件分发流程图：

甚至还有相似题图那样的动态流程图 （是的，吸引你进来的题图竟然是反面教材，我也很心疼啊，画了我半个下午，结果并无太大的帮助）

这些规律和流程图确实是对的，并且某种意义上也是很是清晰的，能帮助你在调试 Bug 的时候找到一点方向。 你或许能够奋发图强，把这些流程图和规律背下来，也能在须要的时候一通叽里呱啦背完你们大眼瞪小眼。 但它们并不能让你真正理解事件分发是什么样子，你可能某一次花费了大量的时间去看懂它们，可是「每次都能看明白！过一段时间又忘了！」 （某段有表明性的评论原话）

但讲道理，分发个触摸事件为何会这么复杂呢？须要这么复杂吗？图啥呢？

因而，让咱们回到起点，看看分发触摸事件究竟是为了解决一个什么样的问题，有没有更简单的分发办法？而后看看当需求增长的时候，要怎么调整这个简单的分发策略？ 看到最后你就会发现，原来一切是那么地天然。

因此，不用死记硬背，也不用急着去怼完整的事件分发流程，那么多复杂的逻辑和状况其实都是围绕着最根本的问题发展出来的，是随着需求的增长一步步变得复杂的，理解了演化过程，你天然会对其演化的结果了然于胸，想忘都忘不掉。

从根本问题出发，一切就会变得天然而然。

艾维巴蒂，黑喂狗！ 下面我将从最简单的需求开始思考方案、编写代码，而后一步步增长需求、调整方案、继续编写代码，争取造出一个麻雀虽小五脏俱全的事件分发框架。

1. 五造轮子

1.1. 一造：直接传给目标View

咱们先实现一个最简单的需求：Activity 中有一堆层层嵌套的 View，有且只有最里边那个 View 会消费事件

（黄色高亮 View 表明能够消费事件，蓝色 View 表明不消费事件）

思考方案：

1. 首先事件从哪儿来，确定得从父亲那来，由于子View被包裹在里面，没有直接与外界通讯的办法，而实际中Activity链接着根ViewDecorView，它是通往外界的桥梁，能接收到屏幕硬件发送过来的触摸事件
2. 因此事件是从Activity开始，通过一层一层 ViewGroup ，传到最里边的 View
3. 这时只须要一个从外向里传递事件的passEvent(ev)方法，父亲一层层往里调，能把事件传递过去，就完成了需求

示意图

麻雀代码：

（本文代码使用Kotlin编写，核心代码也提供了Java版本）

open class MView {
    open fun passEvent(ev: MotionEvent) {
        // do sth
    }
}
    
class MViewGroup(private val child: MView) : MView() {
    override fun passEvent(ev: MotionEvent) {
        child.passEvent(ev)
    }
}
复制代码

1. 暂时把Activity当成MViewGroup处理也没有问题
2. 为何是MViewGroup继承MView而不是反过来，由于 MView 是不须要 child 字段的

1.2. 二造：从里向外传给目标View

而后咱们增长一条需求，让状况复杂一点：Activity中有一堆层层嵌套的View，有好几个叠着的View能处理事件

同时须要增长一条设计原则：用户的一次操做，只能被一个View真正处理（消费）

1. 要求这条原则是为了让操做的反馈符合用户直觉
2. 很容易理解，正常状况下人只会想一次就作一件事
   1. 好比一个列表条目，列表能够点击进入详情，列表上还有个编辑按钮，点击能够编辑条目
      1. 这是一个上下两个View都能点击的场景，但用户点一个地方，确定只想去作一件事，要么进入详情，要么是编辑条目，若是你点编辑结果跳了两个页面，那确定是不合适的
   2. 再好比在一个可点击Item组成的列表里（好比微信的消息界面），Item能够点击进入某个聊天，列表还能滑动上下查看
      1. 若是你让Item和列表都处理事件，那在你滑动的时候，你可能得跳一堆你不想去的聊天页面

若是使用第一次试造的框架，要遵照这条原则，就须要在每个能够处理事件的View层级，判断出本身要处理事件后，不继续调用child的passEvent()方法了，保证只有本身处理了事件。 但若是真这样实现了，在大部分场景下会显得怪怪的，由于处理事件的顺序不对：

1. 好比仍是上面的列表，当用户点击按钮想编辑条目的时候，点击事件先传到条目，若是你在条目中判断须要事件，而后把事件消费了不传给子View，用户就永远点不开编辑条目了
2. 并且换个角度看更加明显，用户确定但愿点哪，哪儿最靠上、离手指最近的东西被触发

因此实现新增需求的一个关键是：找到那个适合处理事件的View，而咱们经过对业务场景进行分析，获得答案是：那个最里面的View适合处理事件

这就不能是等parent不处理事件了才把事件传给child，应该反过来，你须要事件的处理顺序是从里向外：里边的child不要事件了，才调用parent的passEvent()方法把事件传出来。 因而得加一条向外的通道，只能在这条向外的通道上处理事件，前面向里的通道什么都不干，只管把事件往里传。 因此这时你有了两条通道，改个名字吧，向里传递事件是passIn()方法，向外传递并处理事件是passOut()方法。

示意图

麻雀代码：

open class MView {
    var parent: MView? = null

    open fun passIn(ev: MotionEvent) {
        passOut(ev)
    }

    open fun passOut(ev: MotionEvent) {
        parent?.passOut(ev)
    }
}

class MViewGroup(private val child: MView) : MView() {
    init {
        child.parent = this // 示意写法
    }

    override fun passIn(ev: MotionEvent) {
        child.passIn(ev)
    }
}
复制代码

这段代码没有问题，很是简单，可是它对需求意图的表达不够清晰，增长了框架的使用难度

1. 如前所述，咱们但愿passIn()的时候只传递事件，但愿在passOut()的时候每一个View决定是否要处理事件，并进行处理，并且在处理事件后，再也不调用parent的passOut()方法把事件传出来
2. 你会发现，这其中包含了两类职责：
   1. 一类是事件传递控制逻辑，另外一类是事件处理钩子
   2. 其中事件传递控制逻辑基本不会变化，但事件处理的钩子中可能作任何事情
3. 咱们须要把不一样职责的代码分开，更须要把变化的和不变的分开，减小框架使用者的关注点

因而咱们用一个叫作dispatch()的方法单独放事件传递的控制逻辑，用一个叫作onTouch()的方法做为事件处理的钩子，并且钩子有一个返回值，表示钩子中是否处理了事件：

open class MView {
    open fun dispatch(ev: MotionEvent): Boolean {
        return onTouch(ev)
    }

    open fun onTouch(ev: MotionEvent): Boolean {
        return false
    }
}

class MViewGroup(private val child: MView) : MView() {
    override fun dispatch(ev: MotionEvent): Boolean {
        var handled = child.dispatch(ev)
        if (!handled) handled = onTouch(ev)

        return handled
    }

    override fun onTouch(ev: MotionEvent): Boolean {
        return false
    }
}
复制代码

这样写完，整个行为其实没有变化，但你会发现：

1. 控制逻辑集中在dispatch()中，一目了然
2. onTouch()单纯是一个钩子，框架使用者只须要关心这个钩子和它的返回值，不用太关心控制流程
3. 另外，连parent也不须要了

1.3. 三造：区分事件类型

上文的实现看上去已经初具雏形了，但其实连开始提的那条原则都没实现完，由于原则要求一次操做只能有一个 View 进行处理，而咱们实现的是一个触摸事件只能有一个View进行处理。 这里就涉及到一次触摸操做和一个触摸事件的区别：

1. 假设尚未触摸事件的概念，咱们要怎么区分一次触摸操做呢？
   1. 把触摸操做细分一下，大概有按下动做、抬起动做、与屏幕接触时的移动和停留动做
   2. 很容易想到，要区分两次触摸操做，能够经过按下和抬起动做进行区分，按下动做开始了一次触摸操做，抬起动做结束了一次触摸，按下和抬起中间的移动和停留都属于这一次触摸操做，至于移动和停留是否要区分，目前没有看到区分的必要，能够都做为触摸中来处理
2. 因而在一次触摸操做中就有了三种动做的类型：DOWN/UP/ING，其中ING有点不够专业，改个名字叫MOVE吧
3. 而每一个触摸动做会在软件系统中产生一个一样类型的触摸事件
4. 因此最后，一次触摸操做就是由一组从DOWN事件开始、中间是多个MOVE事件、最后结束于UP事件的事件流组成

因而设计原则更确切地说就是：一次触摸产生的事件流，只能被一个View消费

在上次试造的基础上把一个事件变成一个组事件流，其实很是简单：处理DOWN事件时跟前面处理一个事件时同样，但须要同时记住DOWN事件的消费对象，后续的MOVE/UP事件直接交给它就好了

麻雀代码：

open class MView {
    open fun dispatch(ev: MotionEvent): Boolean {
        return onTouch(ev)
    }

    open fun onTouch(ev: MotionEvent): Boolean {
        return false
    }
}

class MViewGroup(private val child: MView) : MView() {
    private var isChildNeedEvent = false

    override fun dispatch(ev: MotionEvent): Boolean {
        var handled = false
        
        if (ev.actionMasked == MotionEvent.ACTION_DOWN) {
            clearStatus()
        
            handled = child.dispatch(ev)
            if (handled) isChildNeedEvent = true

            if (!handled) handled = onTouch(ev)
        } else {
            if (isChildNeedEvent) handled = child.dispatch(ev)
            if (!handled) handled = onTouch(ev)
        }
        
        if (ev.actionMasked == MotionEvent.ACTION_UP) {
            clearStatus()
        }
            
        return handled
    }
    
    private fun clearStatus() {
        isChildNeedEvent = false
    }

    override fun onTouch(ev: MotionEvent): Boolean {
        return false
    }
}
复制代码

代码好像增长了不少，其实只多作了两件事：

1. 增长了一个isChildNeedEvent状态，对是子View是否处理了DOWN事件进行记录，并在其余触摸事件时使用这个状态
2. 在收到DOWN事件的最开始和收到UP事件的最后，重置状态

此时框架使用者仍是只须要关心onTouch()钩子，在须要处理事件时进行处理并返回true，其余事情框架都作好了。

1.4. 四造：增长外部事件拦截

上面的框架已经能完成基本的事件分发工做了，但下面这个需求，你尝试一下用如今框架能实现吗？ 需求：在可滑动View中有一个可点击View，须要让用户即便按下的位置是可点击View，再进行滑动时，也能够滑动外面的的可滑动View。

这个需求其实很是常见，好比全部「条目可点击的滑动列表」就是这样的（微信/QQ聊天列表）。

假如使用上面的框架：

1. 可滑动View会先把事件传到里边的可点击View
2. 可点击View一看来事件了，我又能点击，那舍我其谁啊
3. 而后外面的可滑动View就永远没法处理事件，也就没法滑动

因此直接使用如今的模型去实现的「条目可点击的滑动列表」会永远滑动不了。

那怎么办呢？

1. 难道要让里面的可点击View去感知一下（层层往上找），本身是否是被一个能消费事件的View包裹？是的话本身就不消费事件了？
   1. 这确定是不行的，先不说子View层层反向遍历父亲是否是个好实现，至少不能外面是能够滑动的，里边View的点击事件就所有失效
2. 或者咱们调整dispatch()方法在传入事件过程当中的人设，让它不是只能往里传递事件，而是在本身能消费事件的时候把事件给本身
   1. 这确定也是不行的，跟第一个办法的主要问题同样

直接想实现以为处处是矛盾，找不到突破口，那就从头开始吧，从什么样的触摸反馈是用户以为天然的出发，看看这种符合直觉的反馈方案是否存在，找出来它是什么，再考虑咱们要怎么实现：

1. 当用户面对一个滑动View里有一个可点击View，当他摸在可点击View上时，他是要作什么？
2. 显然，只有两个可能性，要么用户想点这个可点击View，要么用户想滑动这个可滑动View
3. 那么，当用户刚用手指接触的时候，也就是DOWN事件刚来的时候，能判断用户想干什么吗？很抱歉，不能
4. 因此，客观条件下，你就是不可能在DOWN事件传过来的时候，判断出用户到底想作什么，因而两个View其实都不能肯定本身是否要消费事件

我*，这不傻*了吗，还搞什么GUI啊，你们都用命令行吧 等等，不要着急，GUI仍是得搞的，不搞没饭吃的我跟你讲，因此你仍是得想一想，想尽办法去实现。

你先忘记前面说的原则，你想一想，不考虑其余因素，也不是只能用DOWN事件，只要你能判断用户的想法就行，你有什么办法

1. 办法确定是有的，你能够多等一会，看用户接下来的行为能匹配哪一种操做模式
   1. 点击操做的模式是这样：用户先DOWN，而后MOVE很小一段，也不会MOVE出这个子View，关键是比较短的时间就UP
   2. 滑动操做的模式是这样：用户先DOWN，而后开始MOVE，这时候可能会MOVE出这个子View，也可能不，但关键是比较长的时间也没有在UP，一直是在MOVE
2. 因此你的结论是，只有DOWN不行，还得看接下来的事件流，得走着瞧
3. 再多考虑个长按的状况，总结就是：
   1. 若是在某个时间内UP，就是点击里边的View
   2. 若是比较长的时间UP，但没怎么MOVE，就是长按里边的View
   3. 若是在比较短的时间MOVE比较长的距离，就是滑动外面的View

看上去这个目标 View 断定方案很不错，安排得明明白白，但咱们现有的事件处理框架实现不了这样的断定方案，至少存在如下两个冲突：

1. 由于子View和父View都没法在DOWN的时候判断当前事件流是否是该给本身，因此一开始它们都只能返回false。但为了能对后续事件作判断，你但愿事件继续流过它们，按照当前框架的逻辑，你又不能返回false。
2. 假设事件会流过它们，当事件流了一下子后，父 View 判断出这符合本身的消费模式啊，因而想把事件给本身消费，但此时子 View 可能已经在消费事件了，而目前的框架是作不到阻止子 View 继续消费事件的

因此要解决上述的冲突，就确定要对上一版的事件处理框架进行修改，并且看上去一不当心就会大改

1. 首先看第二个冲突，解决它的一个直接方案是：调整 dispatch() 方法在传入事件过程当中的人设，让它不是只传递事件了，还能够在往里传递事件前进行拦截，可以看状况拦截下事件并交给本身的 onTouch() 处理
2. 基于这个解决方案，大概有如下两个改动相对小的方案调整思路：
   1. 思路一：
      1. 当事件走到可滑动父View的时候，它先拦截并处理事件，并且还把事件给攒着
      2. 当通过了几个事件
         1. 若是判断出符合本身的消费模式，那就直接开始本身消费了，也不用继续攒事件了
         2. 若是判断出不是本身的消费模式，再把全部攒着的事件一股脑给子 View，触发里边的点击操做
   2. 思路二：
      1. 全部的 View 只要可能消费事件，就在onTouch()里对DOWN事件返回true，无论是否识别出当前属于本身的消费模式
      2. 当事件走到到可滑动父 View 的时候，它先把事件往里传，里边可能会处理事件，可能不会，可滑动父 View 都暂时不关心
      3. 而后看子 View 是否处理事件
         1. 假如子 View 不处理事件，那啥问题没有，父 View 直接处理事件就行了
         2. 假如子 View 处理事件，可滑动父View就会绷紧神经暗中观察乘机而动，观察事件是否是符合本身的消费模式，一旦发现符合，它就把事件流拦截下来，即便子View也在处理事件，它也不往里disptach事件了，而是直接给本身的onTouch()
3. 两个思路总结一下：
   1. 思路一：外面的父 View 先拦事件，若是判断拦错了，再把事件往里发
   2. 思路二：外面的父 View 先不拦事件，在判断应该拦的时候，忽然把事件拦下来
4. 这两个思路都要对当前框架作改变，看似差很少，但其实仍是有比较明显的优劣的
   1. 思路一问题比较明显：
      1. 父 View 把事件拦下来了，而后发现拦错了再给子 View，但其实子 View 又并不必定能消费事件，这不就是白作一步吗。等到子View不处理事件，又把事件们还给父View，父View还得继续处理事件。整个过程不只繁琐，并且会让开发者感受到别扭
      2. 因此这个思路不太行，还得是把事件先给子View
   2. 思路二就相对正常多了，只有一个问题（下一节再讲，你能够猜一猜，这里我先当没发现），并且框架要作的改变也不多：
      1. 增长一个拦截方法onIntercept()在父 View 往里dispatch事件前，开发者能够覆写这个方法，加入本身的事件模式分析代码，而且能够在肯定要拦截的时候进行拦截
         1. 把分析拦截逻辑抽成一个方法很是合理：何时拦，何时不拦，内里的逻辑不少，但对外暴露的 API 能够很小，很是适合抽出去
      2. 在肯定本身要拦截事件的时候，即便里边在一开始消费了事件，也不把事件往里传了，而是直接给本身的onTouch()

示意图：

因而使用思路二，在「三造」的基础上，修改获得如下代码：

open class MView {
    open fun dispatch(ev: MotionEvent): Boolean {
        return onTouch(ev)
    }

    open fun onTouch(ev: MotionEvent): Boolean {
        return false
    }
}

class MViewGroup(private val child: MView) : MView() {
    private var isChildNeedEvent = false
    private var isSelfNeedEvent = false

    override fun dispatch(ev: MotionEvent): Boolean {
        var handled = false

        if (ev.actionMasked == MotionEvent.ACTION_DOWN) {
            clearStatus()
            
            if (onIntercept(ev)) {
                isSelfNeedEvent = true
                handled = onTouch(ev)
            } else {
                handled = child.dispatch(ev)
                if (handled) isChildNeedEvent = true

                if (!handled) {
                    handled = onTouch(ev)
                    if (handled) isSelfNeedEvent = true
                }
            }
        } else {
            if (isSelfNeedEvent) {
                handled = onTouch(ev)
            } else if (isChildNeedEvent) {
                if (onIntercept(ev)) {
                    isSelfNeedEvent = true
                    handled = onTouch(ev)
                } else {
                    handled = child.dispatch(ev)
                }
            }
        }

        if (ev.actionMasked == MotionEvent.ACTION_UP) {
            clearStatus()
        }
        
        return handled
    }

    private fun clearStatus() {
        isChildNeedEvent = false
        isSelfNeedEvent = false
    }

    override fun onTouch(ev: MotionEvent): Boolean {
        return false
    }

    open fun onIntercept(ev: MotionEvent): Boolean {
        return false
    }
}
复制代码

写的过程当中增长了一些对细节的处理：

1. 不只是在DOWN事件的dispatch()前须要拦截，在后续事件中，也须要加入拦截，不然没法实现中途拦截的目标
2. 在某一个事件判断拦截以后，还须要在后续事件中再判断一次是否要拦截吗？
   1. 彻底不须要，咱们但愿的就是在一次触摸中，尽量只有1个对象去消费事件，决定是你了，那就不要变
   2. 因此增长一个isSelfNeedEvent记录本身是否拦截过事件，若是拦截过，后续事件直接就交给本身处理
3. 在后续事件时，子 View 没有处理事件，外面也不会再处理了，一样由于只能有一个 View 处理（Actvity会处理这样的事件，后面会提到）

这一下代码是否是看上去瞬间复杂了，但其实只是增长了一个事件拦截机制，对比上一次试造的轮子，会更容易理解。（要是 Markdown 支持代码块内自定义着色就行了）

并且对于框架的使用者来讲，关注点仍是很是少

1. 重写onIntercept()方法，判断何时须要拦截事件，须要拦截时返回true
2. 重写onTouch()方法，若是处理了事件，返回true

1.5. 五造：增长内部事件拦截

上面的处理思路虽然实现了需求，但可能会致使一个问题：里边的子 View 接收了一半的事件，可能都已经开始处理并作了一些事情，父 View 突然就不把后续事件给它了，会不会违背用户操做的直觉？甚至出现更奇怪的现象？

这个问题确实比较麻烦，分两类状况讨论

1. 里边的 View 接收了一半事件，但尚未真正开始反馈交互，或者在进行能够被取消的反馈
   1. 好比对于一个可点击的View，View的默认实现是只要被touch了，就会有pressed状态，若是你设置了对应的background，你的 View 就会有高亮效果
   2. 这种高亮即便被中断也没事，不会让用户感受到奇怪，不信你本身试试微信的聊天列表
   3. 但一个值得注意的点是，若是你只是直接不发送MOVE事件了，这会有问题，就这个按下高亮的例子，若是你只是不传MOVE事件了，那谁来告诉里边的子View取消高亮呢？因此你须要在中断的时候也传一个结束事件
      1. 可是，你能直接传一个UP事件吗？也是不行的，由于这样就匹配了里边点击的模式了，会直接触发一个点击事件，这显然不是咱们想要的
      2. 因而外面须要给一个新的事件，这个事件的类型就叫取消事件好了CANCEL
   4. 总结一下，对于这种简单的可被取消状况，你能够这样去处理：
      1. 在肯定要拦截的时候，在把真正的事件转发给本身的onTouch()的同时，另外生成一个新的事件发给本身的子View，事件类型是CANCEL，它将是子View收到的最后一个事件
      2. 子View能够在收到这个事件后，对当前的一些行为进行取消
2. 里边的View接收了一半事件，已经开始反馈交互了，这种反馈最好不要去取消它，或者说取消了会显得很怪
   1. 这个时候，事情会复杂一些，并且这个场景发生的远比你想象中的多，形式也多种多样，不处理好的后果也比只是让用户感受上奇怪要严重得多，可能会有的功能会实现不了，下面举两个例子
      1. 在ViewPager里有三个page，page里是ScrollView，ViewPager能够横向滑动，page里的ScrollView能够竖向滑动
         1. 若是按前面逻辑，当ViewPager把事件给里边ScrollView以后，它也会偷偷观察，若是你一直是竖向滑动，那没话说，ViewPager不会触发拦截事件
         2. 但若是你竖着滑着滑着，手抖了，开始横滑（或者只是斜滑），ViewPager就会开始紧张，想「组织终于决定是我了吗？真的假的，那我可就不客气了」，因而在你斜滑必定距离以后，突然发现，你划不动ScrollView了，而ViewPager开始动
         3. 缘由就是ScrollView的竖滑被取消了，ViewPager把事件拦下来，开始横滑
         4. 这个体验仍是比较怪的，会有种过于灵敏的感受，会让用户只能当心翼翼地滑动
      2. 在一个ScrollView里有一些按钮，按钮有长按事件，长按再拖动就能够移动按钮
         1. （更常见的例子是一个列表，里边的条目能够长按拖动）
         2. 一样按前面的逻辑，当你长按后准备拖动按钮时，你怎么保证不让ScrollView把事件拦下来呢？
   2. 因此这类问题是必定要解决的，但要怎么解决呢
      1. 仍是先从业务上看，从用户的角度看，当里边已经开始作一些特殊处理了，外面应不该该把事件抢走？
         1. 不该该对吧，OK，解决方针就是不该该让外边的View抢事件
      2. 因此接下来的问题是：谁先判断出外边的View不应抢事件，里边的子View仍是外边的父View？而后怎么不让外边的View抢？
         1. 首先，确定是里边的View作出判断：这个事件，真的，外边的View你最好别抢，要不用户不开心了
         2. 而后里边就得告知外边，你别抢了，告知能够有几个方式
            1. 外边抢以前问一下里边，我能不能抢
            2. 里边在肯定这个事件不能被抢以后，从dispatch方法返回一个特别的值给外边（以前只是true和false，如今要加一个）
            3. 里边经过别的方式通知外边，你不要抢
         3. 讲道理，我以为三个方式都行，但第三个方式最为简单直接，并且对框架没有过大的改动，Android也使用了这个方式，父View给子View提供了一个方法requestDisallowInterceptTouchEvent()，子View调用它改变父View的一个状态，同时父View每次在准备拦截前都会判断这个状态（固然这个状态只对当前事件流有效）
         4. 而后，这个状况还得再注意一点，它应该是向上递归的，也就是，在复杂的状况中，有可能有多个上级在暗中观察，当里边的View决定要处理事件并且不许备交出去的时候，外面全部的暗中观察的父View都应该把脑壳转回去

因此，连同上一次试造，总结一下

1. 对于多个可消费事件的View进行嵌套的状况，怎么断定事件的归属会变得很是麻烦，没法马上在DOWN事件时就肯定，只能在后续的事件流中进一步判断
2. 因而在没判断归属的时候，先由里边的子View消费事件，外面暗中观察，同时两方一块对事件类型作进一步匹配，并准备在匹配成功后对事件流的归属进行抢拍
3. 抢拍是先抢先得
   1. 父亲先抢到，发个CANCEL事件给儿子就完了
   2. 儿子先抢到，就得大喊大叫，撒泼耍赖，爸爸们行行好吧，最后得以安心处理事件

另外有几个值得一提的地方：

1. 这种先抢先得的方式感受上有点乱来是吧，但目前也没有想到更好的办法了，通常都是开发者本身根据实际用户体验调整，让父亲或儿子在最适合的时机准确及时地抢到应得的事件
2. 父View在拦截下事件后，把接下来的事件传给本身的onTouch()后，onTouch()只会收到后半部分的事件，这样会不会有问题呢？
   1. 确实直接给后半部分会有问题，因此通常状况是，在没拦截的时候就作好若是要处理事件的一些准备工做，以便以后拦截事件了，只使用后半部分事件也能实现符合用户直觉的反馈

在「四造」的基础上，修改获得如下代码：

interface ViewParent {
    fun requestDisallowInterceptTouchEvent(isDisallowIntercept: Boolean)
}

open class MView {
    var parent: ViewParent? = null

    open fun dispatch(ev: MotionEvent): Boolean {
        return onTouch(ev)
    }

    open fun onTouch(ev: MotionEvent): Boolean {
        return false
    }
}

open class MViewGroup(private val child: MView) : MView(), ViewParent {
    private var isChildNeedEvent = false
    private var isSelfNeedEvent = false
    private var isDisallowIntercept = false

    init {
        child.parent = this
    }

    override fun dispatch(ev: MotionEvent): Boolean {
        var handled = false
        
        if (ev.actionMasked == MotionEvent.ACTION_DOWN) {
            clearStatus()
            
            // add isDisallowIntercept
            if (!isDisallowIntercept && onIntercept(ev)) {
                isSelfNeedEvent = true
                handled = onTouch(ev)
            } else {
                handled = child.dispatch(ev)
                if (handled) isChildNeedEvent = true

                if (!handled) {
                    handled = onTouch(ev)
                    if (handled) isSelfNeedEvent = true
                }
            }
        } else {
            if (isSelfNeedEvent) {
                handled = onTouch(ev)
            } else if (isChildNeedEvent) {
                // add isDisallowIntercept
                if (!isDisallowIntercept && onIntercept(ev)) {
                    isSelfNeedEvent = true

                    // add cancel
                    val cancel = MotionEvent.obtain(ev)
                    cancel.action = MotionEvent.ACTION_CANCEL
                    handled = child.dispatch(cancel)
                    cancel.recycle()
                } else {
                    handled = child.dispatch(ev)
                }
            }
        }
        
        if (ev.actionMasked == MotionEvent.ACTION_UP 
            || ev.actionMasked == MotionEvent.ACTION_CANCEL) {
            clearStatus()
        }
        
        return handled
    }
    
    private fun clearStatus() {
        isChildNeedEvent = false
        isSelfNeedEvent = false
        isDisallowIntercept = false
    }

    override fun onTouch(ev: MotionEvent): Boolean {
        return false
    }

    open fun onIntercept(ev: MotionEvent): Boolean {
        return false
    }

    override fun requestDisallowInterceptTouchEvent(isDisallowIntercept: Boolean) {
        this.isDisallowIntercept = isDisallowIntercept
        parent?.requestDisallowInterceptTouchEvent(isDisallowIntercept)
    }
}
复制代码

此次改动主要是增长了发出CANCEL事件和requestDisallowInterceptTouchEvent机制

1. 在发出CANCEL事件时有一个细节：没有在给 child 分发CANCEL事件的同时继续把原事件分发给本身的onTouch 2. 这是源码中的写法，不是我故意的，多是为了让一个事件也只能有一个View处理，避免出现bug
2. 实现requestDisallowInterceptTouchEvent机制时，增长了ViewParent接口
   1. 不使用这种写法也行，但使用它从代码整洁的角度看会更优雅，好比避免反向依赖，并且这也是源码的写法，因而直接搬来了

虽然目前整个框架的代码有点复杂，但对于使用者来讲，依然很是简单，只是在上一版框架的基础上增长了：

1. 若是View判断本身要消费事件，并且执行的是不但愿被父View打断的操做时，须要马上调用父View的requestDisallowInterceptTouchEvent()方法
2. 若是在onTouch方法中对事件消费而且作了一些操做，须要注意在收到CANCEL事件时，对操做进行取消

到这里，事件分发的主要逻辑已经讲清楚了，不过还差一段 Activity 中的处理，其实它作的事情相似ViewGroup，只有这几个区别：

1. 不会对事件进行拦截
2. 只要有子View没有处理的事件，它都会交给本身的onTouch()

因此很少讲了，直接补上Activity的麻雀：

open class MActivity(private val childGroup: MViewGroup) {
    private var isChildNeedEvent = false
    private var isSelfNeedEvent = false

    open fun dispatch(ev: MotionEvent): Boolean {
        var handled = false

        if (ev.actionMasked == MotionEvent.ACTION_DOWN) {
            clearStatus()

            handled = childGroup.dispatch(ev)
            if (handled) isChildNeedEvent = true

            if (!handled) {
                handled = onTouch(ev)
                if (handled) isSelfNeedEvent = true
            }
        } else {
            if (isSelfNeedEvent) {
                handled = onTouch(ev)
            } else if (isChildNeedEvent) {
                handled = childGroup.dispatch(ev)
            }

            if (!handled) handled = onTouch(ev)
        }

        if (ev.actionMasked == MotionEvent.ACTION_UP
            || ev.actionMasked == MotionEvent.ACTION_CANCEL) {
            clearStatus()
        }

        return handled
    }

    private fun clearStatus() {
        isChildNeedEvent = false
        isSelfNeedEvent = false
    }

    open fun onTouch(ev: MotionEvent): Boolean {
        return false
    }
}
复制代码

1.6. 总结

到这里，咱们终于造好了一个粗糙但不劣质的轮子，源码的主要逻辑与它的区别不大，具体区别大概有：TouchTarget机制、多点触控机制、NestedScrolling 机制、处理各类 listener、结合View的状态进行处理等，相比主要逻辑，它们就没有那么重要了，你们能够自行阅读源码，以后有空也会写关于多点触控和TouchTarget的内容 （挖坑预警）

轮子的完整代码能够在在这里查看（Java版本） 这个轮子把源码中与事件分发相关的内容剥离了出来，能看到：

1. 相比源码，这份代码足够短足够简单，那些跟事件分发无关的东西统统不要来干扰我
   1. 长度总共不超过150行，剔除了全部跟事件分发无关的代码，而且把一些由于其余细节致使写得比较复杂的逻辑，用更简单直接的方式表达了
2. 相比那段经典的事件分发伪代码（见附录），这份代码又足够详细，详细到能告诉你全部你须要知道的事件分发的具体细节
   1. 那段经典伪代码只能起到提纲挈领的做用，而这份麻雀代码虽然极其精简但它五脏俱全，全到能够直接跑 —— 你能够用它进行为伪布局，而后触发触摸事件

但轮子不是最重要的，最重要的是整个演化的过程。

因此回头看，你会发现事件分发其实很简单，它的关键不在于「不一样的事件类型、不一样的View种类、不一样的回调方法、方法不一样的返回值」对事件分发是怎么影响的。 关键在于 「它要实现什么功能？对实现效果有什么要求？使用了什么解决方案？」，从这个角度，就能清晰并且简单地把事件分发整个流程梳理清楚。

事件分发要实现的功能是：对用户的触摸操做进行反馈，使之符合用户的直觉。

从用户的直觉出发能获得这么两个要求：

1. 用户的一次操做只有一个View去消费
2. 让消费事件的View跟用户的意图一致

第二个要求是最难实现的，若是有多个View均可以消费触摸事件，怎么断定哪一个View更适合消费，而且把事件交给它。 咱们使用了一套简单但有效的先到先得策略，让内外的可消费事件的View拥有近乎平等的竞争消费者的资格：它们都能接收到事件，并在本身断定应该消费事件的时候去发起竞争申请，申请成功后事件就所有由它消费。

（转载请注明做者：RubiTree，地址：blog.rubitree.com ）

2. 测试轮子

可能有人会问，听你纸上谈兵了半天，你讲的真的跟源码同样吗，这要是不对我不是亏大了。 问的好，因此接下来我会使用一个测试事件分发的日志测试框架对这个小麻雀进行简单的测试，还会有实践部分真刀真枪地把上面讲过的东西练起来。

2.1. 测试框架

测试的思路是经过在每一个事件分发的钩子中打印日志来跟踪事件分发的过程。 因而就须要在不一样的 View 层级的不一样钩子中，针对不一样的触摸事件进行不一样的操做，以制造各类事件分发的场景。

为了减小重复代码简单搭建了一个测试框架（全部代码都能在此处查看），包括一个能够代理 View 中这些的操做的接口IDispatchDelegate及其实现类，和一个DispatchConfig统一进行不一样的场景的配置。 以后建立了使用统一配置和代理操做的 真实控件们SystemViews 和 咱们本身实现的麻雀控件们SparrowViews。

在DispatchConfig中配置好事件分发的策略后，直接启动SystemViews中的DelegatedActivity，进行触摸，使用关键字TouchDojo过滤，就能获得事件分发的跟踪日志。 同时，运行SparrowActivityTest中的dispatch()测试方法，也能获得麻雀控件的事件分发跟踪日志。

2.2. 测试过程

场景一

先配置策略，模拟View和ViewGroup都不消费事件的场景：

fun getActivityDispatchDelegate(layer: String = "Activity"): IDispatchDelegate {
    return DispatchDelegate(layer)
}

fun getViewGroupDispatchDelegate(layer: String = "ViewGroup"): IDispatchDelegate {
    return DispatchDelegate(layer)
}

fun getViewDispatchDelegate(layer: String = "View"): IDispatchDelegate {
    return DispatchDelegate(layer)
}
复制代码

能看到打印的事件分发跟踪日志：

[down]
|layer:SActivity |on:Dispatch_BE |type:down
|layer:SViewGroup |on:Dispatch_BE |type:down
|layer:SViewGroup |on:Intercept_BE |type:down
|layer:SViewGroup |on:Intercept_AF |result(super):false |type:down
|layer:SView |on:Dispatch_BE |type:down
|layer:SView |on:Touch_BE |type:down
|layer:SView |on:Touch_AF |result(super):false |type:down
|layer:SView |on:Dispatch_AF |result(super):false |type:down
|layer:SViewGroup |on:Touch_BE |type:down
|layer:SViewGroup |on:Touch_AF |result(super):false |type:down
|layer:SViewGroup |on:Dispatch_AF |result(super):false |type:down
|layer:SActivity |on:Touch_BE |type:down
|layer:SActivity |on:Touch_AF |result(super):false |type:down
|layer:SActivity |on:Dispatch_AF |result(super):false |type:down
 
[move]
|layer:SActivity |on:Dispatch_BE |type:move
|layer:SActivity |on:Touch_BE |type:move
|layer:SActivity |on:Touch_AF |result(super):false |type:move
|layer:SActivity |on:Dispatch_AF |result(super):false |type:move

[move]
...
 
[up]
|layer:SActivity |on:Dispatch_BE |type:up
|layer:SActivity |on:Touch_BE |type:up
|layer:SActivity |on:Touch_AF |result(super):false |type:up
|layer:SActivity |on:Dispatch_AF |result(super):false |type:up
复制代码

1. 由于系统控件和麻雀控件打印的日志如出一辙，因此只贴出一份
2. 这里用BE表明 before，表示该方法开始处理事件的时候，用AF表明after，表示该方法结束处理事件的时候，而且打印处理的结果
3. 从日志中能清楚看到，当View和ViewGroup都不消费DOWN事件时，后续事件将再也不传递给View和ViewGroup

场景二

再配置策略，模拟View和ViewGroup都消费事件，同时ViewGroup在第二个MOVE事件时认为本身须要拦截事件的场景：

fun getActivityDispatchDelegate(layer: String = "Activity"): IDispatchDelegate {
    return DispatchDelegate(layer)
}

fun getViewGroupDispatchDelegate(layer: String = "ViewGroup"): IDispatchDelegate {
    return DispatchDelegate(
        layer,
        ALL_SUPER,
        // 表示 onInterceptTouchEvent 方法中，DOWN 事件返回 false，第一个 MOVE 事件返回 false，第二个第三个 MOVE 事件返回 true
        EventsReturnStrategy(T_FALSE, arrayOf(T_FALSE, T_TRUE, T_TRUE), T_SUPER), 
        ALL_TRUE
    )
}

fun getViewDispatchDelegate(layer: String = "View"): IDispatchDelegate {
    return DispatchDelegate(layer, ALL_SUPER, ALL_SUPER, ALL_TRUE)
}
复制代码

能看到打印的事件分发跟踪日志：

[down]
|layer:SActivity |on:Dispatch_BE |type:down
|layer:SViewGroup |on:Dispatch_BE |type:down
|layer:SViewGroup |on:Intercept |result(false):false |type:down
|layer:SView |on:Dispatch_BE |type:down
|layer:SView |on:Touch |result(true):true |type:down
|layer:SView |on:Dispatch_AF |result(super):true |type:down
|layer:SViewGroup |on:Dispatch_AF |result(super):true |type:down
|layer:SActivity |on:Dispatch_AF |result(super):true |type:down
 
[move]
|layer:SActivity |on:Dispatch_BE |type:move
|layer:SViewGroup |on:Dispatch_BE |type:move
|layer:SViewGroup |on:Intercept |result(false):false |type:move
|layer:SView |on:Dispatch_BE |type:move
|layer:SView |on:Touch |result(true):true |type:move
|layer:SView |on:Dispatch_AF |result(super):true |type:move
|layer:SViewGroup |on:Dispatch_AF |result(super):true |type:move
|layer:SActivity |on:Dispatch_AF |result(super):true |type:move
 
[move]
|layer:SActivity |on:Dispatch_BE |type:move
|layer:SViewGroup |on:Dispatch_BE |type:move
|layer:SViewGroup |on:Intercept |result(true):true |type:move
|layer:SView |on:Dispatch_BE |type:cancel
|layer:SView |on:Touch_BE |type:cancel
|layer:SView |on:Touch_AF |result(super):false |type:cancel
|layer:SView |on:Dispatch_AF |result(super):false |type:cancel
|layer:SViewGroup |on:Dispatch_AF |result(super):false |type:move
|layer:SActivity |on:Touch_BE |type:move
|layer:SActivity |on:Touch_AF |result(super):false |type:move
|layer:SActivity |on:Dispatch_AF |result(super):false |type:move
 
[move]
|layer:SActivity |on:Dispatch_BE |type:move
|layer:SViewGroup |on:Dispatch_BE |type:move
|layer:SViewGroup |on:Touch |result(true):true |type:move
|layer:SViewGroup |on:Dispatch_AF |result(super):true |type:move
|layer:SActivity |on:Dispatch_AF |result(super):true |type:move
 
[up]
|layer:SActivity |on:Dispatch_BE |type:up
|layer:SViewGroup |on:Dispatch_BE |type:up
|layer:SViewGroup |on:Touch |result(true):true |type:up
|layer:SViewGroup |on:Dispatch_AF |result(super):true |type:up
|layer:SActivity |on:Dispatch_AF |result(super):true |type:up
复制代码

1. 一样由于系统控件和麻雀控件打印的日志如出一辙，因此只贴出一份
2. 从日志中能清楚看到，在ViewGroup拦截事件先后，事件是如何分发的

2.3. 测试结果

除了以上场景外，我也模拟了其余复杂的场景，能看到系统控件和麻雀控件打印的日志如出一辙，这就说明了麻雀控件中的事件分发逻辑，确实与系统源码是一致的。

并且从打印的日志中，能清晰地看到事件分发的轨迹，对理解事件分发过程也有很大的帮助。因此你们若是有须要，也能够直接使用这个框架像这样对触摸事件分发的各类状况进行调试。

3. 实践

实际上进行事件分发的实践时，会包括两方面内容：

1. 一方面是就是控制事件的分发。这也是本文讲的主要内容
2. 另外一方面是对事件的处理。核心内容是手势的识别，好比识别用户的操做是单击、双击、长按、滑动，这部分也能够本身手写，不会太难，但通常场景中咱们均可以使用SDK提供的十分好用的帮助类GestureDetector，它用起来很是方便

时间关系，这部分暂时直接去看另外一篇透镜《看穿 > NestedScrolling 机制》吧，它提供了过得去的实践场景。

（以为对你有帮助的话，不妨点个赞再走呀~ 给做者一点继续写下去的动力）

4. 附录

4.1.事件分发经典伪代码

public boolean dispatchTouchEvent(MotionEvent event) {
    boolean consume = false;
    if (onInterceptTouchEvent(event)) {
        consume = onTouchEvent(event);
    } else {
        consume = child.dispatchTouchEvent(event);
    }
    return consume;
}
复制代码