android触摸事件分发机制,曾困惑你我的地方

810 阅读3分钟

1.什么是事件分发

做过android乃至做过UI开发的IT从业者大都接触过这个名词,顾名思义,即一系列事件的分发,这里我们将细致的探讨下android端的触摸事件的分发机制。

2.为什么要“炒冷饭”

android事件分发,度娘上一抓一大把,为什么我还要写这篇博客?这是个好问题,我看过不少相关的博文,也看过相应书籍对“事件分发”的解释,但可能入门不久,之前一直没领悟透彻,一些文章也没让我细致的体悟到个钟缘由,疑问有:

  1. 为什么子view若是不在MotionEvent.ACTION_DOWN事件返回true的话,之后的所有事件都无法处理了?
  2. 为什么一旦view消耗了点击事件,那么之后的该系列事件就都由该view消耗了?
  3. 在2的基础上,为什么View#requestDisallowInterptTouchEvent(false)又能将事件的处理权交出去呢?

3.分析

我带着上面两个问题去翻看了ViewGroup#dispatchTouchEvent(MotionEvent ev)的源码。

首先看下部分源码:

这段代码,很显然是事件拦截onInterceptTouchEvent(ev)的触发条件,故而,途中2507和2508两行的条件是我们需要关注的重点,当触摸事件类型为ACTION_DOWN或者mFirstTouchTarget != null时会进入是否拦截的判断,这里注意如果不满足上述条件时,第2519行代码intercepted = true,也就是说如果不是down事件的同时,mFirstTouchTarget == null那么该次事件交由当前ViewGroup处理。那么重点来了,mFirstTouchTarget是什么?是如何赋值的?

接着看:

图中3-28行为接着上图的代码,这里不难看出,3-7行,当事件没取消不拦截的同时为MotionEvent.ACTION_DOWN,MotionEvent.ACTION_POINTER_DOWN, MotionEvent.ACTION_HOVER_MOVE事件的时候dispatchTransformedTouchEvent(ev, false, child, idBitsToAssign)将事件分发给子view处理,若是子view的处理结果返回true则进入8-28行的逻辑并会break跳出for循环,(敲黑板)重点来了,26行newTouchTarget = addTouchTarget(child, idBitsToAssign);进入addTouchTarget方法,即图中39-44行,至此mFirstTouchTarget的赋值我们理出来了。

那么有什么用呢?接着看循环外面的逻辑:

从之前的分析,我们得知,mFirstTouchTarget只有在存在子view消费了事件后,才会!=null,因此若是子view没有消耗事件,则进入2643行,当前view去处理该事件。并最终在函数末尾return handled

4 总结

至此可以对问题1,做出合理的解释了。当子view不消费MotionEvent.ACTION_DOWN事件的时候,那么在MotionEvent.ACTION_DOWN处理结束后mFirstTouchTarget是为null的,然后该系列事件的move等事件进入分发阶段的时候,便会在图一的2507和2508行的if校验中进入2519行intercepted = true始终拦截事件不再分发出去。至于问题2,问题3,其实也大都涵盖在上述分析中,聪明的小伙伴们,可以自行总结一波

推荐

亲情推荐使用阿里云服务器,实惠稳定 附赠优惠礼包自取: 阿里云飞机票

尾声

本人才疏学浅,若有不足,或是胡言乱语之处,望海涵并加以斧正。