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

（黄色高亮 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. 很容易理解，正常情况下人只会想一次就做一件事
3. 比如一个列表条目，列表可以点击进入详情，列表上还有个编辑按钮，点击可以编辑条目
4. 这是一个上下两个View都能点击的场景，但用户点一个地方，肯定只想去做一件事，要么进入详情，要么是编辑条目，如果你点编辑结果跳了两个页面，那肯定是不合适的
5. 再比如在一个可点击Item组成的列表里（比如微信的消息界面），Item可以点击进入某个聊天，列表还能滑动上下查看
6. 如果你让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. 你会发现，这其中包含了两类职责：
3. 一类是事件传递控制逻辑，另一类是事件处理钩子
4. 其中事件传递控制逻辑基本不会变化，但事件处理的钩子中可能做任何事情
5. 我们需要把不同职责的代码分开，更需要把变化的和不变的分开，减少框架使用者的关注点

于是我们用一个叫做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. 假设还没有触摸事件的概念，我们要怎么区分一次触摸操作呢？
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 = 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. 在某一个事件判断拦截之后，还需要在后续事件中再判断一次是否要拦截吗？
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()的同时，另外生成一个新的事件发给自己的子View，事件类型是CANCEL，它将是子View收到的最后一个事件
9. 子View可以在收到这个事件后，对当前的一些行为进行取消
10. 里边的View接收了一半事件，已经开始反馈交互了，这种反馈最好不要去取消它，或者说取消了会显得很怪
11. 这个时候，事情会复杂一些，而且这个场景发生的远比你想象中的多，形式也多种多样，不处理好的后果也比只是让用户感觉上奇怪要严重得多，可能会有的功能会实现不了，下面举两个例子
12. 在ViewPager里有三个page，page里是ScrollView，ViewPager可以横向滑动，page里的ScrollView可以竖向滑动
13. 如果按前面逻辑，当ViewPager把事件给里边ScrollView之后，它也会偷偷观察，如果你一直是竖向滑动，那没话说，ViewPager不会触发拦截事件
14. 但如果你竖着滑着滑着，手抖了，开始横滑（或者只是斜滑），ViewPager就会开始紧张，想「组织终于决定是我了吗？真的假的，那我可就不客气了」，于是在你斜滑一定距离之后，忽然发现，你划不动ScrollView了，而ViewPager开始动
15. 原因就是ScrollView的竖滑被取消了，ViewPager把事件拦下来，开始横滑
16. 这个体验还是比较怪的，会有种过于灵敏的感觉，会让用户只能小心翼翼地滑动
17. 在一个ScrollView里有一些按钮，按钮有长按事件，长按再拖动就可以移动按钮
18. （更常见的例子是一个列表，里边的条目可以长按拖动）
19. 同样按前面的逻辑，当你长按后准备拖动按钮时，你怎么保证不让ScrollView把事件拦下来呢？
20. 所以这类问题是一定要解决的，但要怎么解决呢
21. 还是先从业务上看，从用户的角度看，当里边已经开始做一些特殊处理了，外面应不应该把事件抢走？
22. 不应该对吧，OK，解决方针就是不应该让外边的View抢事件
23. 所以接下来的问题是：谁先判断出外边的View不该抢事件，里边的子View还是外边的父View？然后怎么不让外边的View抢？
24. 首先，肯定是里边的View做出判断：这个事件，真的，外边的View你最好别抢，要不用户不开心了
25. 然后里边就得告知外边，你别抢了，告知可以有几个方式
26. 外边抢之前问一下里边，我能不能抢
27. 里边在确定这个事件不能被抢之后，从dispatch方法返回一个特别的值给外边（之前只是true和false，现在要加一个）
28. 里边通过别的方式通知外边，你不要抢
29. 讲道理，我觉得三个方式都行，但第三个方式最为简单直接，而且对框架没有过大的改动，Android也使用了这个方式，父View给子View提供了一个方法requestDisallowInterceptTouchEvent()，子View调用它改变父View的一个状态，同时父View每次在准备拦截前都会判断这个状态（当然这个状态只对当前事件流有效）
30. 然后，这个情况还得再注意一点，它应该是向上递归的，也就是，在复杂的情况中，有可能有多个上级在暗中观察，当里边的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 = 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接口
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 = 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()
}

最后

今天关于面试的分享就到这里，还是那句话，有些东西你不仅要懂，而且要能够很好地表达出来，能够让面试官认可你的理解，例如Handler机制，这个是面试必问之题。有些晦涩的点，或许它只活在面试当中，实际工作当中你压根不会用到它，但是你要知道它是什么东西。

最后在这里小编分享一份自己收录整理上述技术体系图相关的几十套腾讯、头条、阿里、美团等公司2021年的面试题，把技术点整理成了视频和PDF（实际上比预期多花了不少精力），包含知识脉络 + 诸多细节，由于篇幅有限，这里以图片的形式给大家展示一部分。

还有 高级架构技术进阶脑图、Android开发面试专题资料，高级进阶架构资料 帮助大家学习提升进阶，也节省大家在网上搜索资料的时间来学习，也可以分享给身边好友一起学习。

【Android核心高级技术PDF文档，BAT大厂面试真题解析】

【算法合集】

【延伸Android必备知识点】

【Android部分高级架构视频学习资源】

Android精讲视频领取学习后更加是如虎添翼！进军BATJ大厂等（备战）！现在都说互联网寒冬，其实无非就是你上错了车，且穿的少（技能），要是你上对车，自身技术能力够强，公司换掉的代价大，怎么可能会被裁掉，都是淘汰末端的业务Curd而已！现如今市场上初级程序员泛滥，这套教程针对Android开发工程师1-6年的人员、正处于瓶颈期，想要年后突破自己涨薪的，进阶Android中高级、架构师对你更是如鱼得水，赶快领取吧！
《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》，点击传送门，即可获取！
进阶，也节省大家在网上搜索资料的时间来学习，也可以分享给身边好友一起学习。

【Android核心高级技术PDF文档，BAT大厂面试真题解析】

[外链图片转存中…(img-YDnZYVw8-1715162844111)]

【算法合集】

[外链图片转存中…(img-egB31npA-1715162844111)]

【延伸Android必备知识点】

[外链图片转存中…(img-0rwIl2Fd-1715162844112)]

【Android部分高级架构视频学习资源】

Android精讲视频领取学习后更加是如虎添翼！进军BATJ大厂等（备战）！现在都说互联网寒冬，其实无非就是你上错了车，且穿的少（技能），要是你上对车，自身技术能力够强，公司换掉的代价大，怎么可能会被裁掉，都是淘汰末端的业务Curd而已！现如今市场上初级程序员泛滥，这套教程针对Android开发工程师1-6年的人员、正处于瓶颈期，想要年后突破自己涨薪的，进阶Android中高级、架构师对你更是如鱼得水，赶快领取吧！
《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》，点击传送门，即可获取！