Input系統(tǒng)按鍵事件的分發(fā)處理示例詳解
前言
前面一篇文章分析了 InputReader 對(duì)按鍵事件的流程流程,大致上就是根據(jù)配置文件把按鍵的掃描碼(scan code)轉(zhuǎn)換為按鍵碼(key code),并且同時(shí)會(huì)從配置文件中獲取策略標(biāo)志位(policy flag),用于控制按鍵的行為,例如亮屏。然后把按鍵事件進(jìn)行包裝,分發(fā)給 InputDispatcher。本文就接著來(lái)分析 InputDispatcher 對(duì)按鍵事件的處理。
1. InputDispatcher 收到事件
從前面一篇文章可知,InputDispatcher 收到的按鍵事件的來(lái)源如下
void KeyboardInputMapper::processKey(nsecs_t when, nsecs_t readTime, bool down, int32_t scanCode,
int32_t usageCode) {
// ...
// 按鍵事件包裝成 NotifyKeyArgs
NotifyKeyArgs args(getContext()->getNextId(), when, readTime, getDeviceId(), mSource,
getDisplayId(), policyFlags,
down ? AKEY_EVENT_ACTION_DOWN : AKEY_EVENT_ACTION_UP,
AKEY_EVENT_FLAG_FROM_SYSTEM, keyCode, scanCode, keyMetaState, downTime);
// 加入到 QueuedInputListener 緩存隊(duì)列中
getListener()->notifyKey(&args);
}
InputReader 把按鍵事件交給 KeyboardInputMapper 處理,KeyboardInputMapper 把按鍵事件包裝成 NotifyKeyArgs,然后加入到 QueuedInputListener 的緩存隊(duì)列。
然后,當(dāng) InputReader 處理完所有事件后,會(huì)刷新 QueuedInputListener 的緩存隊(duì)列,如下
void InputReader::loopOnce() {
// ...
{ // acquire lock
// ...
if (count) {
// 處理事件
processEventsLocked(mEventBuffer, count);
}
// ...
} // release lock
// ...
// 刷新緩存隊(duì)列
mQueuedListener->flush();
}
QueuedInputListener 會(huì)把緩存隊(duì)列中的所有事件,分發(fā)給 InputClassifier
// framework/native/services/inputflinger/InputListener.cpp
void QueuedInputListener::flush() {
size_t count = mArgsQueue.size();
for (size_t i = 0; i < count; i++) {
NotifyArgs* args = mArgsQueue[i];
args->notify(mInnerListener);
delete args;
}
mArgsQueue.clear();
}
void NotifyKeyArgs::notify(const sp<InputListenerInterface>& listener) const {
// 交給 InputClassifier
listener->notifyKey(this);
}
InputClassifier 收到 NotifyKeyArgs 事件后,其實(shí)什么也沒(méi)做,就交給了 InputDispatcher
void InputClassifier::notifyKey(const NotifyKeyArgs* args) {
// 直接交給 InputDispatcher
mListener->notifyKey(args);
}
現(xiàn)在明白了按鍵事件的來(lái)源,接下來(lái)分析 InputDispatcher 如何處理按鍵事件
void InputDispatcher::notifyKey(const NotifyKeyArgs* args) {
// 檢測(cè) action,action 只能為 AKEY_EVENT_ACTION_DOWN/AKEY_EVENT_ACTION_UP
if (!validateKeyEvent(args->action)) {
return;
}
// 策略標(biāo)志位,一般來(lái)源于配置文件
uint32_t policyFlags = args->policyFlags;
int32_t flags = args->flags;
int32_t metaState = args->metaState;
// InputDispatcher tracks and generates key repeats on behalf of
// whatever notifies it, so repeatCount should always be set to 0
constexpr int32_t repeatCount = 0;
if ((policyFlags & POLICY_FLAG_VIRTUAL) || (flags & AKEY_EVENT_FLAG_VIRTUAL_HARD_KEY)) {
policyFlags |= POLICY_FLAG_VIRTUAL;
flags |= AKEY_EVENT_FLAG_VIRTUAL_HARD_KEY;
}
if (policyFlags & POLICY_FLAG_FUNCTION) {
metaState |= AMETA_FUNCTION_ON;
}
// 來(lái)自 InputClassifier 的事件都是受信任的
policyFlags |= POLICY_FLAG_TRUSTED;
int32_t keyCode = args->keyCode;
accelerateMetaShortcuts(args->deviceId, args->action, keyCode, metaState);
// 創(chuàng)建 KeyEvent,這個(gè)對(duì)象主要用于,在事件加入到 InputDispatcher 隊(duì)列前,執(zhí)行策略截?cái)嗖樵?
KeyEvent event;
event.initialize(args->id, args->deviceId, args->source, args->displayId, INVALID_HMAC,
args->action, flags, keyCode, args->scanCode, metaState, repeatCount,
args->downTime, args->eventTime);
android::base::Timer t;
// 1. 詢問(wèn)策略,在按鍵事件加入到 InputDispatcher 隊(duì)列前,是否截?cái)嗍录?
// 如果上層不截?cái)嗍录?,policyFlags 添加 POLICY_FLAG_PASS_TO_USER,表示事件需要傳遞給用戶
// 如果上層截?cái)嗍录?,那么不?huì)添加 policyFlags 添加 POLICY_FLAG_PASS_TO_USER,事件最終不會(huì)傳遞給用戶
mPolicy->interceptKeyBeforeQueueing(&event, /*byref*/ policyFlags);
// 記錄處理時(shí)間
// 如果是Power鍵的截?cái)嗵幚頃r(shí)間過(guò)長(zhǎng),那么亮屏或者滅屏可能會(huì)讓用戶感覺(jué)到有延遲
if (t.duration() > SLOW_INTERCEPTION_THRESHOLD) {
ALOGW("Excessive delay in interceptKeyBeforeQueueing; took %s ms",
std::to_string(t.duration().count()).c_str());
}
bool needWake;
{ // acquire lock
mLock.lock();
// 通常系統(tǒng)沒(méi)有輸入過(guò)濾器(input filter)
if (shouldSendKeyToInputFilterLocked(args)) {
// ...
}
// 創(chuàng)建 KeyEntry,這個(gè)對(duì)象是 InputDispatcher 用于分發(fā)循環(huán)的
std::unique_ptr<KeyEntry> newEntry =
std::make_unique<KeyEntry>(args->id, args->eventTime, args->deviceId, args->source,
args->displayId, policyFlags, args->action, flags,
keyCode, args->scanCode, metaState, repeatCount,
args->downTime);
// 2. 把 KeyEntry 加入到 InputDispatcher 的收件箱 mInboundQueue 中
needWake = enqueueInboundEventLocked(std::move(newEntry));
mLock.unlock();
} // release lock
// 3. 如有必要,喚醒 InputDispatcher 線程處理事件
if (needWake) {
mLooper->wake();
}
}
InputDispatcher 處理按鍵事件的過(guò)程如下
- 把按鍵事件包裝成 KeyEvent 對(duì)象,然后查詢截?cái)嗖呗?,看看策略是否截?cái)嘣撌录H绻呗圆唤財(cái)?,那么?huì)在參數(shù) policyFlags 添加 POLICY_FLAG_PASS_TO_USER 標(biāo)志位,表示事件要發(fā)送給用戶。 否則不會(huì)添加這個(gè)標(biāo)志位,InputDispatcher 后面會(huì)丟棄這個(gè)事件,也就是不會(huì)分發(fā)給用戶。參考【1.1 截?cái)嗖呗圆樵儭?/li>
- 把按鍵事件包裝成 KeyEntry 對(duì)象,然后加入到 InputDispatcher 的收件箱 InputDispatcher::mInboundQueue。參考【1.2 InputDispatcher 收件箱接收事件】
- 如有必要,喚醒 InputDispatcher 線程處理事件。通常,InputDispatcher 線程處于休眠狀態(tài)時(shí),如果收到事件,那么需要喚醒線程來(lái)處理事件。
注意,這里的所有操作,不是發(fā)生在 InputDispatcher 線程,而是發(fā)生在 InputReader 線程,這個(gè)線程是負(fù)責(zé)不斷地讀取事件,因此這里的查詢策略是否截?cái)嗍录倪^(guò)程,時(shí)間不能太長(zhǎng),否則影響了輸入系統(tǒng)讀取事件。
另外,在執(zhí)行完截?cái)嗖呗院?,?huì)記錄處理的時(shí)長(zhǎng),如果時(shí)長(zhǎng)超過(guò)一定的閾值,會(huì)收到一個(gè)警告信息。我曾經(jīng)聽(tīng)到其他項(xiàng)目的人在談?wù)?power 鍵亮屏慢的問(wèn)題,那么可以在這里排查下。
1.1 截?cái)嗖呗圆樵?/h3>
// framework/base/services/core/jni/com_android_server_input_InputManagerService.cpp
void NativeInputManager::interceptKeyBeforeQueueing(const KeyEvent* keyEvent,
uint32_t& policyFlags) {
// ...
// 如果處于交互狀態(tài),policyFlags 添加 POLICY_FLAG_INTERACTIVE 標(biāo)志位
bool interactive = mInteractive.load();
if (interactive) {
policyFlags |= POLICY_FLAG_INTERACTIVE;
}
// 受信任的按鍵事件,才會(huì)執(zhí)行策略查詢
// 來(lái)自 InputClassifier 的事件都是受信任的
if ((policyFlags & POLICY_FLAG_TRUSTED)) {
nsecs_t when = keyEvent->getEventTime();
JNIEnv* env = jniEnv();
// 1. 創(chuàng)建上層的 KeyEvent 對(duì)象
jobject keyEventObj = android_view_KeyEvent_fromNative(env, keyEvent);
jint wmActions;
if (keyEventObj) {
// 2. 調(diào)用上層的 InputManangerService#interceptMotionBeforeQueueingNonInteractive()
// 最終是通過(guò) PhoneWindowManager 完成截?cái)嗖呗圆樵兊?
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;
}
// 3. 處理策略查詢的結(jié)果
handleInterceptActions(wmActions, when, /*byref*/ policyFlags);
} else {
// 不受信任的事件,不會(huì)執(zhí)行截?cái)嗖呗圆樵?,而且只有在設(shè)備處于交互狀態(tài)下,才能發(fā)送給用戶
if (interactive) {
policyFlags |= POLICY_FLAG_PASS_TO_USER;
}
}
}
void NativeInputManager::handleInterceptActions(jint wmActions, nsecs_t when,
uint32_t& policyFlags) {
// 4. 如果策略不截?cái)嗍录?,那么在策略?biāo)志位 policyFlags 中添加 POLICY_FLAG_PASS_TO_USER 標(biāo)志位
// 策略查詢的結(jié)果中有 WM_ACTION_PASS_TO_USER 標(biāo)志位,表示需要把事件傳遞給用戶
if (wmActions & WM_ACTION_PASS_TO_USER) {
policyFlags |= POLICY_FLAG_PASS_TO_USER;
}
}
// framework/base/services/core/jni/com_android_server_input_InputManagerService.cpp
void NativeInputManager::interceptKeyBeforeQueueing(const KeyEvent* keyEvent,
uint32_t& policyFlags) {
// ...
// 如果處于交互狀態(tài),policyFlags 添加 POLICY_FLAG_INTERACTIVE 標(biāo)志位
bool interactive = mInteractive.load();
if (interactive) {
policyFlags |= POLICY_FLAG_INTERACTIVE;
}
// 受信任的按鍵事件,才會(huì)執(zhí)行策略查詢
// 來(lái)自 InputClassifier 的事件都是受信任的
if ((policyFlags & POLICY_FLAG_TRUSTED)) {
nsecs_t when = keyEvent->getEventTime();
JNIEnv* env = jniEnv();
// 1. 創(chuàng)建上層的 KeyEvent 對(duì)象
jobject keyEventObj = android_view_KeyEvent_fromNative(env, keyEvent);
jint wmActions;
if (keyEventObj) {
// 2. 調(diào)用上層的 InputManangerService#interceptMotionBeforeQueueingNonInteractive()
// 最終是通過(guò) PhoneWindowManager 完成截?cái)嗖呗圆樵兊?
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;
}
// 3. 處理策略查詢的結(jié)果
handleInterceptActions(wmActions, when, /*byref*/ policyFlags);
} else {
// 不受信任的事件,不會(huì)執(zhí)行截?cái)嗖呗圆樵?,而且只有在設(shè)備處于交互狀態(tài)下,才能發(fā)送給用戶
if (interactive) {
policyFlags |= POLICY_FLAG_PASS_TO_USER;
}
}
}
void NativeInputManager::handleInterceptActions(jint wmActions, nsecs_t when,
uint32_t& policyFlags) {
// 4. 如果策略不截?cái)嗍录?,那么在策略?biāo)志位 policyFlags 中添加 POLICY_FLAG_PASS_TO_USER 標(biāo)志位
// 策略查詢的結(jié)果中有 WM_ACTION_PASS_TO_USER 標(biāo)志位,表示需要把事件傳遞給用戶
if (wmActions & WM_ACTION_PASS_TO_USER) {
policyFlags |= POLICY_FLAG_PASS_TO_USER;
}
}
事件截?cái)嗖呗缘牟樵冞^(guò)程,就是就是通過(guò) JNI 調(diào)用上層 InputManagerService 的方法,而這個(gè)策略最終是由 PhoneWindowManager 實(shí)現(xiàn)的。如果策略不截?cái)?,如果策略不截?cái)嗍录?,那么在參?shù)的策略標(biāo)志位 policyFlags 中添加 POLICY_FLAG_PASS_TO_USER 標(biāo)志位。
為何需要這個(gè)截?cái)嗖呗裕?或者這樣問(wèn),如果沒(méi)有截?cái)嗖呗?,那么?huì)有什么問(wèn)題呢? 假想我們正在處于通話,此時(shí)按下掛斷電話按鍵,如果輸入系統(tǒng)還有很多事件沒(méi)有處理完,或者說(shuō),處理事件的時(shí)間較長(zhǎng),那么掛斷電話的按鍵事件不能得到及時(shí)處理,這就相當(dāng)影響用戶體驗(yàn)。而如果有了截?cái)嗖呗裕谳斎胂到y(tǒng)正式處理事件前,就可以處理掛斷電話按鍵事件。
因此,截?cái)嗖呗缘淖饔镁褪羌皶r(shí)處理系統(tǒng)一些重要的功能。這給我們一個(gè)什么提示呢?當(dāng)硬件上添加了一個(gè)按鍵,如果想要快速響應(yīng)這個(gè)按鍵的事件,那么就在截?cái)嗖呗灾刑幚怼?/p>
關(guān)于截?cái)嗖呗裕约昂竺娴姆职l(fā)策略,是一個(gè)比較好的課題,我會(huì)在后面一篇文章中詳細(xì)分析。
下面,理解幾個(gè)概念
- 什么是交互狀態(tài)?什么是非交互狀態(tài)?簡(jiǎn)單理解,亮屏就是交互狀態(tài),滅屏就是非交互狀態(tài)。但是,嚴(yán)格來(lái)說(shuō),并不準(zhǔn)確,如果讀者想知道具體的定義,可以查看我寫的 PowerManagerService 的文章。
- 什么是受信任的事件?來(lái)自物理輸入設(shè)備的事件都是受信任的,另外像 SystemUI ,由于申請(qǐng)了 android.permission.INJECT_EVENTS 權(quán)限, 因此它注入的 BACK, HOME 按鍵事件也都是受信任。
- 什么是注入事件?簡(jiǎn)單來(lái)說(shuō),不是由物理設(shè)備產(chǎn)生的事件。例如,導(dǎo)航欄上的 BACK, HOME 按鍵,它們的事件都是通過(guò)注入產(chǎn)生的,因此它們是注入事件。
1.2 InputDispatcher 收件箱接收事件
bool InputDispatcher::enqueueInboundEventLocked(std::unique_ptr<EventEntry> newEntry) {
// mInboundQueue 隊(duì)列為空,需要喚醒 InputDispatcher 線程來(lái)處理事件
bool needWake = mInboundQueue.empty();
// 加入到 mInboundQueue 中
mInboundQueue.push_back(std::move(newEntry));
EventEntry& entry = *(mInboundQueue.back());
traceInboundQueueLengthLocked();
switch (entry.type) {
case EventEntry::Type::KEY: {
// Optimize app switch latency.
// If the application takes too long to catch up then we drop all events preceding
// the app switch key.
const KeyEntry& keyEntry = static_cast<const KeyEntry&>(entry);
if (isAppSwitchKeyEvent(keyEntry)) {
if (keyEntry.action == AKEY_EVENT_ACTION_DOWN) {
mAppSwitchSawKeyDown = true;
} else if (keyEntry.action == AKEY_EVENT_ACTION_UP) {
// app 切換按鍵抬起時(shí),需要做如下事情
// 計(jì)算切換超時(shí)時(shí)間
// 需要立即喚醒 InputDispatcher 線程來(lái)處理,因?yàn)檫@個(gè)事件很重要
if (mAppSwitchSawKeyDown) {
mAppSwitchDueTime = keyEntry.eventTime + APP_SWITCH_TIMEOUT;
mAppSwitchSawKeyDown = false;
// 需要喚醒線程,立即處理按鍵事件
needWake = true;
}
}
}
break;
}
// ...
}
// 返回值表明是否需要喚醒 InputDispatcher 線程
return needWake;
}
bool InputDispatcher::isAppSwitchKeyEvent(const KeyEntry& keyEntry) {
return !(keyEntry.flags & AKEY_EVENT_FLAG_CANCELED) && isAppSwitchKeyCode(keyEntry.keyCode) &&
(keyEntry.policyFlags & POLICY_FLAG_TRUSTED) &&
(keyEntry.policyFlags & POLICY_FLAG_PASS_TO_USER);
}
// AKEYCODE_HOME 是 HOME 按鍵,AKEYCODE_APP_SWITCH 是 RECENTS 按鍵
static bool isAppSwitchKeyCode(int32_t keyCode) {
return keyCode == AKEYCODE_HOME || keyCode == AKEYCODE_ENDCALL ||
keyCode == AKEYCODE_APP_SWITCH;
}
InputDispatcher::mInboundQueue 是 InputDispatcher 的事件收件箱,所有的事件,包括注入事件,都會(huì)加入這個(gè)收件箱。
如果收件箱之前沒(méi)有"郵件",當(dāng)接收到"郵件"后,就需要喚醒 InputDispatcher 線程來(lái)處理"郵件",這個(gè)邏輯很合理吧?
另外,聊一下這里提到的 app switch 按鍵。從上面的代碼可知,HOME, RECENT, ENDCALL 按鍵都是 app switch 按鍵。當(dāng) app switch 按鍵抬起時(shí),會(huì)計(jì)算一個(gè)超時(shí)時(shí)間,并且立即喚醒 InputDispatcher 線程來(lái)處理事件,因?yàn)檫@個(gè)事件很重要,需要及時(shí)處理,但是處理時(shí)間也不能太長(zhǎng),因此需要設(shè)置一個(gè)超時(shí)時(shí)間。
為何要給 app switch 按鍵設(shè)置一個(gè)超時(shí)時(shí)間? 假如我在操作一個(gè)界面,此時(shí)由于某些原因,例如 CPU 占用率過(guò)高,導(dǎo)致界面事件處理比較緩慢,也就是常說(shuō)的卡頓現(xiàn)象。此時(shí)我覺(jué)得這個(gè) app 太渣了,想殺掉它,怎么辦呢? 按下導(dǎo)航欄的 RECENT 按鍵,然后干掉它。但是由于界面處理事件比較緩慢,因此 RECENT 按鍵事件可能不能得到及時(shí)處理,這就會(huì)讓我很惱火,我很可能扔掉這個(gè)手機(jī)。因此需要給 app switch 按鍵設(shè)置一個(gè)超時(shí)時(shí)間,如果超時(shí)了,那么就會(huì)丟棄 app switch 按鍵之前的所有事件,來(lái)讓 app switch 事件得到及時(shí)的處理。
2. InputDispatcher 處理按鍵事件
現(xiàn)在收件箱已 InputDispatcher::mInboundQueue 已經(jīng)收到了按鍵事件,那么來(lái)看下 InputDisaptcher 線程如何處理按鍵事件的。由前面的文章可知,InputDisaptcher 線程循環(huán)的代碼如下
void InputDispatcher::dispatchOnce() {
nsecs_t nextWakeupTime = LONG_LONG_MAX;
{ // acquire lock
std::scoped_lock _l(mLock);
mDispatcherIsAlive.notify_all();
// 1. 如果沒(méi)有命令,分發(fā)一次事件
if (!haveCommandsLocked()) {
dispatchOnceInnerLocked(&nextWakeupTime);
}
// 2. 執(zhí)行命令,并且立即喚醒線程
// 這個(gè)命令來(lái)自于前一步的事件分發(fā)
if (runCommandsLockedInterruptible()) {
nextWakeupTime = LONG_LONG_MIN;
}
// 3. 處理 ANR ,并返回下一次線程喚醒的時(shí)間。
const nsecs_t nextAnrCheck = processAnrsLocked();
nextWakeupTime = std::min(nextWakeupTime, nextAnrCheck);
if (nextWakeupTime == LONG_LONG_MAX) {
mDispatcherEnteredIdle.notify_all();
}
} // release lock
// Wait for callback or timeout or wake. (make sure we round up, not down)
nsecs_t currentTime = now();
int timeoutMillis = toMillisecondTimeoutDelay(currentTime, nextWakeupTime);
// 4. 線程休眠 timeoutMillis 毫秒
// 注意,休眠的過(guò)程可能會(huì)被打破
// 例如,窗口返回處理事件的結(jié)果時(shí),會(huì)被喚醒
// 又例如,收件箱接收到了事件,也會(huì)被喚醒
mLooper->pollOnce(timeoutMillis);
}
InputDispatcher 的一次線程循環(huán),做了如下幾件事
- 執(zhí)行一次事件分發(fā)。其實(shí)就是從收件箱中獲取一個(gè)事件進(jìn)行分發(fā)。注意,此過(guò)程只分發(fā)一個(gè)事件。也就是說(shuō),線程循環(huán)一次,只處理了一個(gè)事件。參考【2.1 分發(fā)事件】
- 執(zhí)行命令。 這個(gè)命令是哪里來(lái)的呢?是上一步事件分發(fā)中產(chǎn)生的。事件在發(fā)送給窗口前,會(huì)執(zhí)行一次分發(fā)策略查詢,而這個(gè)查詢的方式就是創(chuàng)建一個(gè)命令來(lái)執(zhí)行。
- 處理 ANR,并返回下一次線程喚醒的時(shí)間。窗口在接收到事件后,需要在規(guī)定的時(shí)間內(nèi)處理,否則會(huì)發(fā)生 ANR。這里利用 ANR 的超時(shí)時(shí)間計(jì)算線程下次喚醒的時(shí)間,以便能及時(shí)處理 ANR。
- 線程休眠。線程被喚醒有很多種可能,例如窗口及時(shí)地返回了事件的處理結(jié)果,或者窗口處理事件超時(shí)了。
2.1 分發(fā)事件
void InputDispatcher::dispatchOnceInnerLocked(nsecs_t* nextWakeupTime) {
nsecs_t currentTime = now();
// Reset the key repeat timer whenever normal dispatch is suspended while the
// device is in a non-interactive state. This is to ensure that we abort a key
// repeat if the device is just coming out of sleep.
// 系統(tǒng)沒(méi)有啟動(dòng)完成,或者正在關(guān)機(jī),mDispatchEnabled 為 false
if (!mDispatchEnabled) {
// 重置生成重復(fù)按鍵的計(jì)時(shí)
resetKeyRepeatLocked();
}
// Activity 發(fā)生旋轉(zhuǎn)時(shí),會(huì)凍結(jié)
if (mDispatchFrozen) {
// 被凍結(jié)時(shí),事件不會(huì)執(zhí)行分發(fā),等到被解凍后,再執(zhí)行分發(fā)
return;
}
// 判斷 app 切換是否超時(shí)
bool isAppSwitchDue = mAppSwitchDueTime <= currentTime;
// 如果下次線程喚醒的時(shí)間大于app切換超時(shí)時(shí)間,那么下次喚醒時(shí)間需要重置為app切換超時(shí)時(shí)間
// 以便處理app切換超時(shí)的問(wèn)題
if (mAppSwitchDueTime < *nextWakeupTime) {
*nextWakeupTime = mAppSwitchDueTime;
}
// mPendingEvent 表示正在處理的事件
if (!mPendingEvent) {
if (mInboundQueue.empty()) { // 收件箱為空
// 收件箱為空,并且發(fā)生了 app 切換超時(shí)
// 也就是說(shuō),目前只有一個(gè) app 切換按鍵事件,并且還超時(shí)了
// 處理這種情況很簡(jiǎn)單,就是重置狀態(tài)即可,因此沒(méi)有其他事件需要丟棄
if (isAppSwitchDue) {
// The inbound queue is empty so the app switch key we were waiting
// for will never arrive. Stop waiting for it.
resetPendingAppSwitchLocked(false);
isAppSwitchDue = false;
}
// Synthesize a key repeat if appropriate.
// 這里處理的情況是,輸入設(shè)備不支持重復(fù)按鍵的生成,那么當(dāng)用戶按下一個(gè)按鍵后,長(zhǎng)時(shí)間不松手,因此就需要合成一個(gè)重復(fù)按鍵事件
if (mKeyRepeatState.lastKeyEntry) {
if (currentTime >= mKeyRepeatState.nextRepeatTime) {
// 合成一個(gè)重復(fù)按鍵事件給 mPendingEvent
mPendingEvent = synthesizeKeyRepeatLocked(currentTime);
} else {
if (mKeyRepeatState.nextRepeatTime < *nextWakeupTime) {
*nextWakeupTime = mKeyRepeatState.nextRepeatTime;
}
}
}
// app
// Nothing to do if there is no pending event.
// 如果此時(shí) mPendingEvent 還是為 null,那么表示真的沒(méi)有事件需要處理,
// 因此此次的分發(fā)循環(huán)就結(jié)束了
if (!mPendingEvent) {
return;
}
} else {
// 1. 從收件箱中取出事件
// mPendingEvent 表示正在處理的事件
mPendingEvent = mInboundQueue.front();
mInboundQueue.pop_front();
traceInboundQueueLengthLocked();
}
// 如果這個(gè)事件需要傳遞給用戶,那么需要通知上層的 PowerManagerService,此時(shí)有用戶行為,
// 例如,按下音量鍵,可以延長(zhǎng)亮屏的時(shí)間
if (mPendingEvent->policyFlags & POLICY_FLAG_PASS_TO_USER) {
pokeUserActivityLocked(*mPendingEvent);
}
}
// Now we have an event to dispatch.
// All events are eventually dequeued and processed this way, even if we intend to drop them.
ALOG_ASSERT(mPendingEvent != nullptr);
bool done = false;
// 如果事件需要被丟棄,那么丟棄的原因保存到 dropReason
DropReason dropReason = DropReason::NOT_DROPPED;
if (!(mPendingEvent->policyFlags & POLICY_FLAG_PASS_TO_USER)) {
// 事件被截?cái)嗖呗越財(cái)嗔?
dropReason = DropReason::POLICY;
} else if (!mDispatchEnabled) {
// 系統(tǒng)沒(méi)有啟動(dòng)完成,或者正在關(guān)機(jī)
dropReason = DropReason::DISABLED;
}
if (mNextUnblockedEvent == mPendingEvent) {
mNextUnblockedEvent = nullptr;
}
switch (mPendingEvent->type) {
// ...
case EventEntry::Type::KEY: {
std::shared_ptr<KeyEntry> keyEntry = std::static_pointer_cast<KeyEntry>(mPendingEvent);
if (isAppSwitchDue) { // app 切換超時(shí)
if (isAppSwitchKeyEvent(*keyEntry)) {
resetPendingAppSwitchLocked(true);
isAppSwitchDue = false;
} else if (dropReason == DropReason::NOT_DROPPED) {
// app switch 事件超時(shí),導(dǎo)致事件被丟棄
dropReason = DropReason::APP_SWITCH;
}
}
// 按鍵事件發(fā)生在10秒之前,丟棄
if (dropReason == DropReason::NOT_DROPPED && isStaleEvent(currentTime, *keyEntry)) {
dropReason = DropReason::STALE;
}
// mNextUnblockedEvent 與觸摸事件有關(guān)
// 舉一個(gè)例子,如果有兩個(gè)窗口,當(dāng)?shù)谝粋€(gè)窗口無(wú)響應(yīng)時(shí),如果用戶此時(shí)操作第二個(gè)窗口
// 系統(tǒng)需要及時(shí)把事件發(fā)送給第二個(gè)窗口,因?yàn)榇藭r(shí)第二個(gè)窗口是一個(gè)焦點(diǎn)窗口
// 那么就需要系統(tǒng)把無(wú)響應(yīng)窗口的事件丟棄,以免影響第二個(gè)窗口事件的分發(fā)
if (dropReason == DropReason::NOT_DROPPED && mNextUnblockedEvent) {
dropReason = DropReason::BLOCKED;
}
// 2. 分發(fā)按鍵事件
done = dispatchKeyLocked(currentTime, keyEntry, &dropReason, nextWakeupTime);
break;
}
// ...
}
// 3. 處理事件分發(fā)的結(jié)果
// done 為 true,有兩種情況,一種是事件已經(jīng)發(fā)送給指定窗口,二是事件已經(jīng)被丟棄
// done 為 false,表示暫時(shí)不止如何處理這個(gè)事件,組合鍵的第一個(gè)按鍵按下時(shí),就是其中一種情況
if (done) {
// 處理事件被丟棄的情況
if (dropReason != DropReason::NOT_DROPPED) {
// 這里處理的一種情況是,如果窗口收到 DOWN 事件,但是 UP 事件由于某種原因被丟棄,那么需要補(bǔ)發(fā)一個(gè) CANCEL 事件
dropInboundEventLocked(*mPendingEvent, dropReason);
}
mLastDropReason = dropReason;
// 無(wú)論事件發(fā)送給窗口,或者丟棄,都表示事件被處理了,因此重置 mPendingEvent
releasePendingEventLocked();
// 既然當(dāng)前事件已經(jīng)處理完,那么立即喚醒,處理下一個(gè)事件
*nextWakeupTime = LONG_LONG_MIN; // force next poll to wake up immediately
}
}
InputDispatcher 線程的一次事件分發(fā)的過(guò)程如下
- 從收件箱取出事件。
- 分發(fā)事件。參考【3. 按鍵事件的分發(fā)】
- 處理事件分發(fā)后的結(jié)果。 事件被丟棄或者發(fā)送給指定窗口,都會(huì)返回 true,表示事件被處理了,因此會(huì)重置 mPendingEvent。而如果事件分發(fā)的結(jié)果返回 false,表示事件沒(méi)有被處理,這種情況表示系統(tǒng)暫時(shí)不知道如何處理,最常見(jiàn)的情況就是組合鍵的第一個(gè)按鍵被按下,例如截屏鍵的 power 鍵按下,此時(shí)系統(tǒng)不知道是不是要單獨(dú)處理這個(gè)按鍵,還要等待組合鍵的另外一個(gè)按鍵,在超時(shí)前按下,因此系統(tǒng)不知道如何處理,需要等等看。
3. 按鍵事件的分發(fā)
bool InputDispatcher::dispatchKeyLocked(nsecs_t currentTime, std::shared_ptr<KeyEntry> entry,
DropReason* dropReason, nsecs_t* nextWakeupTime) {
// Preprocessing.
if (!entry->dispatchInProgress) {
// ...省略生成重復(fù)按鍵的代碼...
// 表明事件處于分發(fā)中
entry->dispatchInProgress = true;
logOutboundKeyDetails("dispatchKey - ", *entry);
}
// 分發(fā)策略讓我們稍后再試,這是為了等待另外一個(gè)組合鍵的按鍵事件到來(lái)
if (entry->interceptKeyResult == KeyEntry::INTERCEPT_KEY_RESULT_TRY_AGAIN_LATER) {
// 還沒(méi)到等待的超時(shí)時(shí)間,那么繼續(xù)等待
if (currentTime < entry->interceptKeyWakeupTime) {
if (entry->interceptKeyWakeupTime < *nextWakeupTime) {
*nextWakeupTime = entry->interceptKeyWakeupTime;
}
return false; // wait until next wakeup
}
// 這里表示已經(jīng)超時(shí)了,因此需要再次詢問(wèn)分發(fā)策略,看看結(jié)果
// 例如,當(dāng)截屏的power鍵超時(shí)時(shí),再次詢問(wèn)分發(fā)策略是否音量下鍵已經(jīng)按下,如果按下了,
// 那么這個(gè) power 事件就不再分發(fā)給用戶
entry->interceptKeyResult = KeyEntry::INTERCEPT_KEY_RESULT_UNKNOWN;
entry->interceptKeyWakeupTime = 0;
}
// Give the policy a chance to intercept the key.
if (entry->interceptKeyResult == KeyEntry::INTERCEPT_KEY_RESULT_UNKNOWN) {
// 1. 如果事件需要分發(fā)給用戶,那么先查詢分發(fā)策略
if (entry->policyFlags & POLICY_FLAG_PASS_TO_USER) {
if (INPUTDISPATCHER_SKIP_EVENT_KEY != 0) {
if(entry->keyCode == 0 && entry->scanCode == INPUTDISPATCHER_SKIP_EVENT_KEY) {
entry->interceptKeyResult = KeyEntry::INTERCEPT_KEY_RESULT_SKIP;
*dropReason = DropReason::POLICY;
ALOGI("Intercepted the key %i", INPUTDISPATCHER_SKIP_EVENT_KEY);
return true;
}
}
// 創(chuàng)建一個(gè)命令
std::unique_ptr<CommandEntry> commandEntry = std::make_unique<CommandEntry>(
&InputDispatcher::doInterceptKeyBeforeDispatchingLockedInterruptible);
sp<IBinder> focusedWindowToken =
mFocusResolver.getFocusedWindowToken(getTargetDisplayId(*entry));
commandEntry->connectionToken = focusedWindowToken;
commandEntry->keyEntry = entry;
// mCommandQueue 中加入一個(gè)命令
postCommandLocked(std::move(commandEntry));
// 返回 false,表示需要運(yùn)行命令看看這個(gè)事件是否需要觸發(fā)組合鍵的功能
return false; // wait for the command to run
} else {
// 如果事件不傳遞給用戶,那么不會(huì)查詢分發(fā)策略是否截?cái)啵亲约航又幚?,后面?huì)丟棄它
entry->interceptKeyResult = KeyEntry::INTERCEPT_KEY_RESULT_CONTINUE;
}
} else if (entry->interceptKeyResult == KeyEntry::INTERCEPT_KEY_RESULT_SKIP) {
// 查詢分發(fā)策略得到的結(jié)果是讓我們跳過(guò)這個(gè)事件,不處理
// 其中一種情況是,組合鍵的另外一個(gè)按鍵被消費(fèi)了,因此是一個(gè)無(wú)效事件,讓我們丟棄它
// 另外一種情況是,分發(fā)策略直接消費(fèi)了這個(gè)事件,讓我們不要聲張,丟棄它
if (*dropReason == DropReason::NOT_DROPPED) {
*dropReason = DropReason::POLICY;
}
}
// Clean up if dropping the event.
// 如果事件有足夠的原因需要被丟棄,那么不執(zhí)行后面的事件分發(fā),而是直接保存事件注入的結(jié)果
if (*dropReason != DropReason::NOT_DROPPED) {
setInjectionResult(*entry,
*dropReason == DropReason::POLICY ? InputEventInjectionResult::SUCCEEDED
: InputEventInjectionResult::FAILED);
mReporter->reportDroppedKey(entry->id);
return true;
}
// Identify targets.
// 2. 找到目標(biāo)輸入窗口,保存到 inputTargets
std::vector<InputTarget> inputTargets;
InputEventInjectionResult injectionResult =
findFocusedWindowTargetsLocked(currentTime, *entry, inputTargets, nextWakeupTime);
// 處理 InputEventInjectionResult::PENDING 結(jié)果
// 表示現(xiàn)在處理事件的時(shí)機(jī)不成熟,例如窗口還在啟動(dòng)中,那么直接結(jié)束此時(shí)的事件分發(fā),等待時(shí)機(jī)合適再處理
if (injectionResult == InputEventInjectionResult::PENDING) {
// 返回 false,那么會(huì)導(dǎo)致線程休眠一段時(shí)間,等再次喚醒時(shí),再來(lái)處理事件
return false;
}
// 保存注入結(jié)果
setInjectionResult(*entry, injectionResult);
// 處理 InputEventInjectionResult::FAILED 和 InputEventInjectionResult::PERMISSION_DENIED 結(jié)果
// 表示沒(méi)有找到事件的輸入目標(biāo)窗口
if (injectionResult != InputEventInjectionResult::SUCCEEDED) {
// 返回 true,那么事件即將被丟棄
return true;
}
// 走到這里,表示成功找到焦點(diǎn)窗口
// Add monitor channels from event's or focused display.
// 添加監(jiān)聽(tīng)所有事件的通道
// TODO:這個(gè)暫時(shí)不知道有何用
addGlobalMonitoringTargetsLocked(inputTargets, getTargetDisplayId(*entry));
// Dispatch the key.
// 處理 InputEventInjectionResult::SUCCEEDED 結(jié)果,表明找到了事件輸入目標(biāo)
// 3. 事件分發(fā)按鍵給目標(biāo)窗口
dispatchEventLocked(currentTime, entry, inputTargets);
return true;
}
按鍵事件分發(fā)的主要過(guò)程如下
- 執(zhí)行分發(fā)策略。分發(fā)策略的作用,一方面是實(shí)現(xiàn)組合按鍵的功能,另外一方面是為了在事件分發(fā)給窗口前,給系統(tǒng)一個(gè)優(yōu)先處理的機(jī)會(huì)。
- 尋找處理按鍵事件的焦點(diǎn)窗口。參考【3.1 尋找焦點(diǎn)窗口】
- 只有成功尋找到焦點(diǎn)窗口,才進(jìn)行按鍵事件分發(fā)。參考【3.2 分發(fā)按鍵事件給目標(biāo)窗口】
分發(fā)策略涉及到組合按鍵的實(shí)現(xiàn),因此是一個(gè)非常復(fù)雜的話題,我們將在后面的文章中,把它和截?cái)嗖呗砸黄鸱治觥?/p>
3.1 尋找焦點(diǎn)窗口
InputEventInjectionResult InputDispatcher::findFocusedWindowTargetsLocked(
nsecs_t currentTime, const EventEntry& entry, std::vector<InputTarget>& inputTargets,
nsecs_t* nextWakeupTime) {
std::string reason;
int32_t displayId = getTargetDisplayId(entry);
// 1. 獲取焦點(diǎn)窗口
sp<WindowInfoHandle> focusedWindowHandle = getFocusedWindowHandleLocked(displayId);
// 獲取焦點(diǎn)app
std::shared_ptr<InputApplicationHandle> focusedApplicationHandle =
getValueByKey(mFocusedApplicationHandlesByDisplay, displayId);
// 沒(méi)有焦點(diǎn)窗口,也沒(méi)有焦點(diǎn)app,那么丟棄事件
if (focusedWindowHandle == nullptr && focusedApplicationHandle == nullptr) {
ALOGI("Dropping %s event because there is no focused window or focused application in "
"display %" PRId32 ".",
NamedEnum::string(entry.type).c_str(), displayId);
return InputEventInjectionResult::FAILED;
}
// Drop key events if requested by input feature
// 窗口feature為 DROP_INPUT 或 DROP_INPUT_IF_OBSCURED,那么丟棄事件
if (focusedWindowHandle != nullptr && shouldDropInput(entry, focusedWindowHandle)) {
return InputEventInjectionResult::FAILED;
}
// 沒(méi)有焦點(diǎn)窗口,但是有焦點(diǎn)app
// 這里處理的情況是,app正在啟動(dòng),但是還沒(méi)有顯示即將獲得焦點(diǎn)的窗口
if (focusedWindowHandle == nullptr && focusedApplicationHandle != nullptr) {
if (!mNoFocusedWindowTimeoutTime.has_value()) {
// 啟動(dòng)一個(gè) ANR 計(jì)時(shí)器,超時(shí)時(shí)間默認(rèn)5秒
std::chrono::nanoseconds timeout = focusedApplicationHandle->getDispatchingTimeout(
DEFAULT_INPUT_DISPATCHING_TIMEOUT);
mNoFocusedWindowTimeoutTime = currentTime + timeout.count();
// 保存正在等待焦點(diǎn)窗口的app
mAwaitedFocusedApplication = focusedApplicationHandle;
mAwaitedApplicationDisplayId = displayId;
ALOGW("Waiting because no window has focus but %s may eventually add a "
"window when it finishes starting up. Will wait for %" PRId64 "ms",
mAwaitedFocusedApplication->getName().c_str(), millis(timeout));
// 線程喚醒時(shí)間修改為超時(shí)時(shí)間,以保證能及時(shí)處理 ANR
*nextWakeupTime = *mNoFocusedWindowTimeoutTime;
// 由于焦點(diǎn)窗口正在啟動(dòng),暫時(shí)不處理事件
return InputEventInjectionResult::PENDING;
} else if (currentTime > *mNoFocusedWindowTimeoutTime) {
// Already raised ANR. Drop the event
ALOGE("Dropping %s event because there is no focused window",
NamedEnum::string(entry.type).c_str());
// 等待焦點(diǎn)窗口超時(shí),丟棄這個(gè)事件
return InputEventInjectionResult::FAILED;
} else {
// Still waiting for the focused window
// 等待焦點(diǎn)窗口還沒(méi)有超時(shí),繼續(xù)等待,暫時(shí)不處理事件
return InputEventInjectionResult::PENDING;
}
}
// 走到這里,表示已經(jīng)有了一個(gè)有效的焦點(diǎn)窗口
// we have a valid, non-null focused window
// 因?yàn)橛辛擞行Ы裹c(diǎn)窗口,重置 mNoFocusedWindowTimeoutTime 和 mAwaitedFocusedApplication
resetNoFocusedWindowTimeoutLocked();
// 對(duì)于注入事件,如果注入者的 UID 與窗口所屬的 UDI 不同,并且注入者沒(méi)有 android.Manifest.permission.INJECT_EVENTS 權(quán)限
// 那么注入事件將會(huì)被丟棄
if (!checkInjectionPermission(focusedWindowHandle, entry.injectionState)) {
return InputEventInjectionResult::PERMISSION_DENIED;
}
// 窗口處于暫停狀態(tài),暫時(shí)不處理當(dāng)前按鍵事件
if (focusedWindowHandle->getInfo()->paused) {
ALOGI("Waiting because %s is paused", focusedWindowHandle->getName().c_str());
return InputEventInjectionResult::PENDING;
}
// 如果前面還有事件沒(méi)有處理完畢,那么需要等待前面事件處理完畢,才能發(fā)送按鍵事件
// 因?yàn)榍懊娴氖录?,可能影響焦點(diǎn)窗口,所以按鍵事件需要等待前面事件處理完畢才能發(fā)送
if (entry.type == EventEntry::Type::KEY) {
if (shouldWaitToSendKeyLocked(currentTime, focusedWindowHandle->getName().c_str())) {
*nextWakeupTime = *mKeyIsWaitingForEventsTimeout;
// 前面有時(shí)間沒(méi)有處理完畢,因此暫不處理當(dāng)前的按鍵事件
return InputEventInjectionResult::PENDING;
}
}
// Success! Output targets.
// 走到這里,表示事件可以成功發(fā)送焦點(diǎn)窗口
// 2. 根據(jù)焦點(diǎn)窗口創(chuàng)建 InputTarget,并保存到參數(shù) inputTargets
// 注意第二個(gè)參數(shù),后面把事件加入到一個(gè)輸入通道鏈接的收件箱時(shí),會(huì)用到
addWindowTargetLocked(focusedWindowHandle,
InputTarget::FLAG_FOREGROUND | InputTarget::FLAG_DISPATCH_AS_IS,
BitSet32(0), inputTargets);
// Done.
return InputEventInjectionResult::SUCCEEDED;
}
尋找目標(biāo)窗口的過(guò)程其實(shí)就是找到焦點(diǎn)窗口,然后根據(jù)焦點(diǎn)窗口創(chuàng)建 InputTarget,保存到參數(shù) inputTargets 中。
結(jié)合前面的代碼分析,尋找焦點(diǎn)窗口返回的結(jié)果,會(huì)影響事件的處理,總結(jié)如下
| 尋找焦點(diǎn)窗口的結(jié)果 | 結(jié)果的說(shuō)明 | 如何影響事件的處理 |
|---|---|---|
| InputEventInjectionResult::SUCCEEDED | 成功為事件找到焦點(diǎn)窗口 | 事件會(huì)被分發(fā)到焦點(diǎn)窗口 |
| InputEventInjectionResult::FAILED | 沒(méi)有找到可用的焦點(diǎn)窗口 | 事件會(huì)被丟棄 |
| InputEventInjectionResult::PERMISSION_DENIED | 沒(méi)有權(quán)限把事件發(fā)送到焦點(diǎn)窗口 | 事件會(huì)被丟棄 |
| InputEventInjectionResult::PENDING | 有焦點(diǎn)窗口,但是暫時(shí)不可用于接收事件 | 線程會(huì)休眠,等待時(shí)機(jī)被喚醒,發(fā)送事件到焦點(diǎn)窗口 |
在工作中,有時(shí)候需要我們分析按鍵事件為何沒(méi)有找到焦點(diǎn)窗口,這里列舉一下所有的情況,以供大家工作或面試時(shí)使用
- 沒(méi)有焦點(diǎn)app,并且沒(méi)有焦點(diǎn)窗口。這種情況應(yīng)該比較極端,應(yīng)該整個(gè)surface系統(tǒng)都出問(wèn)題了。
- 窗口的 Feature 表示要丟棄事件。這個(gè)丟棄事件的 Feature 是 Surface 系統(tǒng)給窗口設(shè)置的,目前我還沒(méi)有搞清楚這里面的邏輯。
- 焦點(diǎn)app啟動(dòng)焦點(diǎn)窗口,超時(shí)了。
- 對(duì)于注入事件,如果注入者的 UID 與焦點(diǎn)窗口的 UID 不同,并且注入者沒(méi)有申請(qǐng) android.Manifest.permission.INJECT_EVENTS 權(quán)限。
沒(méi)有找到焦點(diǎn)窗口的所有情況,都有日志對(duì)應(yīng)輸出,可幫助我們定位問(wèn)題。
現(xiàn)在來(lái)看一下,找到焦點(diǎn)窗口后,創(chuàng)建并保存 InputTarget 的過(guò)程
// 注意,參數(shù) targetFlags 的值為 InputTarget::FLAG_FOREGROUND | InputTarget::FLAG_DISPATCH_AS_IS
// InputTarget::FLAG_FOREGROUND 表示事件正在發(fā)送給前臺(tái)窗口
// InputTarget::FLAG_DISPATCH_AS_IS 表示事件不加工,直接按照原樣進(jìn)行發(fā)送
void InputDispatcher::addWindowTargetLocked(const sp<WindowInfoHandle>& windowHandle,
int32_t targetFlags, BitSet32 pointerIds,
std::vector<InputTarget>& inputTargets) {
std::vector<InputTarget>::iterator it =
std::find_if(inputTargets.begin(), inputTargets.end(),
[&windowHandle](const InputTarget& inputTarget) {
return inputTarget.inputChannel->getConnectionToken() ==
windowHandle->getToken();
});
const WindowInfo* windowInfo = windowHandle->getInfo();
if (it == inputTargets.end()) {
// 創(chuàng)建 InputTarget
InputTarget inputTarget;
// 獲取窗口通道
std::shared_ptr<InputChannel> inputChannel =
getInputChannelLocked(windowHandle->getToken());
if (inputChannel == nullptr) {
ALOGW("Window %s already unregistered input channel", windowHandle->getName().c_str());
return;
}
// 保存輸入通道,通過(guò)這個(gè)通道,事件才能發(fā)送給指定窗口
inputTarget.inputChannel = inputChannel;
// 注意,值為 InputTarget::FLAG_FOREGROUND | InputTarget::FLAG_DISPATCH_AS_IS
inputTarget.flags = targetFlags;
inputTarget.globalScaleFactor = windowInfo->globalScaleFactor;
inputTarget.displayOrientation = windowInfo->displayOrientation;
inputTarget.displaySize =
int2(windowHandle->getInfo()->displayWidth, windowHandle->getInfo()->displayHeight);
// 保存到 inputTargets中
inputTargets.push_back(inputTarget);
it = inputTargets.end() - 1;
}
ALOG_ASSERT(it->flags == targetFlags);
ALOG_ASSERT(it->globalScaleFactor == windowInfo->globalScaleFactor);
// InputTarget 保存窗口的 Transform 信息,這會(huì)把顯示屏的坐標(biāo),轉(zhuǎn)換到窗口的坐標(biāo)系上
// 對(duì)于按鍵事件,不需要把顯示屏坐標(biāo)轉(zhuǎn)換到窗口坐標(biāo)
// 因此,對(duì)于按鍵事件,pointerIds 為0,這里只是簡(jiǎn)單保存一個(gè)默認(rèn)的 Transfrom 而已
it->addPointers(pointerIds, windowInfo->transform);
}
3.2 分發(fā)按鍵事件給目標(biāo)窗口
現(xiàn)在,處理按鍵事件的焦點(diǎn)窗口已經(jīng)找到,并且已經(jīng)保存到 inputTargets,是時(shí)候來(lái)分發(fā)按鍵事件了
void InputDispatcher::dispatchEventLocked(nsecs_t currentTime,
std::shared_ptr<EventEntry> eventEntry,
const std::vector<InputTarget>& inputTargets) {
updateInteractionTokensLocked(*eventEntry, inputTargets);
pokeUserActivityLocked(*eventEntry);
for (const InputTarget& inputTarget : inputTargets) {
// 獲取目標(biāo)窗口的連接
sp<Connection> connection =
getConnectionLocked(inputTarget.inputChannel->getConnectionToken());
if (connection != nullptr) {
// 準(zhǔn)備分發(fā)循環(huán)
prepareDispatchCycleLocked(currentTime, connection, eventEntry, inputTarget);
} else {
if (DEBUG_FOCUS) {
ALOGD("Dropping event delivery to target with channel '%s' because it "
"is no longer registered with the input dispatcher.",
inputTarget.inputChannel->getName().c_str());
}
}
}
}
焦點(diǎn)窗口只有一個(gè),為何需要一個(gè) inputTargets 集合來(lái)保存所有的目標(biāo)窗口,因?yàn)楦鶕?jù)前面的分析,除了焦點(diǎn)窗口以外,還有一個(gè)全局的監(jiān)聽(tīng)事件的輸入目標(biāo)。
WindowManagerService 會(huì)在創(chuàng)建窗口時(shí),創(chuàng)建一個(gè)連接,其中一端給窗口,另外一端給輸入系統(tǒng)。當(dāng)輸入系統(tǒng)需要發(fā)送事件給窗口時(shí),就會(huì)通過(guò)這個(gè)連接進(jìn)行發(fā)送。至于連接的建立過(guò)程,有點(diǎn)小復(fù)雜,本分不分析,后面如果寫 WMS 的文章,再來(lái)細(xì)致分析一次。
找到這個(gè)窗口的連接后,就準(zhǔn)備分發(fā)循環(huán) ? 問(wèn)題來(lái)了,什么是分發(fā)循環(huán) ? InputDispatcher 把一個(gè)事件發(fā)送給窗口,窗口處理完事件,然后返回結(jié)果為 InputDispatcher,這就是一個(gè)循環(huán)。但是注意,分發(fā)事件給窗口,窗口返回處理事件結(jié)果,這兩個(gè)是互為異步過(guò)程。
現(xiàn)在來(lái)看下分發(fā)循環(huán)之前的準(zhǔn)備
void InputDispatcher::prepareDispatchCycleLocked(nsecs_t currentTime,
const sp<Connection>& connection,
std::shared_ptr<EventEntry> eventEntry,
const InputTarget& inputTarget) {
// ...
// 連接處理異常狀態(tài),丟棄事件
if (connection->status != Connection::STATUS_NORMAL) {
#if DEBUG_DISPATCH_CYCLE
ALOGD("channel '%s' ~ Dropping event because the channel status is %s",
connection->getInputChannelName().c_str(), connection->getStatusLabel());
#endif
return;
}
// Split a motion event if needed.
// 針對(duì)觸摸事件的split
if (inputTarget.flags & InputTarget::FLAG_SPLIT) {
// ...
}
// Not splitting. Enqueue dispatch entries for the event as is.
// 把事件加入到連接的發(fā)件箱中,然后啟動(dòng)分發(fā)循環(huán)
enqueueDispatchEntriesLocked(currentTime, connection, eventEntry, inputTarget);
}
void InputDispatcher::enqueueDispatchEntriesLocked(nsecs_t currentTime,
const sp<Connection>& connection,
std::shared_ptr<EventEntry> eventEntry,
const InputTarget& inputTarget) {
// ...
bool wasEmpty = connection->outboundQueue.empty();
// Enqueue dispatch entries for the requested modes.
// 1. 保存事件到連接的發(fā)件箱 Connection::outboundQueue
// 注意最后一個(gè)參數(shù),它的窗口的分發(fā)模式,定義了事件如何分發(fā)到指定窗口
// 根據(jù)前面的代碼分析,目前保存的目標(biāo)窗口的分發(fā)模式只支持下面列舉的 InputTarget::FLAG_DISPATCH_AS_IS
// InputTarget::FLAG_DISPATCH_AS_IS 表示事件按照原樣進(jìn)行發(fā)送
enqueueDispatchEntryLocked(connection, eventEntry, inputTarget,
InputTarget::FLAG_DISPATCH_AS_HOVER_EXIT);
enqueueDispatchEntryLocked(connection, eventEntry, inputTarget,
InputTarget::FLAG_DISPATCH_AS_OUTSIDE);
enqueueDispatchEntryLocked(connection, eventEntry, inputTarget,
InputTarget::FLAG_DISPATCH_AS_HOVER_ENTER);
enqueueDispatchEntryLocked(connection, eventEntry, inputTarget,
InputTarget::FLAG_DISPATCH_AS_IS);
enqueueDispatchEntryLocked(connection, eventEntry, inputTarget,
InputTarget::FLAG_DISPATCH_AS_SLIPPERY_EXIT);
enqueueDispatchEntryLocked(connection, eventEntry, inputTarget,
InputTarget::FLAG_DISPATCH_AS_SLIPPERY_ENTER);
// If the outbound queue was previously empty, start the dispatch cycle going.
// 連接的發(fā)件箱突然有事件了,那得啟動(dòng)分發(fā)循環(huán),把事件發(fā)送到指定窗口
if (wasEmpty && !connection->outboundQueue.empty()) {
// 2. 啟動(dòng)分發(fā)循環(huán)
startDispatchCycleLocked(currentTime, connection);
}
}
分發(fā)循環(huán)前的準(zhǔn)備工作,其實(shí)就是根據(jù)窗口所支持的分發(fā)模式(dispatche mode),調(diào)用enqueueDispatchEntryLocked() 創(chuàng)建并保存事件到連接的收件箱。前面分析過(guò),焦點(diǎn)窗口的的分發(fā)模式為 InputTarget::FLAG_DISPATCH_AS_IS | InputTarget::FLAG_FOREGROUND,而此時(shí)只用到了InputTarget::FLAG_DISPATCH_AS_IS。 參考【3.2.1 根據(jù)分發(fā)模式,添加事件到連接收件箱】
如果連接的收件箱之前沒(méi)有事件,那么證明連接沒(méi)有處于發(fā)送事件的狀態(tài)中,而現(xiàn)在有事件了,那就啟動(dòng)分發(fā)循環(huán)來(lái)發(fā)送事件。參考 【3.2.2 啟動(dòng)分發(fā)循環(huán)】
3.2.1 根據(jù)分發(fā)模式,添加事件到連接收件箱
void InputDispatcher::enqueueDispatchEntryLocked(const sp<Connection>& connection,
std::shared_ptr<EventEntry> eventEntry,
const InputTarget& inputTarget,
int32_t dispatchMode) {
// ...
// 前面保存的 InputTarget,它的 flags 為 InputTarget::FLAG_FOREGROUND | InputTarget::FLAG_DISPATCH_AS_IS
int32_t inputTargetFlags = inputTarget.flags;
// 窗口不支持請(qǐng)求的dispatcher mode,那么不添加事件到連接的發(fā)件箱中
// 對(duì)于按鍵事件,dispatchMode 只能是 InputTarget::FLAG_DISPATCH_AS_IS
if (!(inputTargetFlags & dispatchMode)) {
return;
}
// 1. 為每一個(gè)窗口所支持的 dispatche mode,創(chuàng)建一個(gè) DispatchEntry
inputTargetFlags = (inputTargetFlags & ~InputTarget::FLAG_DISPATCH_MASK) | dispatchMode;
std::unique_ptr<DispatchEntry> dispatchEntry =
createDispatchEntry(inputTarget, eventEntry, inputTargetFlags);
// Use the eventEntry from dispatchEntry since the entry may have changed and can now be a
// different EventEntry than what was passed in.
EventEntry& newEntry = *(dispatchEntry->eventEntry);
// Apply target flags and update the connection's input state.
switch (newEntry.type) {
case EventEntry::Type::KEY: {
const KeyEntry& keyEntry = static_cast<const KeyEntry&>(newEntry);
dispatchEntry->resolvedEventId = keyEntry.id;
dispatchEntry->resolvedAction = keyEntry.action;
dispatchEntry->resolvedFlags = keyEntry.flags;
if (!connection->inputState.trackKey(keyEntry, dispatchEntry->resolvedAction,
dispatchEntry->resolvedFlags)) {
#if DEBUG_DISPATCH_CYCLE
ALOGD("channel '%s' ~ enqueueDispatchEntryLocked: skipping inconsistent key event",
connection->getInputChannelName().c_str());
#endif
return; // skip the inconsistent event
}
break;
}
// ...
}
// Remember that we are waiting for this dispatch to complete.
// 檢測(cè)事件是否正在發(fā)送到前臺(tái)窗應(yīng)用,根據(jù)前面的代碼分析,目標(biāo)窗口的flags包括 FLAG_FOREGROUND
// 因此,條件成立
if (dispatchEntry->hasForegroundTarget()) {
// EventEntry::injectionState::pendingForegroundDispatches +1
incrementPendingForegroundDispatches(newEntry);
}
// 2. 把 DispatchEntry 加入到連接的發(fā)件箱中
connection->outboundQueue.push_back(dispatchEntry.release());
traceOutboundQueueLength(*connection);
}
根據(jù)前面創(chuàng)建 InputTarget 的代碼可知,InputTarget::flags 的值為 InputTarget::FLAG_FOREGROUND | InputTarget::FLAG_DISPATCH_AS_IS。
InputTarget::FLAG_FOREGROUND 表明事件正在發(fā)送給前臺(tái)應(yīng)用,InputTarget::FLAG_DISPATCH_AS_IS 表示事件按照原樣進(jìn)行發(fā)送。
而參數(shù) dispatchMode 只使用了 InputTarget::FLAG_DISPATCH_AS_IS,因此,對(duì)于按鍵事件,只會(huì)創(chuàng)建并添加一個(gè) DispatchEntry 到 Connection::outboundQueue。
3.2.2 啟動(dòng)分發(fā)循環(huán)
現(xiàn)在,焦點(diǎn)窗口連接的發(fā)件箱中已經(jīng)有事件了,此時(shí)真的到了發(fā)送事件給焦點(diǎn)窗口的時(shí)候了
void InputDispatcher::startDispatchCycleLocked(nsecs_t currentTime,
const sp<Connection>& connection) {
// ...
// 遍歷連接發(fā)件箱中的所有事件,逐個(gè)發(fā)送給目標(biāo)窗口
while (connection->status == Connection::STATUS_NORMAL && !connection->outboundQueue.empty()) {
DispatchEntry* dispatchEntry = connection->outboundQueue.front();
dispatchEntry->deliveryTime = currentTime;
// 計(jì)算事件分發(fā)的超時(shí)時(shí)間
const std::chrono::nanoseconds timeout =
getDispatchingTimeoutLocked(connection->inputChannel->getConnectionToken());
dispatchEntry->timeoutTime = currentTime + timeout.count();
// Publish the event.
status_t status;
const EventEntry& eventEntry = *(dispatchEntry->eventEntry);
switch (eventEntry.type) {
case EventEntry::Type::KEY: {
const KeyEntry& keyEntry = static_cast<const KeyEntry&>(eventEntry);
std::array<uint8_t, 32> hmac = getSignature(keyEntry, *dispatchEntry);
// 1. 發(fā)送按鍵事件
status = connection->inputPublisher
.publishKeyEvent(dispatchEntry->seq,
dispatchEntry->resolvedEventId, keyEntry.deviceId,
keyEntry.source, keyEntry.displayId,
std::move(hmac), dispatchEntry->resolvedAction,
dispatchEntry->resolvedFlags, keyEntry.keyCode,
keyEntry.scanCode, keyEntry.metaState,
keyEntry.repeatCount, keyEntry.downTime,
keyEntry.eventTime);
break;
}
// ...
}
// Check the result.
if (status) {
// 發(fā)送異常
if (status == WOULD_BLOCK) {
// ...
}
return;
}
// 走到這里,表示按鍵事件發(fā)送成功
// 2. 按鍵事件發(fā)送成功,那么從連接的發(fā)件箱中移除
connection->outboundQueue.erase(std::remove(connection->outboundQueue.begin(),
connection->outboundQueue.end(),
dispatchEntry));
traceOutboundQueueLength(*connection);
// 3. 把已經(jīng)發(fā)送的事件,加入到連接的等待隊(duì)列中 Connection::waitQueue
// 連接在等待什么呢?當(dāng)然是等到窗口的處理結(jié)果
connection->waitQueue.push_back(dispatchEntry);
// 連接可響應(yīng),那么會(huì)記錄事件處理的超時(shí)時(shí)間,一旦超時(shí),會(huì)引發(fā) ANR
// 因?yàn)槲覀儾豢赡軣o(wú)限等待窗口處理完事件,后面還有好多事件要處理呢
// 4. 用 AnrTracker 記錄事件處理的超時(shí)時(shí)間
if (connection->responsive) {
mAnrTracker.insert(dispatchEntry->timeoutTime,
connection->inputChannel->getConnectionToken());
}
traceWaitQueueLength(*connection);
}
}
事件分發(fā)循環(huán)的過(guò)程如下
- 通過(guò)窗口連接,把事件發(fā)送給窗口,并從連接的發(fā)件箱 Connection::outboundQueue 中移除。
- 把剛剛發(fā)送的事件,保存到連接的等待隊(duì)列 Connection::waitQueue。連接在等待什么呢?當(dāng)然是等到窗口的處理結(jié)果。
- 用 AnrTracker 記錄事件處理的超時(shí)時(shí)間,如果事件處理超時(shí),會(huì)引發(fā) ANR。
既然叫做一個(gè)循環(huán),現(xiàn)在事件已經(jīng)發(fā)送出去了,那么如何接收處理結(jié)果呢? InputDispatcher 線程使用了底層的 Looper 機(jī)制,當(dāng)窗口與輸入系統(tǒng)建立連接時(shí),Looper 通過(guò) epoll 機(jī)制監(jiān)聽(tīng)連接的輸入端的文件描述符,當(dāng)窗口通過(guò)連接反饋處理結(jié)果時(shí),epoll 就會(huì)收到可讀事件,因此 InputDispatcher 線程會(huì)被喚醒來(lái)讀取窗口的事件處理結(jié)果,而這個(gè)過(guò)程就是下面的下面的回調(diào)函數(shù)
如果讀者想了解底層的 Looper 機(jī)制,可以參考我寫的 深入理解Native層消息機(jī)制
int InputDispatcher::handleReceiveCallback(int events, sp<IBinder> connectionToken) {
std::scoped_lock _l(mLock);
// 1. 獲取對(duì)應(yīng)的連接
sp<Connection> connection = getConnectionLocked(connectionToken);
if (connection == nullptr) {
ALOGW("Received looper callback for unknown input channel token %p. events=0x%x",
connectionToken.get(), events);
return 0; // remove the callback
}
bool notify;
if (!(events & (ALOOPER_EVENT_ERROR | ALOOPER_EVENT_HANGUP))) {
if (!(events & ALOOPER_EVENT_INPUT)) {
ALOGW("channel '%s' ~ Received spurious callback for unhandled poll event. "
"events=0x%x",
connection->getInputChannelName().c_str(), events);
return 1;
}
nsecs_t currentTime = now();
bool gotOne = false;
status_t status = OK;
// 通過(guò)一個(gè)無(wú)限循環(huán)讀取,盡可能讀取所有的反饋結(jié)果
for (;;) {
// 2. 讀取窗口的處理結(jié)果
Result<InputPublisher::ConsumerResponse> result =
connection->inputPublisher.receiveConsumerResponse();
if (!result.ok()) {
status = result.error().code();
break;
}
if (std::holds_alternative<InputPublisher::Finished>(*result)) {
const InputPublisher::Finished& finish =
std::get<InputPublisher::Finished>(*result);
// 3. 完成分發(fā)循環(huán)
finishDispatchCycleLocked(currentTime, connection, finish.seq, finish.handled,
finish.consumeTime);
} else if (std::holds_alternative<InputPublisher::Timeline>(*result)) {
// ...
}
gotOne = true;
}
if (gotOne) {
// 4. 執(zhí)行第三步發(fā)送的命令
runCommandsLockedInterruptible();
if (status == WOULD_BLOCK) {
return 1;
}
}
notify = status != DEAD_OBJECT || !connection->monitor;
if (notify) {
ALOGE("channel '%s' ~ Failed to receive finished signal. status=%s(%d)",
connection->getInputChannelName().c_str(), statusToString(status).c_str(),
status);
}
} else {
// ...
}
// Remove the channel.
// 連接的所有事件都發(fā)送完畢了,從 mAnrTracker 和 mConnectionsByToken 移除相應(yīng)的數(shù)據(jù)
// TODO: 為何一定要移除呢?
removeInputChannelLocked(connection->inputChannel->getConnectionToken(), notify);
return 0; // remove the callback
}
處理窗口反饋的事件處理結(jié)果的過(guò)程如下
- 根據(jù)連接的 token 獲取連接。
- 從連接中讀取窗口返回的事件處理結(jié)果。
- 完成這個(gè)事件的分發(fā)循環(huán)。此過(guò)程會(huì)創(chuàng)建一個(gè)命令,并加如到命令隊(duì)列中,然后在第四步執(zhí)行。
- 執(zhí)行第三步創(chuàng)建的命令,以完成分發(fā)循環(huán)。
當(dāng)監(jiān)聽(tīng)到窗口的連接有事件到來(lái)時(shí),會(huì)從連接讀取窗口對(duì)事件的處理結(jié)果,然后創(chuàng)建一個(gè)即將執(zhí)行的命令,保存到命令隊(duì)列中,如下
void InputDispatcher::finishDispatchCycleLocked(nsecs_t currentTime,
const sp<Connection>& connection, uint32_t seq,
bool handled, nsecs_t consumeTime) {
if (connection->status == Connection::STATUS_BROKEN ||
connection->status == Connection::STATUS_ZOMBIE) {
return;
}
// Notify other system components and prepare to start the next dispatch cycle.
onDispatchCycleFinishedLocked(currentTime, connection, seq, handled, consumeTime);
}
void InputDispatcher::onDispatchCycleFinishedLocked(nsecs_t currentTime,
const sp<Connection>& connection, uint32_t seq,
bool handled, nsecs_t consumeTime) {
// 創(chuàng)建命令并加入到命令隊(duì)列 mCommandQueue 中
// 當(dāng)命令調(diào)用時(shí),會(huì)執(zhí)行 doDispatchCycleFinishedLockedInterruptible 函數(shù)
std::unique_ptr<CommandEntry> commandEntry = std::make_unique<CommandEntry>(
&InputDispatcher::doDispatchCycleFinishedLockedInterruptible);
commandEntry->connection = connection;
commandEntry->eventTime = currentTime;
commandEntry->seq = seq;
commandEntry->handled = handled;
commandEntry->consumeTime = consumeTime;
postCommandLocked(std::move(commandEntry));
}
命令是用來(lái)完成事件分發(fā)循環(huán)的,那么命令什么時(shí)候執(zhí)行呢?這就是第四步執(zhí)行的,最終調(diào)用如下函數(shù)來(lái)執(zhí)行命令
void InputDispatcher::doDispatchCycleFinishedLockedInterruptible(CommandEntry* commandEntry) {
sp<Connection> connection = commandEntry->connection;
const nsecs_t finishTime = commandEntry->eventTime;
uint32_t seq = commandEntry->seq;
const bool handled = commandEntry->handled;
// Handle post-event policy actions.
// 1. 根據(jù)序號(hào)seq,從連接的等待隊(duì)列中獲取事件
std::deque<DispatchEntry*>::iterator dispatchEntryIt = connection->findWaitQueueEntry(seq);
if (dispatchEntryIt == connection->waitQueue.end()) {
return;
}
// 獲取對(duì)應(yīng)的事件
DispatchEntry* dispatchEntry = *dispatchEntryIt;
// 如果事件處理的有一點(diǎn)點(diǎn)慢,但是沒(méi)超過(guò)超時(shí)事件,那么這里會(huì)給一個(gè)警告
// 這也說(shuō)明,窗口處理事件,不要執(zhí)行耗時(shí)的代碼
const nsecs_t eventDuration = finishTime - dispatchEntry->deliveryTime;
if (eventDuration > SLOW_EVENT_PROCESSING_WARNING_TIMEOUT) {
ALOGI("%s spent %" PRId64 "ms processing %s", connection->getWindowName().c_str(),
ns2ms(eventDuration), dispatchEntry->eventEntry->getDescription().c_str());
}
if (shouldReportFinishedEvent(*dispatchEntry, *connection)) {
mLatencyTracker.trackFinishedEvent(dispatchEntry->eventEntry->id,
connection->inputChannel->getConnectionToken(),
dispatchEntry->deliveryTime, commandEntry->consumeTime,
finishTime);
}
bool restartEvent;
if (dispatchEntry->eventEntry->type == EventEntry::Type::KEY) {
KeyEntry& keyEntry = static_cast<KeyEntry&>(*(dispatchEntry->eventEntry));
restartEvent =
afterKeyEventLockedInterruptible(connection, dispatchEntry, keyEntry, handled);
} else if (dispatchEntry->eventEntry->type == EventEntry::Type::MOTION) {
MotionEntry& motionEntry = static_cast<MotionEntry&>(*(dispatchEntry->eventEntry));
restartEvent = afterMotionEventLockedInterruptible(connection, dispatchEntry, motionEntry,
handled);
} else {
restartEvent = false;
}
// Dequeue the event and start the next cycle.
// Because the lock might have been released, it is possible that the
// contents of the wait queue to have been drained, so we need to double-check
// a few things.
dispatchEntryIt = connection->findWaitQueueEntry(seq);
if (dispatchEntryIt != connection->waitQueue.end()) {
dispatchEntry = *dispatchEntryIt;
// 2. 從 Connection::waitQueue 中移除等待反饋的事件
connection->waitQueue.erase(dispatchEntryIt);
const sp<IBinder>& connectionToken = connection->inputChannel->getConnectionToken();
// 3. 既然事件處理結(jié)果已經(jīng)反饋了,那么就不用再記錄它的處理超時(shí)時(shí)間了
mAnrTracker.erase(dispatchEntry->timeoutTime, connectionToken);
// 連接從無(wú)響應(yīng)變?yōu)榭身憫?yīng),那么停止 ANR
if (!connection->responsive) {
connection->responsive = isConnectionResponsive(*connection);
if (connection->responsive) {
// The connection was unresponsive, and now it's responsive.
processConnectionResponsiveLocked(*connection);
}
}
traceWaitQueueLength(*connection);
if (restartEvent && connection->status == Connection::STATUS_NORMAL) {
connection->outboundQueue.push_front(dispatchEntry);
traceOutboundQueueLength(*connection);
} else {
releaseDispatchEntry(dispatchEntry);
}
}
// Start the next dispatch cycle for this connection.
// 4. 既然通過(guò)連接收到反饋,那趁這個(gè)機(jī)會(huì),如果發(fā)件箱還有事件,繼續(xù)啟動(dòng)分發(fā)循環(huán)來(lái)發(fā)送事件
startDispatchCycleLocked(now(), connection);
}
分發(fā)循環(huán)的完成過(guò)程如下
- 檢查連接中是否有對(duì)應(yīng)的正在的等待的事件。
- 既然窗口已經(jīng)反饋的事件的處理結(jié)果,那么從連接的等待隊(duì)列 Connection::waitQueue 中移除。
- 既然窗口已經(jīng)反饋的事件的處理結(jié)果,那么就不必處理這個(gè)事件的 ANR,因此移除事件的 ANR 超時(shí)時(shí)間。
- 既然此時(shí)窗口正在反饋事件的處理結(jié)果,那趁熱打鐵,那么開(kāi)啟下一次分發(fā)循環(huán),發(fā)送連接發(fā)件箱中的事件。當(dāng)然,如果發(fā)件箱沒(méi)有事件,那么什么也不做。
完成分發(fā)循環(huán),其實(shí)最主要的就是把按鍵事件從連接的等待隊(duì)列中移除,以及解除 ANR 的觸發(fā)。
總結(jié)
本文雖然分析的只是按鍵事件的分發(fā)過(guò)程,但是從整體上剖析了所有事件的分發(fā)過(guò)程。我們將以此為基礎(chǔ)去分析觸摸事件(motion event)的分發(fā)過(guò)程。
現(xiàn)在總結(jié)下一個(gè)按鍵事件的基本發(fā)送流程
- InputReader 線程把按鍵事件加入到 InputDispatcher 的收件箱之前,會(huì)詢問(wèn)截?cái)嗖呗?,如果策略截?cái)嗔?,那么事件最終不會(huì)發(fā)送給窗口。
- InputDispatcher 通過(guò)一次線程循環(huán)來(lái)發(fā)送按鍵事件
- 事件在發(fā)送之前,會(huì)循環(huán)分發(fā)策略,主要是為了實(shí)現(xiàn)組合按鍵功能。
- 如果截?cái)嗖呗院头职l(fā)策略都不截?cái)喟存I事件,那么會(huì)尋找能處理按鍵事件的焦點(diǎn)窗口。
- 焦點(diǎn)窗口找到了,那么會(huì)把按鍵事件加入到窗口連接的發(fā)件箱中。
- 執(zhí)行分發(fā)循環(huán),從窗口連接的發(fā)件箱中獲取事件,然后發(fā)送給窗口。然后把事件從發(fā)件箱中移除,并加入到連接的等待隊(duì)列中。最后,記錄 ANR 時(shí)間。
- 窗口返回事件的處理結(jié)果,InputDispatcher 會(huì)讀取結(jié)果,然后把事件從連接的等待隊(duì)列中移除,然后解除 ANR 的觸發(fā)。
- 繼續(xù)發(fā)送連接中的事件,并重復(fù)上述過(guò)程,直至連接中沒(méi)有事件為止。
感想
我是一個(gè)注重實(shí)際效果的人,我花這么大力氣去分析事件的分發(fā)流程,是否值得? 從長(zhǎng)期的考慮看,肯定是值得的,從短期看,我們可以從 trace log 中分析出 ANR 的原因是否是因?yàn)槭录幚沓瑫r(shí)。
以上就是Input系統(tǒng)按鍵事件的分發(fā)處理示例詳解的詳細(xì)內(nèi)容,更多關(guān)于Input系統(tǒng)按鍵事件分發(fā)的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章!
相關(guān)文章
Android 三級(jí)NestedScroll嵌套滾動(dòng)實(shí)踐
這篇文章主要介紹了Android 三級(jí)NestedScroll嵌套滾動(dòng)實(shí)踐,文中通過(guò)示例代碼介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友們下面隨著小編來(lái)一起學(xué)習(xí)學(xué)習(xí)吧2019-02-02
淺析Android位置權(quán)限以及數(shù)組尋找索引的坑
這篇文章給大家分享了Android位置權(quán)限以及數(shù)組尋找索引的坑的相關(guān)知識(shí)點(diǎn)內(nèi)容,有興趣的朋友可以參考學(xué)習(xí)下。2018-07-07
Android底部菜單欄(RadioGroup+Fragment)美化
這篇文章主要介紹了Android底部菜單欄RadioGroup+Fragment美化,文中示例代碼介紹的非常詳細(xì),具有一定的參考價(jià)值,感興趣的小伙伴們可以參考一下2020-07-07
Android使用Volley框架定制PostUploadRequest上傳文件
這篇文章主要為大家詳細(xì)介紹了Android使用Volley框架定制PostUploadRequest上傳文件或圖片,具有一定的參考價(jià)值,感興趣的小伙伴們可以參考一下2018-12-12
Android 完全退出當(dāng)前應(yīng)用程序的四種方法
Android程序有很多Activity,比如說(shuō)主窗口A,調(diào)用了子窗口B,如果在B中直接finish(), 接下里顯示的是A。在B中如何關(guān)閉整個(gè)Android應(yīng)用程序呢?本人總結(jié)了幾種比較簡(jiǎn)單的實(shí)現(xiàn)方法2016-02-02
Android實(shí)現(xiàn)自動(dòng)輪播圖效果
這篇文章主要為大家詳細(xì)介紹了Android實(shí)現(xiàn)自動(dòng)輪播圖效果,具有一定的參考價(jià)值,感興趣的小伙伴們可以參考一下2018-11-11

