安卓自定义 View 进阶:事件分发机制原理

事件分发机制原理

之前讲解了很多与View绘图相关的知识,你可以在 安卓自定义View教程目录 中查看到这些文章,如果你理解了这些文章,那么至少2D绘图部分不是难题了,大部分的需求都能满足,但是关于View还有很多知识点,例如: 让绘图更加炫酷的Paint让View动起来的动画与用户交互的触控事件 等一系列内容。本次就带大家简单的了解一下与交互息息相关的东西-事件分发原理

本次魔法小火车的终点站是事件分发,请各位魔法师带好装备,准备登车启程。

注意:本文中所有源码分析部分均基于 API23(Android 6.0) 版本,由于安卓系统源码改变很多,可能与之前版本有所不同,但基本流程都是一致的。

为什么要有事件分发机制?

安卓上面的View是树形结构的,View可能会重叠在一起,当我们点击的地方有多个View都可以响应的时候,这个点击事件应该给谁呢?为了解决这一个问题,就有了事件分发机制。

如下图,View是一层一层嵌套的,当手指点击 View1 的时候,下面的ViewGroupARootView 等也是能够响应的,为了确定到底应该是哪个View处理这次点击事件,就需要事件分发机制来帮忙。

View的结构:

我们的View是树形结构的,在上一个问题中实例View的结构大致如下:

layout文件:

  • <com.gcssloop.touchevent.test.RootView
  • xmlns:android="http://schemas.android.com/apk/res/android"
  • xmlns:tools="http://schemas.android.com/tools"
  • android:layout_width="match_parent"
  • android:layout_height="300dp"
  • android:background="#4E5268"
  • android:layout_margin="20dp"
  • tools:context="com.gcssloop.touchevent.MainActivity">
  • <com.gcssloop.touchevent.test.ViewGroupA
  • android:background="#95C3FA"
  • android:layout_width="200dp"
  • android:layout_height="200dp">
  • <com.gcssloop.touchevent.test.View1
  • android:background="#BDDA66"
  • android:layout_width="130dp"
  • android:layout_height="130dp"/>
  • </com.gcssloop.touchevent.test.ViewGroupA>
  • <com.gcssloop.touchevent.test.View2
  • android:layout_alignParentRight="true"
  • android:background="#BDDA66"
  • android:layout_width="80dp"
  • android:layout_height="80dp"/>
  • </com.gcssloop.touchevent.test.RootView>

View结构:

可以看到在上面的View结构中莫名多出来的两个东西,PhoneWindowDecorView ,这两个我们并没有在Layout文件中定义过,但是为什么会存在呢?

仔细观察上面的 layout 文件,你会发现一个问题,我在 layout 文件中的最顶层 View(Group) 的大小并不是填满父窗体的,留下了大量的空白区域,由于我们的手机屏幕不能透明,所以这些空白区域肯定要显示一些东西,那么应该显示什么呢?

有过安卓开发经验的都知道,屏幕上没有View遮挡的部分会显示主题的颜色。不仅如此,最上面的一个标题栏也没有在 layout 文件中,这个标题栏又是显示在哪里的呢?

你没有猜错,这个主题颜色和标题栏等内容就是显示在DecorView中的。

现在知道 DecorView 是干什么的了,那么PhoneWindow 又有什么作用?

要了解 PhoneWindow 是干啥的,首先要了解啥是 Window ,看官方说明:

Abstract base class for a top-level window look and behavior policy. An instance of this class should be used as the top-level view added to the window manager. It provides standard UI policies such as a background, title area, default key processing, etc.

简单来说,Window是一个抽象类,是所有视图的最顶层容器,视图的外观和行为都归他管,不论是背景显示,标题栏还是事件处理都是他管理的范畴,它其实就像是View界的太上皇(虽然能管的事情看似很多,但是没实权,因为抽象类不能直接使用)。

而 PhoneWindow 作为 Window 的唯一亲儿子(唯一实现类),自然就是 View 界的皇帝了,PhoneWindow 的权利可是非常大大,不过对于我们来说用处并不大,因为皇帝平时都是躲在深宫里面的,虽然偶尔用特殊方法能见上一面,但想要完全指挥 PhoneWindow 为你工作是很困难的。

而上面说的 DecorView 是 PhoneWindow 的一个内部类,其职位相当于小太监,就是跟在 PhoneWindow 身边专业为 PhoneWindow 服务的,除了自己要干活之外,也负责消息的传递,PhoneWindow 的指示通过 DecorView 传递给下面的 View,而下面 View 的信息也通过 DecorView 回传给 PhoneWindow。

事件分发、拦截与消费

下表省略了 PhoneWidow 和 DecorView。

表示有该方法。
X 表示没有该方法。

类型 相关方法 Activity ViewGroup View
事件分发 dispatchTouchEvent
事件拦截 onInterceptTouchEvent X X
事件消费 onTouchEvent

这个三个方法均有一个 boolean(布尔) 类型的返回值,通过返回 true 和 false 来控制事件传递的流程。

PS: 从上表可以看到 Activity 和 View 都是没有事件拦截的,这是因为:

Activity 作为原始的事件分发者,如果 Activity 拦截了事件会导致整个屏幕都无法响应事件,这肯定不是我们想要的效果。

View最为事件传递的最末端,要么消费掉事件,要么不处理进行回传,根本没必要进行事件拦截。

事件分发流程

前面我们了解到了我们的View是树形结构的,基于这样的结构,我们的事件可以进行有序的分发。

事件收集之后最先传递给 Activity, 然后依次向下传递,大致如下:

  • Activity -> PhoneWindow -> DecorView -> ViewGroup -> ... -> View

这样的事件分发机制逻辑非常清晰,可是,你是否注意到一个问题?如果最后分发到View,如果这个View也没有处理事件怎么办,就这样让事件浪费掉?

当然不会啦,如果没有任何View消费掉事件,那么这个事件会按照反方向回传,最终传回给Activity,如果最后 Activity 也没有处理,本次事件才会被抛弃:

  • Activity <- PhoneWindow <- DecorView <- ViewGroup <- ... <- View

看到这里,我不禁微微一皱眉,这个东西咋看起来那么熟悉呢?再仔细一看,这不就是一个非常经典的责任链模式吗, 如果我能处理就拦截下来自己干,如果自己不能处理或者不确定就交给责任链中下一个对象。

这种设计是非常精巧的,上层View既可以直接拦截该事件,自己处理,也可以先询问(分发给)子View,如果子View需要就交给子View处理,如果子View不需要还能继续交给上层View处理。既保证了事件的有序性,又非常的灵活。在我第一次将这个逻辑弄清楚的时候,看着这样精妙的设计,简直想欢呼庆贺一下。

其实关于事件传递机制,吴小龙的 Android事件传递机制分析 一文中的比喻非常有趣,本文也会借鉴一些其中的内容。

先确定几个角色:

Activity - 公司大老板
RootView - 项目经理
ViewGroupA - 技术小组长
View1 - 码农小王(公司里唯一的码农)
View2 - 跑龙套的路人甲,无视即可

top Created with Sketch.