【Android面试查漏补缺】之事件分发机制详解

概述前言查漏补缺，查漏补缺，你不知道哪里漏了，怎么补缺呢？本文属于【Android面试查漏补缺】系列文章第一篇，持续更新中，感兴趣的朋友可以【关注+收藏】哦~本系列文章是对自己的前段时间面试经历的总结。其实本来自己是不太想继续写关于面试题的文章了，因为社区内很多这类的文章，但是如果每个 前言

查漏补缺，查漏补缺，你不知道哪里漏了，怎么补缺呢？本文属于【AndroID面试查漏补缺】系列文章第一篇，持续更新中，感兴趣的朋友可以【关注+收藏】哦~

本系列文章是对自己的前段时间面试经历的总结。其实本来自己是不太想继续写关于面试题的文章了，因为社区内很多这类的文章，但是如果每个地方翻一下，又不方便自己回顾，所以还是决定写下本文供自己巩固，也给大家一个参考。

一、题目层次

面试中提到安卓的事件分发，我们一般都能说到从 Activity -> Window -> DecorVIEw -> VIEwGroup -> VIEw 的 dispatchtouchEvent 流程，这个是最基本的需要掌握的，由此能深入引出一些什么知识点呢？

事件是如何从屏幕点击最终到达 Activity 的？
CANCEL 事件什么时候会触发？
如何解决滑动冲突？

二、题目详解2.1 安卓事件的分发

安卓的事件分发大概会经历 Activity -> PhoneWindow -> DecorVIEw -> VIEwGroup -> VIEw 的 dispatchtouchEvent。
其中 dispatchtouchEvent 用下面的一段伪代码就可以说明了，过程就不具体分析了，大家应该也都比较清晰。

// 伪代码public boolean dispatchtouchEvent() {    boolean res = false;    // 是否不允许拦截事件    // 如果设置了 FLAG_disALLOW_INTERCEPT，不会拦截事件，所以在 child 里可以通过 requestdisallowIntercepttouchEvent 控制父 VIEw 是否来拦截事件    final boolean disallowIntercept = (mGroupFlags & FLAG_disALLOW_INTERCEPT) != 0;    if (!disallowIntercept && onIntercepttouchEvent()) { // VIEw 不调用这里，直接执行下面的 touchListener 判断        if (touchListener && touchListener.ontouch()) {            return true;        }        res = ontouchEvent(); // 里面会处理点击事件 -> performClick() -> clickListener.onClick()    } else if (DOWN) { // 如果是 DOWN 事件，则遍历子 VIEw 进行事件分发        // 循环子 VIEw 处理事件        for (childs) {            res = child.dispatchtouchEvent();        }    } else {        // 事件分发给 target 去处理，这里的 target 就是上一步处理 DOWN 事件的 VIEw        target.child.dispatchtouchEvent();    }    return res;}

2.2 事件是如何到达 Activity 的

既然上面的事件分发是从 Activity 开始的，那事件是怎么到达 Activity 的呢？

总体流程大概是这样的：用户点击设备, linux 内核接受中断, 中断加工成输入事件数据写入对应的设备节点中, inputReader 会监控 /dev/input/ 下的所有设备节点, 当某个节点有数据可以读时，通过 EventHub 将原始事件取出来并翻译加工成输入事件，交给 inputdispatcher，inputdispatcher 根据 WMS 提供的窗口信息把事件交给合适的窗口,窗口 VIEwRootImpl 派发事件

大体流程图如下：

input

其中主要有几个阶段：

硬件中断inputManagerService 做的事情inputReaderThread 做的事情inputdispatcherThread 做的事情WindowinputEventReceiver 做的事情2.2.1 硬件中断

硬件中断这里就简单介绍一些， *** 作系统对硬件事件的接收是通过中断来进行的。
内核启动的时候会在中断描述符表中对中断类型以及对应的处理方法的地址进行注册。
当有中断的时候，就会调用对应的处理方法，把对应的事件写入到设备节点里。

2.2.2 inputManagerService 做的事情

inputManagerService 是用来处理 input 事件的，Java 侧的 inputManagerService 就是 C++ 代码的一个封装，以及提供了一些 callback 用来传递事件到 Java 层。
我们看一下 native 侧的 inputManagerService 初始化代码。

NativeinputManager::NativeinputManager(jobject contextObj,        jobject serviceObj, const sp<Looper>& looper) :        mLooper(looper), mInteractive(true) {    // ...    sp<EventHub> eventHub = new EventHub();    minputManager = new inputManager(eventHub, this, this);}

主要做的两件事：

初始化 EventHub

EventHub::EventHub(voID) {            // ...    mINotifyFd = inotify_init();    int result = inotify_add_watch(mINotifyFd, DEVICE_PATH, IN_DELETE | IN_CREATE);    result = epoll_ctl(mEpollFd, EPolL_CTL_ADD, mINotifyFd, &eventItem);    result = epoll_ctl(mEpollFd, EPolL_CTL_ADD, mWakeReadPipeFd, &eventItem);}

EventHub 的作用是用来监控设备节点是否有更新。

初始化 inputManager

voID inputManager::initialize() {    mReaderThread = new inputReaderThread(mReader);    mdispatcherThread = new inputdispatcherThread(mdispatcher);}

inputManager 里初始化了 inputReaderThread 和 inputdispatcherThread 两个线程，一个用来读取事件，一个用来派发事件。

2.2.3 inputReaderThread 做的事情

bool inputReaderThread::threadLoop() {    mReader->loopOnce();    return true;}voID inputReader::loopOnce() {    // 从 EventHub 获取事件    size_t count = mEventHub->getEvents(timeoutMillis, mEventBuffer, EVENT_BUFFER_SIZE);    // 处理事件    processEventsLocked(mEventBuffer, count);    // 事件发送给 inputdispatcher 去做分发    mQueuedListener->flush();}

这里代码比较多，做一些省略。
inputReaderThread 里做了三件事情：

从 EventHub 获取事件处理事件，这里事件有不同的类型，会做不同的处理和封装把事件发送给 inputdispatcher2.2.4 inputdispatcherThread 做的事情

bool inputdispatcherThread::threadLoop() {    mdispatcher->dispatchOnce(); // 内部调用 dispatchOnceInnerLocked    return true;}voID inputdispatcher::dispatchOnceInnerLocked(nsecs_t* nextWakeupTime) {    // 从队列中取出一个事件    mPendingEvent = mInboundQueue.dequeueAthead();    // 根据不同的事件类型，进行不同的 *** 作    switch (mPendingEvent->type) {    case EventEntry::TYPE_CONfigURATION_CHANGED: {        // ...    case EventEntry::TYPE_DEVICE_reset: {        // ...    case EventEntry::TYPE_KEY: {        // ...    case EventEntry::TYPE_MOTION: {        // 派发事件        done = dispatchMotionLocked(currentTime, typedEntry,                &dropReason, nextWakeupTime);        break;    }}

上面通过 dispatchMotionLocked 方法派发事件，具体的函数调用过程省略如下：

dispatchMotionLocked -> dispatchEventLocked -> preparedispatchCycleLocked -> enqueuedispatchEntrIEsLocked -> startdispatchCycleLocked -> publishMotionEvent -> inputChannel.sendMessage

其中会找到当前合适的 Window，然后调用 inputChannel 去发送事件。

这里的 inputChannel 对应的是 VIEwRootImpl 里的 inputChannel。
至于中间的怎么做的关联，这里就先不做分析，整个代码比较长，而且对于流程的掌握影响不大。

2.2.5 WindowinputEventReceiver 接受事件并进行分发

在 VIEwRootImpl 里有一个 WindowinputEventReceiver 用来接受事件并进行分发。
inputChannel 发送的事件最终都是通过 WindowinputEventReceiver 进行接受。
WindowinputEventReceiver 是在 VIEwRootImpl.setVIEw 里面初始化的，setVIEw 的调用是在 ActivityThread.handleResumeActivity -> WindowManagerGlobal.addVIEw。

    public voID setVIEw(VIEw vIEw, WindowManager.LayoutParams attrs, VIEw panelParentVIEw) {        // ...        if (minputChannel != null) {            if (minputQueueCallback != null) {                minputQueue = new inputQueue();                minputQueueCallback.oninputQueueCreated(minputQueue);            }            minputEventReceiver = new WindowinputEventReceiver(minputChannel,                    Looper.myLooper());        }    }

public abstract class inputEventReceiver {    // native 侧代码调用这个方法，把事件派发过来    private voID dispatchinputEvent(int seq, inputEvent event, int displayID) {        mSeqMap.put(event.getSequenceNumber(), seq);        oninputEvent(event, displayID);    }}final class WindowinputEventReceiver extends inputEventReceiver {    @OverrIDe    public voID oninputEvent(inputEvent event, int displayID) {        // 事件接受        enqueueinputEvent(event, this, 0, true);    }    // ...}voID enqueueinputEvent(inputEvent event,        inputEventReceiver receiver, int flags, boolean processImmediately) {    // 是否要立即处理事件    if (processImmediately) {        doProcessinputEvents();    } else {        scheduleProcessinputEvents();    }}voID doProcessinputEvents() {    // ...    while (mPendinginputEventhead != null) {        deliverinputEvent(q);    }    // ...}private voID deliverinputEvent(QueuedinputEvent q) {    // ...    inputStage stage;    if (q.shouldSendToSynthesizer()) {        stage = mSyntheticinputStage;    } else {        stage = q.shouldSkipIme() ? mFirstPostImeinputStage : mFirstinputStage;    }    // 分发事件    stage.deliver(q);}

从上面的代码流程中，事件最终走到 inputStage.deliver 里。

abstract class inputStage {    public final voID deliver(QueuedinputEvent q) {        if ((q.mFlags & QueuedinputEvent.FLAG_FINISHED) != 0) {            forward(q);        } else if (shouldDropinputEvent(q)) {            finish(q, false);        } else {            apply(q, onProcess(q));        }    }}

在 deliver 里，最终调用 onProcess，实现是在 VIEwPostImeinputStage。

final class VIEwPostImeinputStage extends inputStage {    @OverrIDe    protected int onProcess(QueuedinputEvent q) {        if (q.mEvent instanceof KeyEvent) {            return processKeyEvent(q);        } else {            final int source = q.mEvent.getSource();            if ((source & inputDevice.soURCE_CLASS_POINTER) != 0) {                return processpointerEvent(q);            } else if ((source & inputDevice.soURCE_CLASS_trackball) != 0) {                return processtrackballEvent(q);            } else {                return processGenericMotionEvent(q);            }        }    }    private int processpointerEvent(QueuedinputEvent q) {        // 这里 mVIEw 是 DecorVIEw，调用到 DecorVIEw.dispatchPointerEvent        boolean handled = mVIEw.dispatchPointerEvent(event);        // ...        return handled ? FINISH_HANDLED : FORWARD;    }}// VIEw.javapublic final boolean dispatchPointerEvent(MotionEvent event) {    if (event.istouchEvent()) {        return dispatchtouchEvent(event);    } else {        return dispatchGenericMotionEvent(event);    }}// DecorVIEw.javapublic boolean dispatchtouchEvent(MotionEvent ev) {    // 这里的 Callback 就是 Activity，是在 Activity.attach 里调用 mWindow.setCallback(this); 设置的    final Window.Callback cb = mWindow.getCallback();    return cb != null && !mWindow.isDestroyed() && mFeatureID < 0            ? cb.dispatchtouchEvent(ev) : super.dispatchtouchEvent(ev);}

通过上面一系列流程，最终就调用到 Activity.dispatchtouchEvent 里，也就是开始的流程了。

通过上面的分析，我们基本上知道了事件从用户点击屏幕到 VIEw 处理的过程了，就是下面这张图。

 

input2.3 CANCEL 事件什么时候会触发

这个如果仔细看 dispatchtouchEvent 的代码的话，可以看到一些时机：

VIEw 收到 ACTION_DOWN 事件以后，上一个事件还没有结束（可能因为 APP 的切换、ANR 等导致系统扔掉了后续的事件），这个时候会先执行一次 ACTION_CANCEL

// VIEwGroup.dispatchtouchEvent()public boolean dispatchtouchEvent(MotionEvent ev) {    if (actionMasked == MotionEvent.ACTION_DOWN) {        // Throw away all prevIoUs state when starting a new touch gesture.        // The framework may have dropped the up or cancel event for the prevIoUs gesture        // due to an app switch, ANR, or some other state change.        cancelAndCleartouchTargets(ev);        resettouchState();    }}

子 VIEw 之前拦截了事件，但是后面父 VIEw 重新拦截了事件，这个时候会给子 VIEw 发送 ACTION_CANCEL 事件

// VIEwGroup.dispatchtouchEvent()public boolean dispatchtouchEvent(MotionEvent ev) {    if (mFirsttouchTarget == null) {    } else {        // 有子 VIEw 获取了事件        touchTarget target = mFirsttouchTarget;        while (target != null) {            final touchTarget next = target.next;            final boolean cancelChild = resetCancelNextUpFlag(target.child)                    || intercepted;            // 父 VIEw 此时如果拦截了事件，cancelChild 是 true            if (dispatchtransformedtouchEvent(ev, cancelChild,                    target.child, target.pointerIDBits)) {                handled = true;            }        }    }}private boolean dispatchtransformedtouchEvent(MotionEvent event, boolean cancel,        VIEw child, int desiredPointerIDBits) {    final int oldAction = event.getAction();    // 如果 cancel 是 true，则发送 ACTION_CANCEL 事件    if (cancel || oldAction == MotionEvent.ACTION_CANCEL) {        event.setAction(MotionEvent.ACTION_CANCEL);        if (child == null) {            handled = super.dispatchtouchEvent(event);        } else {            handled = child.dispatchtouchEvent(event);        }        event.setAction(oldAction);        return handled;    }}

2.4 如何解决滑动冲突

这个也是老生常谈的一个问题了，主要就是两个方法：

通过重写父类的 onIntercepttouchEvent 来拦截滑动事件通过在子类中调用 parent.requestdisallowIntercepttouchEvent 来通知父类是否要拦截事件，requestdisallowIntercepttouchEvent 会设置 FLAG_disALLOW_INTERCEPT 标志，这个在最开始的伪代码那里做过介绍三、总结

上面就是从 VIEw 事件分发引申出的一些问题，简单的解答如下：

VIEw 事件分发

// 伪代码public boolean dispatchtouchEvent() {    boolean res = false;    // 是否不允许拦截事件    // 如果设置了 FLAG_disALLOW_INTERCEPT，不会拦截事件，所以在 child 里可以通过 requestdisallowIntercepttouchEvent 控制父 VIEw 是否来拦截事件    final boolean disallowIntercept = (mGroupFlags & FLAG_disALLOW_INTERCEPT) != 0;    if (!disallowIntercept && onIntercepttouchEvent()) { // VIEw 不调用这里，直接执行下面的 touchListener 判断        if (touchListener && touchListener.ontouch()) {            return true;        }        res = ontouchEvent(); // 里面会处理点击事件 -> performClick() -> clickListener.onClick()    } else if (DOWN) { // 如果是 DOWN 事件，则遍历子 VIEw 进行事件分发        // 循环子 VIEw 处理事件        for (childs) {            res = child.dispatchtouchEvent();        }    } else {        // 事件分发给 target 去处理，这里的 target 就是上一步处理 DOWN 事件的 VIEw        target.child.dispatchtouchEvent();    }    return res;}

事件是如何从屏幕点击最终到达 Activity 的？

input

CANCEL 事件什么时候会触发？

VIEw 收到 ACTION_DOWN 事件以后，上一个事件还没有结束（可能因为 APP 的切换、ANR 等导致系统扔掉了后续的事件），这个时候会先执行一次 ACTION_CANCEL子 VIEw 之前拦截了事件，但是后面父 VIEw 重新拦截了事件，这个时候会给子 VIEw 发送 ACTION_CANCEL 事件如何解决滑动冲突？通过重写父类的 onIntercepttouchEvent 来拦截滑动事件通过在子类中调用 parent.requestdisallowIntercepttouchEvent 来通知父类是否要拦截事件最后

我把之前遇到的面试真题做了一个整合，已上传至开源项目【GitHub】,有需要的朋友可以自行免费获取。

Activity面试题

Fragment面试题

Service&broadcast Receiver面试题

WebVIEw&Binder面试题

Handler面试题

AsyncTask面试题

由于篇幅原因，为了避免影响到大家的阅读体验，在此只以截图展示部分内容，有需要的朋友记得点赞支持下哦，【点这里】即可免费领取！

总结

以上是内存溢出为你收集整理的【Android面试查漏补缺】之事件分发机制详解全部内容，希望文章能够帮你解决【Android面试查漏补缺】之事件分发机制详解所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。