事件分发

• android事件处理的时候 会根据事件发生的坐标，从父容器一直慢慢的发送到相关的所有的view
• 因此当都不处理的时候 事件传递的流程图

dispatchTouchEvent返回true

• 但是如果我们在A的dispatchTouchEvent 中返回true，那么也就是事件不进行分发
  
  
• 发现只是调用了ViewGroupA事件的拦截方法，也就是没有将事件进行分发，连自己的onTouchEvent事件都没有进行处理
• 如果让ViewGroupB的dispatchEvent返回true呢？
  
  
• 当我们的view的dispatchTouchEvent返回true呢？现在我们可以推测了AdispatchTouchEvnet–>AonInterceptTouchEvent–>BdispatchTouchEvent–>BonInterceptTouchEvent–>CdispatchTouchEvent

onIntercaptTouchEvent返回true

• 当我们的ViewGroupA的onInterceptTouchEvent返回true的时候，也就是我们的ViewGroupA决定进行事件拦截
• 正如我们知道的，当对事件拦截之后直接进入自己view的touchEvent方法中处理，下图

• onInterceptTouchEvent方法，也是我们写自定义view的时候解决事件冲突的地方

• 当我们的ViewGroupB的onInterceptTouchEvent返回true呢？原理一样

• 当然，onIntercaptTouchEvent是viewGroup的方法，只有viewGroup才能决定事件是否拦截，而我们的view没有onInterceptTouchEvent方法

在onTouchEvent中返回true

• 我们知道返回true，是将事件由我们自己的view处理了，那么事件被消耗了的话，流程图有什么不同呢？
• 这里我们先让我们的view的onTouchEvent返回true

• 如果让我们的viewGroupB处理事件呢？我们也可以推测出来了
  

• 我们从打印的log可以看出来，当我们对事件进行拦截之后，下次的事件，直接交给了ViewGroupB处理，这个也是考虑了优化了

• 接下来我们将由我们的顶级控件，ViewGroupA来处理我们的事件响应，那么应该是什么效果呢？

• 结果我们可以想到，正常的流程还是会走，直到我们的ViewGroupA的onTouchEvent方法调用了，那么下次的事件也是直接交给处理事件的控件直接处理。

#

总的来说我们已经通过Log来详细的分析了事件的三个方法，现在大家应该很清晰时间流程了

• 总结
  
  • 当我们在dispatchTouchEvent中返回true的话，那么事件将不会分发
  • 如果我们调用了onInterceptTouchEvent返回true的话，那么事件将会拦截，交给拦截事件的view处理，会 调用onTouchEvent方法
  • 如果我们的onTouchEvent返回true的话，那么事件将会被消耗，下次的事件不会再向下传递，而是直接由处理的事件的控件拦截，之后交给刚才的控件处理相关事件
  • 一般我们自定义view的时候会在onIntercaptTouchEvent方法中处理事件冲突，来决定是否拦截事件
  • 而我们会在onTouchEvent中直接返回true，表示如果子控件不处理的话，那么我们的自定义view将会处理所有的事件
  • view没有onIntercaptTouchEvent方法