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

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. 假设还没有触摸事件的概念，我们要怎么区分一次触摸操作呢？

2. 把触摸操作细分一下，大概有按下动作、抬起动作、与屏幕接触时的移动和停留动作

3. 很容易想到，要区分两次触摸操作，可以通过按下和抬起动作进行区分，按下动作开始了一次触摸操作，抬起动作结束了一次触摸，按下和抬起中间的移动和停留都属于这一次触摸操作，至于移动和停留是否要区分，目前没有看到区分的必要，可以都作为触摸中来处理

4. 于是在一次触摸操作中就有了三种动作的类型：DOWN/UP/ING，其中ING有点不够专业，改个名字叫MOVE吧

5. 而每个触摸动作会在软件系统中产生一个同样类型的触摸事件

6. 所以最后，一次触摸操作就是由一组从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 包裹？是的话自己就不消费事件了？

2. 这肯定是不行的，先不说子 View 层层反向遍历父亲是不是个好实现，至少不能外面是可以滑动的，里边 View 的点击事件就全部失效

3. 或者我们调整dispatch()方法在传入事件过程中的人设，让它不是只能往里传递事件，而是在自己能消费事件的时候把事件给自己

4. 这肯定也是不行的，跟第一个办法的主要问题一样

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

1. 当用户面对一个滑动 View 里有一个可点击 View，当他摸在可点击 View 上时，他是要做什么？

2. 显然，只有两个可能性，要么用户想点这个可点击 View，要么用户想滑动这个可滑动 View

3. 那么，当用户刚用手指接触的时候，也就是DOWN事件刚来的时候，能判断用户想干什么吗？很抱歉，不能

4. 所以，客观条件下，你就是不可能在DOWN事件传过来的时候，判断出用户到底想做什么，于是两个 View 其实都不能确定自己是否要消费事件

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

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

1. 办法肯定是有的，你可以多等一会，看用户接下来的行为能匹配哪种操作模式

2. 点击操作的模式是这样：用户先DOWN，然后MOVE很小一段，也不会 MOVE 出这个子 View，关键是比较短的时间就UP
   

3. 滑动操作的模式是这样：用户先DOWN，然后开始MOVE，这时候可能会 MOVE 出这个子 View，也可能不，但关键是比较长的时间也没有在UP，一直是在MOVE
   

4. 所以你的结论是，只有DOWN不行，还得看接下来的事件流，得走着瞧

5. 再多考虑个长按的情况，总结就是：

6. 如果在某个时间内UP，就是点击里边的 View

7. 如果比较长的时间UP，但没怎么MOVE，就是长按里边的 View

8. 如果在比较短的时间MOVE比较长的距离，就是滑动外面的 View

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

1. 因为子 View 和父 View 都无法在DOWN的时候判断当前事件流是不是该给自己，所以一开始它们都只能返回false。但为了能对后续事件做判断，你希望事件继续流过它们，按照当前框架的逻辑，你又不能返回false。

2. 假设事件会流过它们，当事件流了一会儿后，父 View 判断出这符合自己的消费模式啊，于是想把事件给自己消费，但此时子 View 可能已经在消费事件了，而目前的框架是做不到阻止子 View 继续消费事件的

所以要解决上述的冲突，就肯定要对上一版的事件处理框架进行修改，而且看上去一不小心就会大改

1. 首先看第二个冲突，解决它的一个直接方案是：调整 dispatch() 方法在传入事件过程中的人设，让它不是只传递事件了，还可以在往里传递事件前进行拦截，能够看情况拦截下事件并交给自己的 onTouch() 处理

2. 基于这个解决方案，大概有以下两个改动相对小的方案调整思路：

3. 思路一：

4. 当事件走到可滑动父 View 的时候，它先拦截并处理事件，而且还把事件给攒着

5. 当经过了几个事件

6. 如果判断出符合自己的消费模式，那就直接开始自己消费了，也不用继续攒事件了

7. 如果判断出不是自己的消费模式，再把所有攒着的事件一股脑给子 View，触发里边的点击操作

8. 思路二：

9. 所有的 View 只要可能消费事件，就在onTouch()里对DOWN事件返回true，不管是否识别出当前属于自己的消费模式

10. 当事件走到到可滑动父 View 的时候，它先把事件往里传，里边可能会处理事件，可能不会，可滑动父 View 都暂时不关心

11. 然后看子 View 是否处理事件

12. 假如子 View 不处理事件，那啥问题没有，父 View 直接处理事件就好了

13. 假如子 View 处理事件，可滑动父 View 就会绷紧神经暗中观察伺机而动，观察事件是不是符合自己的消费模式，一旦发现符合，它就把事件流拦截下来，即使子 View 也在处理事件，它也不往里disptach事件了，而是直接给自己的onTouch()
    

14. 两个思路总结一下：

15. 思路一：外面的父 View 先拦事件，如果判断拦错了，再把事件往里发

16. 思路二：外面的父 View 先不拦事件，在判断应该拦的时候，突然把事件拦下来

17. 这两个思路都要对当前框架做改变，看似差不多，但其实还是有比较明显的优劣的

18. 思路一问题比较明显：

19. 父 View 把事件拦下来了，然后发现拦错了再给子 View，但其实子 View 又并不一定能消费事件，这不就是白做一步吗。等到子 View 不处理事件，又把事件们还给父 View，父 View 还得继续处理事件。整个过程不仅繁琐，而且会让开发者感觉到别扭

20. 所以这个思路不太行，还得是把事件先给子 View

21. 思路二就相对正常多了，只有一个问题（下一节再讲，你可以猜一猜，这里我先当没发现），而且框架要做的改变也很少：

22. 增加一个拦截方法onIntercept()在父 View 往里dispatch事件前，开发者可以覆写这个方法，加入自己的事件模式分析代码，并且可以在确定要拦截的时候进行拦截

23. 把分析拦截逻辑抽成一个方法非常合理：什么时候拦，什么时候不拦，内里的逻辑很多，但对外暴露的 API 可以很小，非常适合抽出去

24. 在确定自己要拦截事件的时候，即使里边在一开始消费了事件，也不把事件往里传了，而是直接给自己的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 = falseprivate var isSelfNeedEvent = false

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

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

if (onIntercept(ev)) {isSelfNeedEvent = truehandled = 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 = truehandled = onTouch(ev)} else {handled = child.dispatch(ev)}}}

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

return handled}

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

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

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

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

1. 不仅是在DOWN事件的dispatch()前需要拦截，在后续事件中，也需要加入拦截，否则无法实现中途拦截的目标

2. 在某一个事件判断拦截之后，还需要在后续事件中再判断一次是否要拦截吗？

3. 完全不需要，我们希望的就是在一次触摸中，尽可能只有 1 个对象去消费事件，决定是你了，那就不要变

4. 所以增加一个isSelfNeedEvent记录自己是否拦截过事件，如果拦截过，后续事件直接就交给自己处理

5. 在后续事件时，子 View 没有处理事件，外面也不会再处理了，同样因为只能有一个 View 处理（Actvity 会处理这样的事件，后面会提到）

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

而且对于框架的使用者来说，关注点还是非常少

1. 重写onIntercept()方法，判断什么时候需要拦截事件，需要拦截时返回true
   

2. 重写onTouch()方法，如果处理了事件，返回true
   

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

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

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

1. 里边的 View 接收了一半事件，但还没有真正开始反馈交互，或者在进行可以被取消的反馈

2. 比如对于一个可点击的 View，View 的默认实现是只要被 touch 了，就会有pressed状态，如果你设置了对应的background，你的 View 就会有高亮效果

3. 这种高亮即使被中断也没事，不会让用户感觉到奇怪，不信你自己试试微信的聊天列表

4. 但一个值得注意的点是，如果你只是直接不发送MOVE事件了，这会有问题，就这个按下高亮的例子，如果你只是不传MOVE事件了，那谁来告诉里边的子 View 取消高亮呢？所以你需要在中断的时候也传一个结束事件

5. 但是，你能直接传一个UP事件吗？也是不行的，因为这样就匹配了里边点击的模式了，会直接触发一个点击事件，这显然不是我们想要的

6. 于是外面需要给一个新的事件，这个事件的类型就叫取消事件好了CANCEL
   

7. 总结一下，对于这种简单的可被取消情况，你可以这样去处理：

8. 在确定要拦截的时候，在把真正的事件转发给自己的onTouch()的同时，另

《Android学习笔记总结+最新移动架构视频+大厂安卓面试真题+项目实战源码讲义》
浏览器打开：qq.cn.hn/FTe 免费领取

外生成一个新的事件发给自己的子 View，事件类型是CANCEL，它将是子 View 收到的最后一个事件 2. 子 View 可以在收到这个事件后，对当前的一些行为进行取消 2. 里边的 View 接收了一半事件，已经开始反馈交互了，这种反馈最好不要去取消它，或者说取消了会显得很怪

1. 这个时候，事情会复杂一些，而且这个场景发生的远比你想象中的多，形式也多种多样，不处理好的后果也比只是让用户感觉上奇怪要严重得多，可能会有的功能会实现不了，下面举两个例子

2. 在ViewPager里有三个 page，page 里是ScrollView，ViewPager可以横向滑动，page 里的ScrollView可以竖向滑动

3. 如果按前面逻辑，当ViewPager把事件给里边ScrollView之后，它也会偷偷观察，如果你一直是竖向滑动，那没话说，ViewPager不会触发拦截事件

4. 但如果你竖着滑着滑着，手抖了，开始横滑（或者只是斜滑），ViewPager就会开始紧张，想「组织终于决定是我了吗？真的假的，那我可就不客气了」，于是在你斜滑一定距离之后，忽然发现，你划不动ScrollView了，而ViewPager开始动

5. 原因就是ScrollView的竖滑被取消了，ViewPager把事件拦下来，开始横滑

6. 这个体验还是比较怪的，会有种过于灵敏的感觉，会让用户只能小心翼翼地滑动

7. 在一个ScrollView里有一些按钮，按钮有长按事件，长按再拖动就可以移动按钮

8. （更常见的例子是一个列表，里边的条目可以长按拖动）

9. 同样按前面的逻辑，当你长按后准备拖动按钮时，你怎么保证不让ScrollView把事件拦下来呢？

10. 所以这类问题是一定要解决的，但要怎么解决呢

11. 还是先从业务上看，从用户的角度看，当里边已经开始做一些特殊处理了，外面应不应该把事件抢走？

12. 不应该对吧，OK，解决方针就是不应该让外边的 View 抢事件

13. 所以接下来的问题是：谁先判断出外边的 View 不该抢事件，里边的子 View 还是外边的父 View？然后怎么不让外边的 View 抢？

14. 首先，肯定是里边的 View 做出判断：这个事件，真的，外边的 View 你最好别抢，要不用户不开心了

15. 然后里边就得告知外边，你别抢了，告知可以有几个方式

16. 外边抢之前问一下里边，我能不能抢

17. 里边在确定这个事件不能被抢之后，从dispatch方法返回一个特别的值给外边（之前只是true和false，现在要加一个）

18. 里边通过别的方式通知外边，你不要抢

19. 讲道理，我觉得三个方式都行，但第三个方式最为简单直接，而且对框架没有过大的改动，Android 也使用了这个方式，父 View 给子 View 提供了一个方法requestDisallowInterceptTouchEvent()，子 View 调用它改变父 View 的一个状态，同时父 View 每次在准备拦截前都会判断这个状态（当然这个状态只对当前事件流有效）

20. 然后，这个情况还得再注意一点，它应该是向上递归的，也就是，在复杂的情况中，有可能有多个上级在暗中观察，当里边的 View 决定要处理事件而且不准备交出去的时候，外面所有的暗中观察的父 View 都应该把脑袋转回去

所以，连同上一次试造，总结一下

1. 对于多个可消费事件的 View 进行嵌套的情况，怎么判定事件的归属会变得非常麻烦，无法立刻在DOWN事件时就确定，只能在后续的事件流中进一步判断

2. 于是在没判断归属的时候，先由里边的子 View 消费事件，外面暗中观察，同时两方一块对事件类型做进一步匹配，并准备在匹配成功后对事件流的归属进行抢拍

3. 抢拍是先抢先得

4. 父亲先抢到，发个CANCEL事件给儿子就完了

5. 儿子先抢到，就得大喊大叫，撒泼耍赖，爸爸们行行好吧，最后得以安心处理事件

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

1. 这种先抢先得的方式感觉上有点乱来是吧，但目前也没有想到更好的办法了，一般都是开发者自己根据实际用户体验调整，让父亲或儿子在最适合的时机准确及时地抢到应得的事件

2. 父 View 在拦截下事件后，把接下来的事件传给自己的onTouch()后，onTouch()只会收到后半部分的事件，这样会不会有问题呢？

3. 确实直接给后半部分会有问题，所以一般情况是，在没拦截的时候就做好如果要处理事件的一些准备工作，以便之后拦截事件了，只使用后半部分事件也能实现符合用户直觉的反馈

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

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 = falseprivate var isSelfNeedEvent = falseprivate var isDisallowIntercept = false

init {child.parent = this}

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

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

// add isDisallowInterceptif (!isDisallowIntercept && onIntercept(ev)) {isSelfNeedEvent = truehandled = 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 isDisallowInterceptif (!isDisallowIntercept && onIntercept(ev)) {isSelfNeedEvent = true

// add cancelval cancel = MotionEvent.obtain(ev)cancel.action = MotionEvent.ACTION_CANCELhandled = 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 = falseisSelfNeedEvent = falseisDisallowIntercept = false}

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

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

override fun requestDisallowInterceptTouchEvent(isDisallowIntercept: Boolean) {this.isDisallowIntercept = isDisallowInterceptparent?.requestDisallowInterceptTouchEvent(isDisallowIntercept)}}

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

1. 在发出CANCEL事件时有一个细节：没有在给 child 分发CANCEL事件的同时继续把原事件分发给自己的onTouch 2. 这是源码中的写法，不是我故意的，可能是为了让一个事件也只能有一个 View 处理，避免出现 bug

2. 实现requestDisallowInterceptTouchEvent机制时，增加了ViewParent接口

3. 不使用这种写法也行，但使用它从代码整洁的角度看会更优雅，比如避免反向依赖，而且这也是源码的写法，于是直接搬来了

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

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 = falseprivate 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 = falseisSelfNeedEvent = false}

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

1.6. 总结

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

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

1. 相比源码，这份代码足够短足够简单，那些跟事件分发无关的东西通通不要来干扰我

2. 长度总共不超过 150 行，剔除了所有跟事件分发无关的代码，并且把一些因为其他细节导致写得比较复杂的逻辑，用更简单直接的方式表达了

3. 相比那段经典的事件分发伪代码（见附录），这份代码又足够详细，详细到能告诉你所有你需要知道的事件分发的具体细节

4. 那段经典伪代码只能起到提纲挈领的作用，而这份麻雀代码虽然极其精简但它五脏俱全，全到可以直接跑 —— 你可以用它进行为伪布局，然后触发触摸事件

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

所以回头看，你会发现事件分发其实很简单，它的关键不在于「不同的事件类型、不同的 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)