Android教程網
  1. 首頁
  2. Android 技術
  3. Android 手機
  4. Android 系統教程
  5. Android 游戲
 Android教程網 >> Android技術 >> 關於Android編程 >> Android輸入事件從讀取到分發五:事件分發前的攔截過程

Android輸入事件從讀取到分發五:事件分發前的攔截過程

編輯:關於Android編程

已經提過事件在分發前要做攔截的事情,只不過當時沒有展開來分析,因此這篇文章的主要目的就是分析事件在分發前的攔截過程。(注:Android源碼版本為6.0)
我們分析到InputDispatcher類的notifyKey方法中,第一次嘗試攔截事件,可以在看看這個方法:

void InputDispatcher::notifyKey(const NotifyKeyArgs* args) {
...
    KeyEvent event;
    event.initialize(args->deviceId, args->source, args->action,
            flags, keyCode, args->scanCode, metaState, 0,
            args->downTime, args->eventTime);

    mPolicy->interceptKeyBeforeQueueing(&event, /*byref*/ policyFlags);
...
}

這裡是事件進入隊列前的攔截,這裡將其稱為第一次攔截吧。
除此之外,在事件分發之前還要做一次攔截,也就是事件進入到InputDispatcherThread線程後,在發送事件之前,做一次攔截,調用流程如下:
dispatchOnce
->dispatchOnceInnerLocked
->dispatchKeyLocked
->doInterceptKeyBeforeDispatchingLockedInterruptible
->mPolicy->interceptKeyBeforeDispatching
這個過程這裡將其稱為二次攔截吧。

有了上面知識的鋪墊,下面,我們逐一分析兩次攔截過程。

第一次事件攔截

首先看下時序圖:
這裡寫圖片描述
接下來,跟著時序圖,我們分析下事件攔截的源碼:
當我們在InputDispatcher::notifyKey調用mPolicy->interceptKeyBeforeQueueing方法後,就進入到NativeInputManager::interceptKeyBeforeQueueing方法了:

void NativeInputManager::interceptKeyBeforeQueueing(const KeyEvent* keyEvent,
        uint32_t& policyFlags) {
    // Policy:
    // - Ignore untrusted events and pass them along.
    // - Ask the window manager what to do with normal events and trusted injected events.
    // - For normal events wake and brighten the screen if currently off or dim.
    bool interactive = mInteractive.load();
    if (interactive) {
        policyFlags |= POLICY_FLAG_INTERACTIVE;
    }
    if ((policyFlags & POLICY_FLAG_TRUSTED)) {
        nsecs_t when = keyEvent->getEventTime();
        JNIEnv* env = jniEnv();
        jobject keyEventObj = android_view_KeyEvent_fromNative(env, keyEvent);
        jint wmActions;
        if (keyEventObj) {
            wmActions = env->CallIntMethod(mServiceObj,
                    gServiceClassInfo.interceptKeyBeforeQueueing,
                    keyEventObj, policyFlags);
            if (checkAndClearExceptionFromCallback(env, "interceptKeyBeforeQueueing")) {
                wmActions = 0;
            }
            android_view_KeyEvent_recycle(env, keyEventObj);
            env->DeleteLocalRef(keyEventObj);
        } else {
            ALOGE("Failed to obtain key event object for interceptKeyBeforeQueueing.");
            wmActions = 0;
        }

        handleInterceptActions(wmActions, when, /*byref*/ policyFlags);
    } else {
        if (interactive) {
            policyFlags |= POLICY_FLAG_PASS_TO_USER;
        }
    }
}

這個函數首先根據傳下來的KeyEvent類型的參數構造一個keyEventObj,構造的過程是調用android_view_KeyEvent_fromNative方法實現的:

jobject android_view_KeyEvent_fromNative(JNIEnv* env, const KeyEvent* event) {
    jobject eventObj = env->CallStaticObjectMethod(gKeyEventClassInfo.clazz,
            gKeyEventClassInfo.obtain,
            nanoseconds_to_milliseconds(event->getDownTime()),
            nanoseconds_to_milliseconds(event->getEventTime()),
            event->getAction(),
            event->getKeyCode(),
            event->getRepeatCount(),
            event->getMetaState(),
            event->getDeviceId(),
            event->getScanCode(),
            event->getFlags(),
            event->getSource(),
            NULL);
    if (env->ExceptionCheck()) {
        ALOGE("An exception occurred while obtaining a key event.");
        LOGE_EX(env);
        env->ExceptionClear();
        return NULL;
    }
    return eventObj;
}

這個方法使用了jni來調用java層的一個靜態方法obtain,使用這個方法構造了一個eventObj 並返回。這裡不是我們關注的,暫時這樣吧,回NativeInputManager::interceptKeyBeforeQueueing方法中,構造好keyEventObj對象後,又使用jni調用了java層的返回值為int的實例方法,這個實例由mServiceObj決定,它其實就是InputManagerService的實例。大家稍微追蹤一下就會明白,這裡就不啰嗦了。
然後就進入到一系列的interceptKeyBeforeQueueing方法的調用了:

    // Native callback.
    private int interceptKeyBeforeQueueing(KeyEvent event, int policyFlags) {
        return mWindowManagerCallbacks.interceptKeyBeforeQueueing(event, policyFlags);
    }

mWindowManagerCallbacks的實現類是InputMonitor,它的interceptKeyBeforeQueueing方法如下:

    @Override
    public int interceptKeyBeforeQueueing(KeyEvent event, int policyFlags) {
        return mService.mPolicy.interceptKeyBeforeQueueing(event, policyFlags);
    }

這個函數中的mPolicy定義如下:

final WindowManagerPolicy mPolicy = new PhoneWindowManager();

因此,接下來進入到了PhoneWindowManager的interceptKeyBeforeQueueing方法了。

    /** {@inheritDoc} */
    @Override
    public int interceptKeyBeforeQueueing(KeyEvent event, int policyFlags) {
        if (!mSystemBooted) {
            // If we have not yet booted, don't let key events do anything.
            return 0;
        }
        ...
        final boolean interactive = (policyFlags & FLAG_INTERACTIVE) != 0;
        final boolean down = event.getAction() == KeyEvent.ACTION_DOWN;
        final boolean canceled = event.isCanceled();
        switch (keyCode) {
            case KeyEvent.KEYCODE_VOLUME_DOWN:
            case KeyEvent.KEYCODE_VOLUME_UP:
            case KeyEvent.KEYCODE_VOLUME_MUTE: {

             if (keyCode == KeyEvent.KEYCODE_VOLUME_DOWN) {
                    if (down) {
                        if (interactive && !mScreenshotChordVolumeDownKeyTriggered
                                && (event.getFlags() & KeyEvent.FLAG_FALLBACK) == 0) {
                            mScreenshotChordVolumeDownKeyTriggered = true;
                            mScreenshotChordVolumeDownKeyTime = event.getDownTime();
                            mScreenshotChordVolumeDownKeyConsumed = false;
                            cancelPendingPowerKeyAction();
                            interceptScreenshotChord();
                        }
                    } else {
                        mScreenshotChordVolumeDownKeyTriggered = false;
                        cancelPendingScreenshotChordAction();
                    }
                } else if (keyCode == KeyEvent.KEYCODE_VOLUME_UP) {
                    if (down) {
                        if (interactive && !mScreenshotChordVolumeUpKeyTriggered
                                && (event.getFlags() & KeyEvent.FLAG_FALLBACK) == 0) {
                            mScreenshotChordVolumeUpKeyTriggered = true;
                            cancelPendingPowerKeyAction();
                            cancelPendingScreenshotChordAction();
                        }
                    } else {
                        mScreenshotChordVolumeUpKeyTriggered = false;
                        cancelPendingScreenshotChordAction();
                    }
                }       return result;
        ...
    }

這個方法很長,這裡只貼出一小部分。這個方法的返回值很關鍵,返回0則意味著事件被攔截,返回1則意味著事件允許被發送到應用程序中。我們看下最終返回值的處理。再次回到NativeInputManager::interceptKeyBeforeQueueing方法,返回值保存在wmActions變量中,然後調用handleInterceptActions方法處理返回值。其定義如下:

void NativeInputManager::handleInterceptActions(jint wmActions, nsecs_t when,
        uint32_t& policyFlags) {
    if (wmActions & WM_ACTION_PASS_TO_USER) {
        policyFlags |= POLICY_FLAG_PASS_TO_USER;
    } else {
#if DEBUG_INPUT_DISPATCHER_POLICY
        ALOGD("handleInterceptActions: Not passing key to user.");
#endif
    }
}

WM_ACTION_PASS_TO_USER定義如下:

enum {
    WM_ACTION_PASS_TO_USER = 1,
};

這裡位運算,但結果就是如果返回值為1,二者位與後為1,則給policyFlags 添加POLICY_FLAG_PASS_TO_USER標志,意味著可以把該事件發送到應用程序,否則,從注釋中可以知道不會發送事件給用戶。
第一次事件攔截具體會攔截什麼事件,大家可以自己去看,你可以直接去看PhoneWindowManager的interceptKeyBeforeQueueing方法,看看這個方法中,那些事件處理後返回值為0。如果返回值為0則說明這個事件被攔截了。
接下來我們看下第二次攔截

第二次事件攔截

首先看下時序圖:
這裡寫圖片描述
從圖中可以看到其調用過程和第一階段完全相同,因此這裡就不再追蹤源碼了。感興趣可以看看PhoneWindowManager的interceptKeyBeforeDispatching方法,這個方法對事件做了二次攔截,這個方法的返回值為-1則說明事件被攔截,返回值為0則說明事件被放行。
我們看下返回值的處理過程:

            jlong delayMillis = env->CallLongMethod(mServiceObj,
                    gServiceClassInfo.interceptKeyBeforeDispatching,
                    inputWindowHandleObj, keyEventObj, policyFlags);
            bool error = checkAndClearExceptionFromCallback(env, "interceptKeyBeforeDispatching");
            android_view_KeyEvent_recycle(env, keyEventObj);
            env->DeleteLocalRef(keyEventObj);
            if (!error) {
                if (delayMillis < 0) {
                    result = -1;
                } else if (delayMillis > 0) {
                    result = milliseconds_to_nanoseconds(delayMillis);
                }
            }

這裡可以看到返回值存放在delayMillis 變量中,接著判斷:
如果返回值為負數,那麼result=-1,入則,返回值等於0則不處理,因為result默認初始化值為0,如果返回值大於0則把milliseconds_to_nanoseconds的返回值給result。milliseconds_to_nanoseconds方的定義如下:

static CONSTEXPR inline nsecs_t milliseconds_to_nanoseconds(nsecs_t secs)
{
    return secs*1000000;
}

可以看到就是給返回值*1000000.
result最終會返回到InputDispatcher中:

void InputDispatcher::doInterceptKeyBeforeDispatchingLockedInterruptible(
        CommandEntry* commandEntry) {
    KeyEntry* entry = commandEntry->keyEntry;

    KeyEvent event;
    initializeKeyEvent(&event, entry);

    mLock.unlock();

    nsecs_t delay = mPolicy->interceptKeyBeforeDispatching(commandEntry->inputWindowHandle,
            &event, entry->policyFlags);

    mLock.lock();

    if (delay < 0) {
        entry->interceptKeyResult = KeyEntry::INTERCEPT_KEY_RESULT_SKIP;
    } else if (!delay) {
        entry->interceptKeyResult = KeyEntry::INTERCEPT_KEY_RESULT_CONTINUE;
    } else {
        entry->interceptKeyResult = KeyEntry::INTERCEPT_KEY_RESULT_TRY_AGAIN_LATER;
        entry->interceptKeyWakeupTime = now() + delay;
    }
    entry->release();
}

這個方法中,會根據返回值給entry->interceptKeyResult變量賦值。從名字上我們可以猜測,返回值小於0則攔截事件,等於0則放行事件,大於0是待會再檢測是否需要攔截?
這三種類型對應的處理方式在InputDispatcher::dispatchKeyLocked方法中:

    // Handle case where the policy asked us to try again later last time.
    if (entry->interceptKeyResult == KeyEntry::INTERCEPT_KEY_RESULT_TRY_AGAIN_LATER) {
        if (currentTime < entry->interceptKeyWakeupTime) {
            if (entry->interceptKeyWakeupTime < *nextWakeupTime) {
                *nextWakeupTime = entry->interceptKeyWakeupTime;
            }
            return false; // wait until next wakeup
        }
        entry->interceptKeyResult = KeyEntry::INTERCEPT_KEY_RESULT_UNKNOWN;
        entry->interceptKeyWakeupTime = 0;
    }

這裡展示了對INTERCEPT_KEY_RESULT_TRY_AGAIN_LATER的處理,會判斷攔截時間和當前時間,如果當前時間小於攔截時間,則下次循環再處理。所以我們理解的是對的。

 if (entry->interceptKeyResult == KeyEntry::INTERCEPT_KEY_RESULT_SKIP) {
        if (*dropReason == DROP_REASON_NOT_DROPPED) {
            *dropReason = DROP_REASON_POLICY;
        }
    }

這裡展示了INTERCEPT_KEY_RESULT_SKIP類型的處理,如果dropReason 的狀態為不沒有丟棄事件的話,那就把它的狀態改為因為策略丟棄。也就是事件被攔截了。
INTERCEPT_KEY_RESULT_CONTINUE則是不做處理了。所有沒有對應這種狀態的處理代碼。

  1. 上一頁:
  2. 下一頁:
熱門文章
閱讀排行版
Copyright © Android教程網 All Rights Reserved