关于java:Android面试查漏补缺之事件分发机制详解

44次阅读

共计 9565 个字符，预计需要花费 24 分钟才能阅读完成。

前言

查漏补缺，查漏补缺，你不晓得哪里漏了，怎么补缺呢？本文属于【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 派发事件

大体流程图如下：

其中次要有几个阶段：

  1. 硬件中断
  2. InputManagerService 做的事件
  3. InputReaderThread 做的事件
  4. InputDispatcherThread 做的事件
  5. 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);
}

次要做的两件事：

  1. 初始化 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 的作用是用来监控设施节点是否有更新。

  1. 初始化 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 里做了三件事件：

  1. 从 EventHub 获取事件
  2. 处理事件，这里事件有不同的类型，会做不同的解决和封装
  3. 把事件发送给 InputDispatcher

2.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.java
public final boolean dispatchPointerEvent(MotionEvent event) {if (event.isTouchEvent()) {return dispatchTouchEvent(event);
    } else {return dispatchGenericMotionEvent(event);
    }
}

// DecorView.java
public 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 解决的过程了，就是上面这张图。

2.3 CANCEL 事件什么时候会触发

这个如果认真看 dispatchTouchEvent 的代码的话，能够看到一些机会：

  1. 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();}
}
  1. 子 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 如何解决滑动抵触

这个也是陈词滥调的一个问题了，次要就是两个办法：

  1. 通过重写父类的 onInterceptTouchEvent 来拦挡滑动事件
  2. 通过在子类中调用 parent.requestDisallowInterceptTouchEvent 来告诉父类是否要拦挡事件，requestDisallowInterceptTouchEvent 会设置 FLAG_DISALLOW_INTERCEPT 标记，这个在最开始的伪代码那里做过介绍

三、总结

下面就是从 View 事件散发引申出的一些问题，简略的解答如下：

  1. 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;
}
  1. 事件是如何从屏幕点击最终达到 Activity 的？
  2. CANCEL 事件什么时候会触发？
  • View 收到 ACTION_DOWN 事件当前，上一个事件还没有完结（可能因为 APP 的切换、ANR 等导致系统扔掉了后续的事件），这个时候会先执行一次 ACTION_CANCEL
  • 子 View 之前拦挡了事件，然而前面父 View 从新拦挡了事件，这个时候会给子 View 发送 ACTION_CANCEL 事件
  1. 如何解决滑动抵触？
  • 通过重写父类的 onInterceptTouchEvent 来拦挡滑动事件
  • 通过在子类中调用 parent.requestDisallowInterceptTouchEvent 来告诉父类是否要拦挡事件

最初

我把之前遇到的面试真题做了一个整合，已上传至开源我的项目【GitHub】, 有须要的敌人能够自行收费获取。

Activity 面试题

Fragment 面试题

Service&Broadcast Receiver 面试题

WebView&Binder 面试题

Handler 面试题

AsyncTask 面试题

因为篇幅起因，为了防止影响到大家的浏览体验，在此只以截图展现局部内容，有须要的敌人记得点赞反对下哦，【点这里】即可收费支付！

正文完
java
发表至： java
2020-12-10
 0
关于java:Spring-Security即将弃用WebSecurityConfigurerAdapter配置类
关于java:Spring-Boot-Vue-如此强大
关于java:项目
测试