模擬面試,解鎖大廠 ——從Android的事件分發說起

南方吳彥祖_藍斯發表於2020-09-21

每天一個面試知識點,文章持續更新,Android模擬面試,解鎖大廠一對一面試體驗。

一、題目層次

面試中提到安卓的事件分發,我們一般都能說到從 Activity -> Window -> DecorView -> ViewGroup -> View 的 dispatchTouchEvent 流程,這個是最基本的需要掌握的,由此能深入引出一些什麼知識點呢?

  1. 事件是如何從螢幕點選最終到達 Activity 的?
  2. CANCEL 事件什麼時候會觸發?
  3. 如何解決滑動衝突?

二、題目詳解

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 派發事件

大體流程圖如下:

模擬面試,解鎖大廠 ——從Android的事件分發說起

其中主要有幾個階段:

  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 的作用是用來監控裝置節點是否有更新。
2. 初始化 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.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 處理的過程了,就是下面這張圖。

模擬面試,解鎖大廠 ——從Android的事件分發說起

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;}

2. 事件是如何從螢幕點選最終到達 Activity 的?

模擬面試,解鎖大廠 ——從Android的事件分發說起

3. CANCEL 事件什麼時候會觸發?

  • View 收到 ACTION_DOWN 事件以後,上一個事件還沒有結束(可能因為 APP 的切換、ANR 等導致系統扔掉了後續的事件),這個時候會先執行一次 ACTION_CANCEL
  • 子 View 之前攔截了事件,但是後面父 View 重新攔截了事件,這個時候會給子 View 傳送 ACTION_CANCEL 事件
  1. 如何解決滑動衝突?
  • 透過重寫父類的 onInterceptTouchEvent 來攔截滑動事件
  • 透過在子類中呼叫 parent.requestDisallowInterceptTouchEvent 來通知父類是否要攔截事件

結尾

面試造火箭,工作擰螺絲。雖然我只想擰螺絲,但是我們卻需要透過造火箭來找到擰螺絲的工作。

有些東西你不僅要懂,而且要能夠很好地表達出來,能夠讓面試官認可你的理解,例如Handler機制,這個是面試必問之題。有些晦澀的點,或許它只活在面試當中,實際工作當中你壓根不會用到它,但是你要知道它是什麼東西。

一些基礎知識和理論肯定是要背的,要理解的背,用自己的語言總結一下背下來。

那麼該如何複習?

我為大家準備了以下一體系的複習資料:

《Android開發七大模組核心知識筆記》

模擬面試,解鎖大廠 ——從Android的事件分發說起
模擬面試,解鎖大廠 ——從Android的事件分發說起

《960全網最全Android開發筆記》

模擬面試,解鎖大廠 ——從Android的事件分發說起

《379頁Android開發面試寶典》

歷時半年,我們整理了這份市面上最全面的安卓面試題解析大全
包含了騰訊、百度、小米、阿里、樂視、美團、58、360、新浪、搜狐等一線網際網路公司面試被問到的題目。熟悉本文中列出的知識點會大大增加透過前兩輪技術面試的機率。

如何使用它?

1.可以透過目錄索引直接翻看需要的知識點,查漏補缺。
2.五角星數表示面試問到的頻率,代表重要推薦指數

模擬面試,解鎖大廠 ——從Android的事件分發說起

《507頁Android開發相關原始碼解析》

只要是程式設計師,不管是Java還是Android,如果不去閱讀原始碼,只看API文件,那就只是停留於皮毛,這對我們知識體系的建立和完備以及實戰技術的提升都是不利的。

真正最能鍛鍊能力的便是直接去閱讀原始碼,不僅限於閱讀各大系統原始碼,還包括各種優秀的開源庫。

模擬面試,解鎖大廠 ——從Android的事件分發說起

資料太多,全部展示會影響篇幅,暫時就先列舉這些部分截圖,以上資源均免費分享,以上內容均放在了開源專案: github  中已收錄,大家可以自行獲取(或者關注主頁掃描加微信獲取)。

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/69983917/viewspace-2722901/,如需轉載,請註明出處,否則將追究法律責任。

相關文章