换个角度描述Android事件传递,读完会让你耳目一新

6,989

前言

关于Android中事件传递机制早已是老生常谈的话题,甭管工作多久水平咋样应该都能道出一二。依稀记得刚接触事件分发那会,一股脑的钻进网络上那几张神图,什么三大方法、职责链,最后再巴拉巴拉贴一大堆源码(有的还贴错了),嗯,学完之后效果还挺不错,起码面试的时候能忽悠。关于只教是什么,不教为什么,鲁先生说过,这样是在耍流氓。今天我将换一种思路去描述事件分发,先带大家构建事件分发模型,讲述其设计背景职责边界,最后带着我们的猜测去源码中找答案。

目录

  • 1. 背景
    • 设计缘由
    • 事件传递流程
    • 滚动模型的设计
    • 滑动冲突的解决方案
  • 2. 源码解析
    • 事件传递
    • 事件拦截
    • 事件消费
  • 3. 综上所述

1. 背景

1.1 设计缘由

我们都知道,Android中界面中是由一个个ViewViewGroup组成,其中ViewGroupView是一对多的树型关系。

View树中,层级越深显示优先级越高,比如最内层View肯定会显示在父容器的上层,而我们的智能手机是可以跟用户的手指进行交互的,用户肯定希望所见即所得指哪并打哪。想要满足用户的需求,肯定要有一套完善的事件传递机制。

1.2 事件传递流程

首先我们要明确一个概念:所有的触摸事件都会到达ActivityActivity内部通过Window连接着一个View的根布局DecorView,事件会从Activity一层一层传递到最内层的View

基于上面的传递流程来分析一个实际问题,如下图所示,ViewGroup内部包含一个子View,二者都可点击,而用户希望指哪打哪,所以点击A处时需要ViewGroup响应,点击B处时需要View响应。但是当点击View时怎么保证ViewGroup不会响应?事情有点复杂。这时候我们需要借助一种设计思想递归

因为View的优先级是高的,所以当事件来临时ViewGroup先不做处理直接传递到子View,此过程为递归中的,当子View拿到事件后判断是否需要消费此事件,然后把消费结果传递给ViewGroupViewGroup拿到事件后判断是否已经被子View消费,如果已经被消费自己就没有权限处理这个事件了,否则做和子View相同的操作然后把结果传递给父View,这样逐层进行直到根布局,此过程为递归中的。用两张图做一下表示:

注意点

  • 一个View需要消费一组事件也即是自己来处理这组事件,并且一组事件只能被消费一次。
  • 一组触摸事件分为按下移动抬起,称之为一个事件序列,其中移动事件会有多个。当一个View决定自己消费一组事件需要在按下时就给出结果,反之如果在按下时决定消费意味着这一组事件序列均由自己消费。

1.3 滚动模型的设计

如果仅仅是处理点击事件用上面的方案没有任何问题,可是我们的屏幕还可以滑动啊,而且用户希望既可以点击又可以滑动。如果子View需要能点击,父View需要能滑动怎么办?因为一组事件只能被消费一次,如果子View消费了父View就没有权限处理了,所以基于上面的方案点击滑动只能二选其一,害...白忙活~~ 先别急着走,往下看...

首先事件必然是从ViewGroup流向View,所以主动权还是在ViewGroup,如果ViewGroup判断出事件在滚动,不管子View是否消费事件,直接把事件拦截然后自己进行消费,看似可行。可是仔细思考后会带来一系列问题,如下:

View在点击的时候可以设置点击背景,按下时背景设置为深色,抬起背景恢复正常,比如微信聊天列表的item。这种情况下如果ViewGroup直接拦截即便事件结束View的背景色始终无法恢复正常。其实引发的问题不止这一个,我们只需要知道这样做不行就可以了。

哎呀,这可如何是好... 硬刚不行能不能来一手曲线救国?接着上面的思路往下分析,假如ViewGroup在判断出要滑动时给子View发送一个特殊的事件(偷偷告诉你,其实就是CANCEL事件),子View收到这个特殊事件时把已经消费的事件作废,这样做是真的没啥问题了。不信接着看微信聊天列表,是不是按下有一个深色背景,一开始滑动就恢复正常了。

1.4 滑动冲突的解决方案

完美无瑕的外表下其实内心千疮百孔,你不会真的以为碰到滚动就拦截,这样就万事大吉了吧?少年你还是太年轻。如果ViewGroup和其父ViewGroup同时需要滚动呢?诶,好像不太对劲...

场景一

ViewPager嵌套ScrollView,当用户垂直方向滑ScrollView时滑着滑着滑歪了然后滑动就切换到了水平方向,这是非常有可能的,因为用户不可能玩手机时小心翼翼的搁那滑。按照1.3的方案这时会出现一点小问,用户:“本来我垂直方向滑的好好地,手指稍微一偏你就给我切换到水平滑动了,敏感过头了吧,我要换手机。”

其实这种问题很好解决,可惜面试的时候好多人都答不上来。ScrollView滚动时只需要给父View以及爷爷View发一个通知告诉他们:“我要开始滚动了,请不要拦截我”,OK,问题结局。

场景二

上面我们描述的是非同向滑动。关于同向滑动一直是一个比较难解决的问题,以至于Google花了三个版本的迭代才推出了一个相对稳定的NestedScrolling,这是基于事件分发扩展出来的一个专门用于解决滑动冲突的,关于NestedScrolling东西蛮多,感兴趣的同学可自行了解。

2. 源码解析

其实上一小节我已经把事件分发的原理描述的很清楚了,再去看事件分发源码应该会很轻松。另外读源码要懂得抽丝剥茧,如果非要把try catch之类的也要掰持清楚,那可有的折腾了。比如我们今天要阅读的事件分发源码,我会剥去大部分代码,只会找到关键一小部分,我们的目的是把原理搞明白。如果对其他部分代码也感兴趣可单独阅读。

关于前面提到的三大方法也就是传递拦截消费分别对应dispatchTouchEventonInterceptTouchEventonTouchEvent,其中onInterceptTouchEventViewGroup独有,相信大家应该都很清楚在这就不多做赘述了。

另外Activity在事件分发的过程中与ViewGroup充当的角色类似,就不单独描述了。

2.1 事件传递

ViewViewGroup中存在dispatchTouchEvent,其中ViewGroup对其进行了复写。

View 的 dispatchTouchEvent()

其实View在事件分发中做的事情很简单,基本可以用三行代码概括

 public boolean dispatchTouchEvent(MotionEvent event) {
 	return onTouchEvent(event)
 }

ViewdispatchTouchEvent方法本来就很短,把一些细节撇去基本和上面三行代码等价。

ViewGroup 的 dispatchTouchEvent()

关于事件分发的大部分细节都隐藏在ViewGroupdispatchTouchEvent中,所以没办法,我也要开始大篇幅贴代码了...

提示

关于TouchTarget:如果触摸的区域没有子View、子View不消费事件、子View收到了cancel事件,那么ViewGroup的mFirstTouchTarget会为null。弄清楚这个很重要,TouchTarget衔接了很多重要信息。

  public boolean dispatchTouchEvent(MotionEvent ev) {
        boolean handled = false;//声明消费结果
        final int action = ev.getAction();
        final int actionMasked = action & MotionEvent.ACTION_MASK;
        // 1
        if (actionMasked == MotionEvent.ACTION_DOWN) {
            //清理touchTarget
            cancelAndClearTouchTargets(ev);
            //清理上一次的事件序列,保证新事件序列的纯洁度
            resetTouchState();
        }
        ...
        ...
        // 2
        final boolean intercepted;//声明预拦截
        //ACTION_DOWN(第一次事件不能进行拦截,要给子View一次机会) || mFirstTouchTarget(触摸到了子View)不为空
        if (actionMasked == MotionEvent.ACTION_DOWN || mFirstTouchTarget != null) {
            //子View是否申请对其不拦截
            final boolean disallowIntercept = (mGroupFlags & FLAG_DISALLOW_INTERCEPT) != 0;
            //子View没有申请对其不拦截
            if (!disallowIntercept) {
                intercepted = onInterceptTouchEvent(ev);
                ev.setAction(action);
            } else {
                intercepted = false;
            }
        } else {
            intercepted = true;
        }
        ...
        //此处巴拉巴拉一大堆代码,其实就是对TouchTarget做处理。大概内容就是如果:触摸的区域没有子View、子View不消费事件、
        //子View收到了cancel事件(父View发的),这三个种条件满足任意一种父View的mFirstTouchTarget都会变为null。
        ...

        //3
        //如果给子View发送cancel事件后mFirstTouchTarget会变null,
        final boolean canceled = resetCancelNextUpFlag(this)||actionMasked == MotionEvent.ACTION_CANCEL;
        //mFirstTouchTarget == null等价于没有子View消费事件
        if (mFirstTouchTarget == null) {
            //没有TouchTarget,第三个参数直接传null。此处会间接调用自己的onTouchEvent
            handled = dispatchTransformedTouchEvent(ev, canceled, null,
                    ViewGroup.TouchTarget.ALL_POINTER_IDS);
        } else {
            ...
            //如果收到cancel事件 || 被拦截。
            final boolean cancelChild = resetCancelNextUpFlag(target.child)
                    || intercepted;
            if (dispatchTransformedTouchEvent(ev, cancelChild,
                    target.child, target.pointerIdBits)) {
                handled = true;
            }
        }
        return handled;
    }

作者花了很长时间才把300行的代码精简到60行,过滤掉的代码不是说没用,只是跟事件分发的流程关系不太大,全部贴出来只会给大家徒添困扰。我们读源码不就是为了搞清楚本质吗,所以不要为了读而读。

关于精简代码我也给分成了四部分(步骤见注释 //1,2,3),我们来逐步分析:

第一步:

首先在donw事件来临时执行了两个方法,cancelAndClearTouchTargets方法用于重置touchTargetresetTouchState方法用于重置上一次的事件序列,保证新的时间序列的纯洁度

第二步:

第二步用于做拦截处理。首先外层有两个判断条件,第二个条件意思是mFirstTouchTarget不为空,也就是子View要消费事件,而第一个意为在DOWN事件来临时先不拦截,给子View一个机会,因为DOWN事件来临时mFirstTouchTarget肯定时null。内部的逻辑大概就是,如果子view没有申请对它不拦截,就执行自己的onInterceptTouchEvent并把结果返回给intercepted

第三步:

关于第三步的代码,其实很长很长,内部巴拉巴拉一大堆,逻辑相当复杂,我精简掉的大部分代码也都是在这个步骤,为了不给大家徒添困扰,我是废了好大力气才提炼出这几行代码。总的来说就是执行dispatchTransformedTouchEvent来拿到事件的消费结果,调度子View的事件也是通过这个方法进行的。需要注意的一点:当ViewGroup确定拦截事件时不会立即执行,而是先将mFirstTouchTarget置为null,下一个事件到来时再自己处理。代码含义我在注释中已经写的很清楚,就不多做赘述。

下面来看一下dispatchTransformedTouchEvent这个方法的源码:


 //第二个参数cancel包含两种含义,一种是外部收到了取消事件,另一种是事件被拦截
    private boolean dispatchTransformedTouchEvent(MotionEvent event, boolean cancel,
                                                  View child, int desiredPointerIdBits) {
        final boolean handled;
        // 1
        //做取消事件的处理
        final int oldAction = event.getAction();
        if (cancel || oldAction == MotionEvent.ACTION_CANCEL) {
            event.setAction(MotionEvent.ACTION_CANCEL);
            //没有子view,自己执行super 也就是 View 的 dispatchTouchEvent 并将ACTION_CANCEL事件传递进去
            if (child == null) {
                handled = super.dispatchTouchEvent(event);
            } else {
                //将cancel事件传递给子View。下一个事件传递时父View的TouchTarget会变为null
                handled = child.dispatchTouchEvent(event);
            }
            event.setAction(oldAction);
            return handled;
        }
        ...
        ...
        // 2
        // 没有子View 执行View 的 dispatchTouchEvent 也就是执行自己的onTouchEvent
        if (child == null) {//基本等价于TouchTarget为null
            handled = super.dispatchTouchEvent(transformedEvent);
        } else {
            ...
            //拿到子 View 的 dispatchTouchEvent 的返回值(也即是消费结果)
            handled = child.dispatchTouchEvent(transformedEvent);
        }

        return handled;
    }

关于这个方法的源码我没怎么剪,实际上跟这个长得基本也差不多。我把它分成了两部分:

第一步:

当事件为cancel类型时,如果TouchTargetnull,自己执行super 也就是 ViewdispatchTouchEvent方法,并将cancel事件传递进去做重置操作,否则就执行子ViewdispatchTouchEvent并将cancel事件传递进去。

第二步

这部分才真正进入到了对子View的调度,也是在此处拿到事件的消费结果,逻辑跟第一部分类似,注释也写的很清楚,就不多做赘述。

2.2 事件拦截

ViewGroup 的 onInterceptTouchEvent

因为ViewGroup默认是不具备滑动功能的,所以内部的拦截方法基本啥也没做。没骗你,不信你看源码:

 public boolean onInterceptTouchEvent(MotionEvent ev) {
        if (ev.isFromSource(InputDevice.SOURCE_MOUSE)
                && ev.getAction() == MotionEvent.ACTION_DOWN
                && ev.isButtonPressed(MotionEvent.BUTTON_PRIMARY)
                && isOnScrollbarThumb(ev.getX(), ev.getY())) {
            return true;
        }
        return false;
    }

如果一个ViewGroup需要滚动必须得重写这个方法(不考虑NestedScrolling的前提下),如果检查到事件在滚动就返回true并将事件交给自己的onTouchEvent处理,在内部实现具体的操作即可。如果做滑动的ViewGroup,需要在合适的时机调用父ViewrequestDisallowInterceptTouchEvent通知父View不要拦截事件

2.3 事件消费

View 的 onTouchEvent

onTouchEvent其实是为了符合单一设计原则设计出来的一个钩子方法,专门用于处理触摸事件反馈,如果具备触摸的View都必须对其重写。默认情况下的onTouchEvent内部有很多小细节,比如注册了点击事件会返回true预按下处理波纹效果等等,跟事件分发的流程关系不太大,就不在本篇文章做描述,如果大家感兴趣我可以单独写一篇文章专门讲解onTouchEvent的内部细节

3. 综上所述

  • 为了提升用户体验,不得不设计一套完善的事件传递机制
  • 通过递归设计思想,提升内层View处理事件的优先级
  • ViewGroup可通过拦截事件来处理滑动
  • 通过调用父ViewrequestDisallowInterceptTouchEvent来解决滑动冲突