Input系統(tǒng)按鍵事件的分發(fā)處理示例詳解
前言
前面一篇文章分析了 InputReader 對按鍵事件的流程流程,大致上就是根據(jù)配置文件把按鍵的掃描碼(scan code)轉(zhuǎn)換為按鍵碼(key code),并且同時(shí)會從配置文件中獲取策略標(biāo)志位(policy flag),用于控制按鍵的行為,例如亮屏。然后把按鍵事件進(jìn)行包裝,分發(fā)給 InputDispatcher。本文就接著來分析 InputDispatcher 對按鍵事件的處理。
1. InputDispatcher 收到事件
從前面一篇文章可知,InputDispatcher 收到的按鍵事件的來源如下
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 處理完所有事件后,會刷新 QueuedInputListener 的緩存隊(duì)列,如下
void InputReader::loopOnce() {
// ...
{ // acquire lock
// ...
if (count) {
// 處理事件
processEventsLocked(mEventBuffer, count);
}
// ...
} // release lock
// ...
// 刷新緩存隊(duì)列
mQueuedListener->flush();
}
QueuedInputListener 會把緩存隊(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í)什么也沒做,就交給了 InputDispatcher
void InputClassifier::notifyKey(const NotifyKeyArgs* args) {
// 直接交給 InputDispatcher
mListener->notifyKey(args);
}
現(xiàn)在明白了按鍵事件的來源,接下來分析 InputDispatcher 如何處理按鍵事件
void InputDispatcher::notifyKey(const NotifyKeyArgs* args) {
// 檢測 action,action 只能為 AKEY_EVENT_ACTION_DOWN/AKEY_EVENT_ACTION_UP
if (!validateKeyEvent(args->action)) {
return;
}
// 策略標(biāo)志位,一般來源于配置文件
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;
}
// 來自 InputClassifier 的事件都是受信任的
policyFlags |= POLICY_FLAG_TRUSTED;
int32_t keyCode = args->keyCode;
accelerateMetaShortcuts(args->deviceId, args->action, keyCode, metaState);
// 創(chuàng)建 KeyEvent,這個對象主要用于,在事件加入到 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. 詢問策略,在按鍵事件加入到 InputDispatcher 隊(duì)列前,是否截?cái)嗍录?
// 如果上層不截?cái)嗍录?,policyFlags 添加 POLICY_FLAG_PASS_TO_USER,表示事件需要傳遞給用戶
// 如果上層截?cái)嗍录?,那么不會添?policyFlags 添加 POLICY_FLAG_PASS_TO_USER,事件最終不會傳遞給用戶
mPolicy->interceptKeyBeforeQueueing(&event, /*byref*/ policyFlags);
// 記錄處理時(shí)間
// 如果是Power鍵的截?cái)嗵幚頃r(shí)間過長,那么亮屏或者滅屏可能會讓用戶感覺到有延遲
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)沒有輸入過濾器(input filter)
if (shouldSendKeyToInputFilterLocked(args)) {
// ...
}
// 創(chuàng)建 KeyEntry,這個對象是 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 處理按鍵事件的過程如下
- 把按鍵事件包裝成 KeyEvent 對象,然后查詢截?cái)嗖呗?,看看策略是否截?cái)嘣撌录H绻呗圆唤財(cái)?,那么會在參?shù) policyFlags 添加 POLICY_FLAG_PASS_TO_USER 標(biāo)志位,表示事件要發(fā)送給用戶。 否則不會添加這個標(biāo)志位,InputDispatcher 后面會丟棄這個事件,也就是不會分發(fā)給用戶。參考【1.1 截?cái)嗖呗圆樵儭?/li>
- 把按鍵事件包裝成 KeyEntry 對象,然后加入到 InputDispatcher 的收件箱 InputDispatcher::mInboundQueue。參考【1.2 InputDispatcher 收件箱接收事件】
- 如有必要,喚醒 InputDispatcher 線程處理事件。通常,InputDispatcher 線程處于休眠狀態(tài)時(shí),如果收到事件,那么需要喚醒線程來處理事件。
注意,這里的所有操作,不是發(fā)生在 InputDispatcher 線程,而是發(fā)生在 InputReader 線程,這個線程是負(fù)責(zé)不斷地讀取事件,因此這里的查詢策略是否截?cái)嗍录倪^程,時(shí)間不能太長,否則影響了輸入系統(tǒng)讀取事件。
另外,在執(zhí)行完截?cái)嗖呗院?,會記錄處理的時(shí)長,如果時(shí)長超過一定的閾值,會收到一個警告信息。我曾經(jīng)聽到其他項(xiàng)目的人在談?wù)?power 鍵亮屏慢的問題,那么可以在這里排查下。
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;
}
// 受信任的按鍵事件,才會執(zhí)行策略查詢
// 來自 InputClassifier 的事件都是受信任的
if ((policyFlags & POLICY_FLAG_TRUSTED)) {
nsecs_t when = keyEvent->getEventTime();
JNIEnv* env = jniEnv();
// 1. 創(chuàng)建上層的 KeyEvent 對象
jobject keyEventObj = android_view_KeyEvent_fromNative(env, keyEvent);
jint wmActions;
if (keyEventObj) {
// 2. 調(diào)用上層的 InputManangerService#interceptMotionBeforeQueueingNonInteractive()
// 最終是通過 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 {
// 不受信任的事件,不會執(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;
}
// 受信任的按鍵事件,才會執(zhí)行策略查詢
// 來自 InputClassifier 的事件都是受信任的
if ((policyFlags & POLICY_FLAG_TRUSTED)) {
nsecs_t when = keyEvent->getEventTime();
JNIEnv* env = jniEnv();
// 1. 創(chuàng)建上層的 KeyEvent 對象
jobject keyEventObj = android_view_KeyEvent_fromNative(env, keyEvent);
jint wmActions;
if (keyEventObj) {
// 2. 調(diào)用上層的 InputManangerService#interceptMotionBeforeQueueingNonInteractive()
// 最終是通過 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 {
// 不受信任的事件,不會執(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)嗖呗缘牟樵冞^程,就是就是通過 JNI 調(diào)用上層 InputManagerService 的方法,而這個策略最終是由 PhoneWindowManager 實(shí)現(xiàn)的。如果策略不截?cái)啵绻呗圆唤財(cái)嗍录?,那么在參?shù)的策略標(biāo)志位 policyFlags 中添加 POLICY_FLAG_PASS_TO_USER 標(biāo)志位。
為何需要這個截?cái)嗖呗裕?或者這樣問,如果沒有截?cái)嗖呗?,那么會有什么問題呢? 假想我們正在處于通話,此時(shí)按下掛斷電話按鍵,如果輸入系統(tǒng)還有很多事件沒有處理完,或者說,處理事件的時(shí)間較長,那么掛斷電話的按鍵事件不能得到及時(shí)處理,這就相當(dāng)影響用戶體驗(yàn)。而如果有了截?cái)嗖呗裕谳斎胂到y(tǒng)正式處理事件前,就可以處理掛斷電話按鍵事件。
因此,截?cái)嗖呗缘淖饔镁褪羌皶r(shí)處理系統(tǒng)一些重要的功能。這給我們一個什么提示呢?當(dāng)硬件上添加了一個按鍵,如果想要快速響應(yīng)這個按鍵的事件,那么就在截?cái)嗖呗灾刑幚怼?/p>
關(guān)于截?cái)嗖呗?,以及后面的分發(fā)策略,是一個比較好的課題,我會在后面一篇文章中詳細(xì)分析。
下面,理解幾個概念
- 什么是交互狀態(tài)?什么是非交互狀態(tài)?簡單理解,亮屏就是交互狀態(tài),滅屏就是非交互狀態(tài)。但是,嚴(yán)格來說,并不準(zhǔn)確,如果讀者想知道具體的定義,可以查看我寫的 PowerManagerService 的文章。
- 什么是受信任的事件?來自物理輸入設(shè)備的事件都是受信任的,另外像 SystemUI ,由于申請了 android.permission.INJECT_EVENTS 權(quán)限, 因此它注入的 BACK, HOME 按鍵事件也都是受信任。
- 什么是注入事件?簡單來說,不是由物理設(shè)備產(chǎn)生的事件。例如,導(dǎo)航欄上的 BACK, HOME 按鍵,它們的事件都是通過注入產(chǎn)生的,因此它們是注入事件。
1.2 InputDispatcher 收件箱接收事件
bool InputDispatcher::enqueueInboundEventLocked(std::unique_ptr<EventEntry> newEntry) {
// mInboundQueue 隊(duì)列為空,需要喚醒 InputDispatcher 線程來處理事件
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 線程來處理,因?yàn)檫@個事件很重要
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 的事件收件箱,所有的事件,包括注入事件,都會加入這個收件箱。
如果收件箱之前沒有"郵件",當(dāng)接收到"郵件"后,就需要喚醒 InputDispatcher 線程來處理"郵件",這個邏輯很合理吧?
另外,聊一下這里提到的 app switch 按鍵。從上面的代碼可知,HOME, RECENT, ENDCALL 按鍵都是 app switch 按鍵。當(dāng) app switch 按鍵抬起時(shí),會計(jì)算一個超時(shí)時(shí)間,并且立即喚醒 InputDispatcher 線程來處理事件,因?yàn)檫@個事件很重要,需要及時(shí)處理,但是處理時(shí)間也不能太長,因此需要設(shè)置一個超時(shí)時(shí)間。
為何要給 app switch 按鍵設(shè)置一個超時(shí)時(shí)間? 假如我在操作一個界面,此時(shí)由于某些原因,例如 CPU 占用率過高,導(dǎo)致界面事件處理比較緩慢,也就是常說的卡頓現(xiàn)象。此時(shí)我覺得這個 app 太渣了,想殺掉它,怎么辦呢? 按下導(dǎo)航欄的 RECENT 按鍵,然后干掉它。但是由于界面處理事件比較緩慢,因此 RECENT 按鍵事件可能不能得到及時(shí)處理,這就會讓我很惱火,我很可能扔掉這個手機(jī)。因此需要給 app switch 按鍵設(shè)置一個超時(shí)時(shí)間,如果超時(shí)了,那么就會丟棄 app switch 按鍵之前的所有事件,來讓 app switch 事件得到及時(shí)的處理。
2. InputDispatcher 處理按鍵事件
現(xiàn)在收件箱已 InputDispatcher::mInboundQueue 已經(jīng)收到了按鍵事件,那么來看下 InputDisaptcher 線程如何處理按鍵事件的。由前面的文章可知,InputDisaptcher 線程循環(huán)的代碼如下
void InputDispatcher::dispatchOnce() {
nsecs_t nextWakeupTime = LONG_LONG_MAX;
{ // acquire lock
std::scoped_lock _l(mLock);
mDispatcherIsAlive.notify_all();
// 1. 如果沒有命令,分發(fā)一次事件
if (!haveCommandsLocked()) {
dispatchOnceInnerLocked(&nextWakeupTime);
}
// 2. 執(zhí)行命令,并且立即喚醒線程
// 這個命令來自于前一步的事件分發(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 毫秒
// 注意,休眠的過程可能會被打破
// 例如,窗口返回處理事件的結(jié)果時(shí),會被喚醒
// 又例如,收件箱接收到了事件,也會被喚醒
mLooper->pollOnce(timeoutMillis);
}
InputDispatcher 的一次線程循環(huán),做了如下幾件事
- 執(zhí)行一次事件分發(fā)。其實(shí)就是從收件箱中獲取一個事件進(jìn)行分發(fā)。注意,此過程只分發(fā)一個事件。也就是說,線程循環(huán)一次,只處理了一個事件。參考【2.1 分發(fā)事件】
- 執(zhí)行命令。 這個命令是哪里來的呢?是上一步事件分發(fā)中產(chǎn)生的。事件在發(fā)送給窗口前,會執(zhí)行一次分發(fā)策略查詢,而這個查詢的方式就是創(chuàng)建一個命令來執(zhí)行。
- 處理 ANR,并返回下一次線程喚醒的時(shí)間。窗口在接收到事件后,需要在規(guī)定的時(shí)間內(nèi)處理,否則會發(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)沒有啟動完成,或者正在關(guān)機(jī),mDispatchEnabled 為 false
if (!mDispatchEnabled) {
// 重置生成重復(fù)按鍵的計(jì)時(shí)
resetKeyRepeatLocked();
}
// Activity 發(fā)生旋轉(zhuǎn)時(shí),會凍結(jié)
if (mDispatchFrozen) {
// 被凍結(jié)時(shí),事件不會執(zhí)行分發(fā),等到被解凍后,再執(zhí)行分發(fā)
return;
}
// 判斷 app 切換是否超時(shí)
bool isAppSwitchDue = mAppSwitchDueTime <= currentTime;
// 如果下次線程喚醒的時(shí)間大于app切換超時(shí)時(shí)間,那么下次喚醒時(shí)間需要重置為app切換超時(shí)時(shí)間
// 以便處理app切換超時(shí)的問題
if (mAppSwitchDueTime < *nextWakeupTime) {
*nextWakeupTime = mAppSwitchDueTime;
}
// mPendingEvent 表示正在處理的事件
if (!mPendingEvent) {
if (mInboundQueue.empty()) { // 收件箱為空
// 收件箱為空,并且發(fā)生了 app 切換超時(shí)
// 也就是說,目前只有一個 app 切換按鍵事件,并且還超時(shí)了
// 處理這種情況很簡單,就是重置狀態(tà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)用戶按下一個按鍵后,長時(shí)間不松手,因此就需要合成一個重復(fù)按鍵事件
if (mKeyRepeatState.lastKeyEntry) {
if (currentTime >= mKeyRepeatState.nextRepeatTime) {
// 合成一個重復(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,那么表示真的沒有事件需要處理,
// 因此此次的分發(fā)循環(huán)就結(jié)束了
if (!mPendingEvent) {
return;
}
} else {
// 1. 從收件箱中取出事件
// mPendingEvent 表示正在處理的事件
mPendingEvent = mInboundQueue.front();
mInboundQueue.pop_front();
traceInboundQueueLengthLocked();
}
// 如果這個事件需要傳遞給用戶,那么需要通知上層的 PowerManagerService,此時(shí)有用戶行為,
// 例如,按下音量鍵,可以延長亮屏的時(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)沒有啟動完成,或者正在關(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)
// 舉一個例子,如果有兩個窗口,當(dāng)?shù)谝粋€窗口無響應(yīng)時(shí),如果用戶此時(shí)操作第二個窗口
// 系統(tǒng)需要及時(shí)把事件發(fā)送給第二個窗口,因?yàn)榇藭r(shí)第二個窗口是一個焦點(diǎn)窗口
// 那么就需要系統(tǒng)把無響應(yīng)窗口的事件丟棄,以免影響第二個窗口事件的分發(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í)不止如何處理這個事件,組合鍵的第一個按鍵按下時(shí),就是其中一種情況
if (done) {
// 處理事件被丟棄的情況
if (dropReason != DropReason::NOT_DROPPED) {
// 這里處理的一種情況是,如果窗口收到 DOWN 事件,但是 UP 事件由于某種原因被丟棄,那么需要補(bǔ)發(fā)一個 CANCEL 事件
dropInboundEventLocked(*mPendingEvent, dropReason);
}
mLastDropReason = dropReason;
// 無論事件發(fā)送給窗口,或者丟棄,都表示事件被處理了,因此重置 mPendingEvent
releasePendingEventLocked();
// 既然當(dāng)前事件已經(jīng)處理完,那么立即喚醒,處理下一個事件
*nextWakeupTime = LONG_LONG_MIN; // force next poll to wake up immediately
}
}
InputDispatcher 線程的一次事件分發(fā)的過程如下
- 從收件箱取出事件。
- 分發(fā)事件。參考【3. 按鍵事件的分發(fā)】
- 處理事件分發(fā)后的結(jié)果。 事件被丟棄或者發(fā)送給指定窗口,都會返回 true,表示事件被處理了,因此會重置 mPendingEvent。而如果事件分發(fā)的結(jié)果返回 false,表示事件沒有被處理,這種情況表示系統(tǒng)暫時(shí)不知道如何處理,最常見的情況就是組合鍵的第一個按鍵被按下,例如截屏鍵的 power 鍵按下,此時(shí)系統(tǒng)不知道是不是要單獨(dú)處理這個按鍵,還要等待組合鍵的另外一個按鍵,在超時(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ā)策略讓我們稍后再試,這是為了等待另外一個組合鍵的按鍵事件到來
if (entry->interceptKeyResult == KeyEntry::INTERCEPT_KEY_RESULT_TRY_AGAIN_LATER) {
// 還沒到等待的超時(shí)時(shí)間,那么繼續(xù)等待
if (currentTime < entry->interceptKeyWakeupTime) {
if (entry->interceptKeyWakeupTime < *nextWakeupTime) {
*nextWakeupTime = entry->interceptKeyWakeupTime;
}
return false; // wait until next wakeup
}
// 這里表示已經(jīng)超時(shí)了,因此需要再次詢問分發(fā)策略,看看結(jié)果
// 例如,當(dāng)截屏的power鍵超時(shí)時(shí),再次詢問分發(fā)策略是否音量下鍵已經(jīng)按下,如果按下了,
// 那么這個 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)建一個命令
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 中加入一個命令
postCommandLocked(std::move(commandEntry));
// 返回 false,表示需要運(yùn)行命令看看這個事件是否需要觸發(fā)組合鍵的功能
return false; // wait for the command to run
} else {
// 如果事件不傳遞給用戶,那么不會查詢分發(fā)策略是否截?cái)啵亲约航又幚?,后面會丟棄它
entry->interceptKeyResult = KeyEntry::INTERCEPT_KEY_RESULT_CONTINUE;
}
} else if (entry->interceptKeyResult == KeyEntry::INTERCEPT_KEY_RESULT_SKIP) {
// 查詢分發(fā)策略得到的結(jié)果是讓我們跳過這個事件,不處理
// 其中一種情況是,組合鍵的另外一個按鍵被消費(fèi)了,因此是一個無效事件,讓我們丟棄它
// 另外一種情況是,分發(fā)策略直接消費(fèi)了這個事件,讓我們不要聲張,丟棄它
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ī)不成熟,例如窗口還在啟動中,那么直接結(jié)束此時(shí)的事件分發(fā),等待時(shí)機(jī)合適再處理
if (injectionResult == InputEventInjectionResult::PENDING) {
// 返回 false,那么會導(dǎo)致線程休眠一段時(shí)間,等再次喚醒時(shí),再來處理事件
return false;
}
// 保存注入結(jié)果
setInjectionResult(*entry, injectionResult);
// 處理 InputEventInjectionResult::FAILED 和 InputEventInjectionResult::PERMISSION_DENIED 結(jié)果
// 表示沒有找到事件的輸入目標(biāo)窗口
if (injectionResult != InputEventInjectionResult::SUCCEEDED) {
// 返回 true,那么事件即將被丟棄
return true;
}
// 走到這里,表示成功找到焦點(diǎn)窗口
// Add monitor channels from event's or focused display.
// 添加監(jiān)聽所有事件的通道
// TODO:這個暫時(shí)不知道有何用
addGlobalMonitoringTargetsLocked(inputTargets, getTargetDisplayId(*entry));
// Dispatch the key.
// 處理 InputEventInjectionResult::SUCCEEDED 結(jié)果,表明找到了事件輸入目標(biāo)
// 3. 事件分發(fā)按鍵給目標(biāo)窗口
dispatchEventLocked(currentTime, entry, inputTargets);
return true;
}
按鍵事件分發(fā)的主要過程如下
- 執(zhí)行分發(fā)策略。分發(fā)策略的作用,一方面是實(shí)現(xiàn)組合按鍵的功能,另外一方面是為了在事件分發(fā)給窗口前,給系統(tǒng)一個優(yōu)先處理的機(jī)會。
- 尋找處理按鍵事件的焦點(diǎn)窗口。參考【3.1 尋找焦點(diǎn)窗口】
- 只有成功尋找到焦點(diǎn)窗口,才進(jìn)行按鍵事件分發(fā)。參考【3.2 分發(fā)按鍵事件給目標(biāo)窗口】
分發(fā)策略涉及到組合按鍵的實(shí)現(xiàn),因此是一個非常復(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);
// 沒有焦點(diǎn)窗口,也沒有焦點(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;
}
// 沒有焦點(diǎn)窗口,但是有焦點(diǎn)app
// 這里處理的情況是,app正在啟動,但是還沒有顯示即將獲得焦點(diǎn)的窗口
if (focusedWindowHandle == nullptr && focusedApplicationHandle != nullptr) {
if (!mNoFocusedWindowTimeoutTime.has_value()) {
// 啟動一個 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)窗口正在啟動,暫時(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í),丟棄這個事件
return InputEventInjectionResult::FAILED;
} else {
// Still waiting for the focused window
// 等待焦點(diǎn)窗口還沒有超時(shí),繼續(xù)等待,暫時(shí)不處理事件
return InputEventInjectionResult::PENDING;
}
}
// 走到這里,表示已經(jīng)有了一個有效的焦點(diǎn)窗口
// we have a valid, non-null focused window
// 因?yàn)橛辛擞行Ы裹c(diǎn)窗口,重置 mNoFocusedWindowTimeoutTime 和 mAwaitedFocusedApplication
resetNoFocusedWindowTimeoutLocked();
// 對于注入事件,如果注入者的 UID 與窗口所屬的 UDI 不同,并且注入者沒有 android.Manifest.permission.INJECT_EVENTS 權(quán)限
// 那么注入事件將會被丟棄
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;
}
// 如果前面還有事件沒有處理完畢,那么需要等待前面事件處理完畢,才能發(fā)送按鍵事件
// 因?yàn)榍懊娴氖录赡苡绊懡裹c(diǎn)窗口,所以按鍵事件需要等待前面事件處理完畢才能發(fā)送
if (entry.type == EventEntry::Type::KEY) {
if (shouldWaitToSendKeyLocked(currentTime, focusedWindowHandle->getName().c_str())) {
*nextWakeupTime = *mKeyIsWaitingForEventsTimeout;
// 前面有時(shí)間沒有處理完畢,因此暫不處理當(dāng)前的按鍵事件
return InputEventInjectionResult::PENDING;
}
}
// Success! Output targets.
// 走到這里,表示事件可以成功發(fā)送焦點(diǎn)窗口
// 2. 根據(jù)焦點(diǎn)窗口創(chuàng)建 InputTarget,并保存到參數(shù) inputTargets
// 注意第二個參數(shù),后面把事件加入到一個輸入通道鏈接的收件箱時(shí),會用到
addWindowTargetLocked(focusedWindowHandle,
InputTarget::FLAG_FOREGROUND | InputTarget::FLAG_DISPATCH_AS_IS,
BitSet32(0), inputTargets);
// Done.
return InputEventInjectionResult::SUCCEEDED;
}
尋找目標(biāo)窗口的過程其實(shí)就是找到焦點(diǎn)窗口,然后根據(jù)焦點(diǎn)窗口創(chuàng)建 InputTarget,保存到參數(shù) inputTargets 中。
結(jié)合前面的代碼分析,尋找焦點(diǎn)窗口返回的結(jié)果,會影響事件的處理,總結(jié)如下
| 尋找焦點(diǎn)窗口的結(jié)果 | 結(jié)果的說明 | 如何影響事件的處理 |
|---|---|---|
| InputEventInjectionResult::SUCCEEDED | 成功為事件找到焦點(diǎn)窗口 | 事件會被分發(fā)到焦點(diǎn)窗口 |
| InputEventInjectionResult::FAILED | 沒有找到可用的焦點(diǎn)窗口 | 事件會被丟棄 |
| InputEventInjectionResult::PERMISSION_DENIED | 沒有權(quán)限把事件發(fā)送到焦點(diǎn)窗口 | 事件會被丟棄 |
| InputEventInjectionResult::PENDING | 有焦點(diǎn)窗口,但是暫時(shí)不可用于接收事件 | 線程會休眠,等待時(shí)機(jī)被喚醒,發(fā)送事件到焦點(diǎn)窗口 |
在工作中,有時(shí)候需要我們分析按鍵事件為何沒有找到焦點(diǎn)窗口,這里列舉一下所有的情況,以供大家工作或面試時(shí)使用
- 沒有焦點(diǎn)app,并且沒有焦點(diǎn)窗口。這種情況應(yīng)該比較極端,應(yīng)該整個surface系統(tǒng)都出問題了。
- 窗口的 Feature 表示要丟棄事件。這個丟棄事件的 Feature 是 Surface 系統(tǒng)給窗口設(shè)置的,目前我還沒有搞清楚這里面的邏輯。
- 焦點(diǎn)app啟動焦點(diǎn)窗口,超時(shí)了。
- 對于注入事件,如果注入者的 UID 與焦點(diǎn)窗口的 UID 不同,并且注入者沒有申請 android.Manifest.permission.INJECT_EVENTS 權(quán)限。
沒有找到焦點(diǎn)窗口的所有情況,都有日志對應(yīng)輸出,可幫助我們定位問題。
現(xiàn)在來看一下,找到焦點(diǎn)窗口后,創(chuàng)建并保存 InputTarget 的過程
// 注意,參數(shù) targetFlags 的值為 InputTarget::FLAG_FOREGROUND | InputTarget::FLAG_DISPATCH_AS_IS
// InputTarget::FLAG_FOREGROUND 表示事件正在發(fā)送給前臺窗口
// 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;
}
// 保存輸入通道,通過這個通道,事件才能發(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 信息,這會把顯示屏的坐標(biāo),轉(zhuǎn)換到窗口的坐標(biāo)系上
// 對于按鍵事件,不需要把顯示屏坐標(biāo)轉(zhuǎn)換到窗口坐標(biāo)
// 因此,對于按鍵事件,pointerIds 為0,這里只是簡單保存一個默認(rèn)的 Transfrom 而已
it->addPointers(pointerIds, windowInfo->transform);
}
3.2 分發(fā)按鍵事件給目標(biāo)窗口
現(xiàn)在,處理按鍵事件的焦點(diǎn)窗口已經(jīng)找到,并且已經(jīng)保存到 inputTargets,是時(shí)候來分發(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)窗口只有一個,為何需要一個 inputTargets 集合來保存所有的目標(biāo)窗口,因?yàn)楦鶕?jù)前面的分析,除了焦點(diǎn)窗口以外,還有一個全局的監(jiān)聽事件的輸入目標(biāo)。
WindowManagerService 會在創(chuàng)建窗口時(shí),創(chuàng)建一個連接,其中一端給窗口,另外一端給輸入系統(tǒng)。當(dāng)輸入系統(tǒng)需要發(fā)送事件給窗口時(shí),就會通過這個連接進(jìn)行發(fā)送。至于連接的建立過程,有點(diǎn)小復(fù)雜,本分不分析,后面如果寫 WMS 的文章,再來細(xì)致分析一次。
找到這個窗口的連接后,就準(zhǔn)備分發(fā)循環(huán) ? 問題來了,什么是分發(fā)循環(huán) ? InputDispatcher 把一個事件發(fā)送給窗口,窗口處理完事件,然后返回結(jié)果為 InputDispatcher,這就是一個循環(huán)。但是注意,分發(fā)事件給窗口,窗口返回處理事件結(jié)果,這兩個是互為異步過程。
現(xiàn)在來看下分發(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.
// 針對觸摸事件的split
if (inputTarget.flags & InputTarget::FLAG_SPLIT) {
// ...
}
// Not splitting. Enqueue dispatch entries for the event as is.
// 把事件加入到連接的發(fā)件箱中,然后啟動分發(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
// 注意最后一個參數(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ā)件箱突然有事件了,那得啟動分發(fā)循環(huán),把事件發(fā)送到指定窗口
if (wasEmpty && !connection->outboundQueue.empty()) {
// 2. 啟動分發(fā)循環(huán)
startDispatchCycleLocked(currentTime, connection);
}
}
分發(fā)循環(huán)前的準(zhǔn)備工作,其實(shí)就是根據(jù)窗口所支持的分發(fā)模式(dispatche mode),調(diào)用enqueueDispatchEntryLocked() 創(chuàng)建并保存事件到連接的收件箱。前面分析過,焦點(diǎn)窗口的的分發(fā)模式為 InputTarget::FLAG_DISPATCH_AS_IS | InputTarget::FLAG_FOREGROUND,而此時(shí)只用到了InputTarget::FLAG_DISPATCH_AS_IS。 參考【3.2.1 根據(jù)分發(fā)模式,添加事件到連接收件箱】
如果連接的收件箱之前沒有事件,那么證明連接沒有處于發(fā)送事件的狀態(tài)中,而現(xiàn)在有事件了,那就啟動分發(fā)循環(huán)來發(fā)送事件。參考 【3.2.2 啟動分發(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;
// 窗口不支持請求的dispatcher mode,那么不添加事件到連接的發(fā)件箱中
// 對于按鍵事件,dispatchMode 只能是 InputTarget::FLAG_DISPATCH_AS_IS
if (!(inputTargetFlags & dispatchMode)) {
return;
}
// 1. 為每一個窗口所支持的 dispatche mode,創(chuàng)建一個 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.
// 檢測事件是否正在發(fā)送到前臺窗應(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ā)送給前臺應(yīng)用,InputTarget::FLAG_DISPATCH_AS_IS 表示事件按照原樣進(jìn)行發(fā)送。
而參數(shù) dispatchMode 只使用了 InputTarget::FLAG_DISPATCH_AS_IS,因此,對于按鍵事件,只會創(chuàng)建并添加一個 DispatchEntry 到 Connection::outboundQueue。
3.2.2 啟動分發(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ā)件箱中的所有事件,逐個發(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),那么會記錄事件處理的超時(shí)時(shí)間,一旦超時(shí),會引發(fā) ANR
// 因?yàn)槲覀儾豢赡軣o限等待窗口處理完事件,后面還有好多事件要處理呢
// 4. 用 AnrTracker 記錄事件處理的超時(shí)時(shí)間
if (connection->responsive) {
mAnrTracker.insert(dispatchEntry->timeoutTime,
connection->inputChannel->getConnectionToken());
}
traceWaitQueueLength(*connection);
}
}
事件分發(fā)循環(huán)的過程如下
- 通過窗口連接,把事件發(fā)送給窗口,并從連接的發(fā)件箱 Connection::outboundQueue 中移除。
- 把剛剛發(fā)送的事件,保存到連接的等待隊(duì)列 Connection::waitQueue。連接在等待什么呢?當(dāng)然是等到窗口的處理結(jié)果。
- 用 AnrTracker 記錄事件處理的超時(shí)時(shí)間,如果事件處理超時(shí),會引發(fā) ANR。
既然叫做一個循環(huán),現(xiàn)在事件已經(jīng)發(fā)送出去了,那么如何接收處理結(jié)果呢? InputDispatcher 線程使用了底層的 Looper 機(jī)制,當(dāng)窗口與輸入系統(tǒng)建立連接時(shí),Looper 通過 epoll 機(jī)制監(jiān)聽連接的輸入端的文件描述符,當(dāng)窗口通過連接反饋處理結(jié)果時(shí),epoll 就會收到可讀事件,因此 InputDispatcher 線程會被喚醒來讀取窗口的事件處理結(jié)果,而這個過程就是下面的下面的回調(diào)函數(shù)
如果讀者想了解底層的 Looper 機(jī)制,可以參考我寫的 深入理解Native層消息機(jī)制
int InputDispatcher::handleReceiveCallback(int events, sp<IBinder> connectionToken) {
std::scoped_lock _l(mLock);
// 1. 獲取對應(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;
// 通過一個無限循環(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é)果的過程如下
- 根據(jù)連接的 token 獲取連接。
- 從連接中讀取窗口返回的事件處理結(jié)果。
- 完成這個事件的分發(fā)循環(huán)。此過程會創(chuàng)建一個命令,并加如到命令隊(duì)列中,然后在第四步執(zhí)行。
- 執(zhí)行第三步創(chuàng)建的命令,以完成分發(fā)循環(huán)。
當(dāng)監(jiān)聽到窗口的連接有事件到來時(shí),會從連接讀取窗口對事件的處理結(jié)果,然后創(chuàng)建一個即將執(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í),會執(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));
}
命令是用來完成事件分發(fā)循環(huán)的,那么命令什么時(shí)候執(zhí)行呢?這就是第四步執(zhí)行的,最終調(diào)用如下函數(shù)來執(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ù)序號seq,從連接的等待隊(duì)列中獲取事件
std::deque<DispatchEntry*>::iterator dispatchEntryIt = connection->findWaitQueueEntry(seq);
if (dispatchEntryIt == connection->waitQueue.end()) {
return;
}
// 獲取對應(yīng)的事件
DispatchEntry* dispatchEntry = *dispatchEntryIt;
// 如果事件處理的有一點(diǎn)點(diǎn)慢,但是沒超過超時(shí)事件,那么這里會給一個警告
// 這也說明,窗口處理事件,不要執(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);
// 連接從無響應(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. 既然通過連接收到反饋,那趁這個機(jī)會,如果發(fā)件箱還有事件,繼續(xù)啟動分發(fā)循環(huán)來發(fā)送事件
startDispatchCycleLocked(now(), connection);
}
分發(fā)循環(huán)的完成過程如下
- 檢查連接中是否有對應(yīng)的正在的等待的事件。
- 既然窗口已經(jīng)反饋的事件的處理結(jié)果,那么從連接的等待隊(duì)列 Connection::waitQueue 中移除。
- 既然窗口已經(jīng)反饋的事件的處理結(jié)果,那么就不必處理這個事件的 ANR,因此移除事件的 ANR 超時(shí)時(shí)間。
- 既然此時(shí)窗口正在反饋事件的處理結(jié)果,那趁熱打鐵,那么開啟下一次分發(fā)循環(huán),發(fā)送連接發(fā)件箱中的事件。當(dāng)然,如果發(fā)件箱沒有事件,那么什么也不做。
完成分發(fā)循環(huán),其實(shí)最主要的就是把按鍵事件從連接的等待隊(duì)列中移除,以及解除 ANR 的觸發(fā)。
總結(jié)
本文雖然分析的只是按鍵事件的分發(fā)過程,但是從整體上剖析了所有事件的分發(fā)過程。我們將以此為基礎(chǔ)去分析觸摸事件(motion event)的分發(fā)過程。
現(xiàn)在總結(jié)下一個按鍵事件的基本發(fā)送流程
- InputReader 線程把按鍵事件加入到 InputDispatcher 的收件箱之前,會詢問截?cái)嗖呗?,如果策略截?cái)嗔?,那么事件最終不會發(fā)送給窗口。
- InputDispatcher 通過一次線程循環(huán)來發(fā)送按鍵事件
- 事件在發(fā)送之前,會循環(huán)分發(fā)策略,主要是為了實(shí)現(xiàn)組合按鍵功能。
- 如果截?cái)嗖呗院头职l(fā)策略都不截?cái)喟存I事件,那么會尋找能處理按鍵事件的焦點(diǎn)窗口。
- 焦點(diǎn)窗口找到了,那么會把按鍵事件加入到窗口連接的發(fā)件箱中。
- 執(zhí)行分發(fā)循環(huán),從窗口連接的發(fā)件箱中獲取事件,然后發(fā)送給窗口。然后把事件從發(fā)件箱中移除,并加入到連接的等待隊(duì)列中。最后,記錄 ANR 時(shí)間。
- 窗口返回事件的處理結(jié)果,InputDispatcher 會讀取結(jié)果,然后把事件從連接的等待隊(duì)列中移除,然后解除 ANR 的觸發(fā)。
- 繼續(xù)發(fā)送連接中的事件,并重復(fù)上述過程,直至連接中沒有事件為止。
感想
我是一個注重實(shí)際效果的人,我花這么大力氣去分析事件的分發(fā)流程,是否值得? 從長期的考慮看,肯定是值得的,從短期看,我們可以從 trace log 中分析出 ANR 的原因是否是因?yàn)槭录幚沓瑫r(shí)。
以上就是Input系統(tǒng)按鍵事件的分發(fā)處理示例詳解的詳細(xì)內(nèi)容,更多關(guān)于Input系統(tǒng)按鍵事件分發(fā)的資料請關(guān)注腳本之家其它相關(guān)文章!
相關(guān)文章
Android簡單實(shí)現(xiàn)屏幕下方Tab菜單的方法
這篇文章主要介紹了Android簡單實(shí)現(xiàn)屏幕下方Tab菜單的方法,簡單分析了Android實(shí)現(xiàn)tab菜單所涉及的界面布局及功能相關(guān)操作技巧,需要的朋友可以參考下2016-08-08
Android中程序的停止?fàn)顟B(tài)詳細(xì)介紹
這篇文章主要介紹了Android中程序的停止?fàn)顟B(tài)詳細(xì)介紹,本文講解了什么是程序的停止?fàn)顟B(tài)、為什么Android要引入這一狀態(tài)、激活狀態(tài)和停止?fàn)顟B(tài)的切換、如何變?yōu)橥V範(fàn)顟B(tài)等內(nèi)容,需要的朋友可以參考下2015-01-01
Android截取視頻幀并轉(zhuǎn)化為Bitmap示例
利用MediaMetadataRetriever按照時(shí)間截取視頻并轉(zhuǎn)換為Bitmap存放于SDCard,具體實(shí)現(xiàn)如下,感興趣的朋友可以參考下哈2013-06-06
Android開發(fā)之AlarmManager的用法詳解
這篇文章主要介紹了Android開發(fā)之AlarmManager的用法,是Android應(yīng)用開發(fā)中非常實(shí)用的技能,需要的朋友可以參考下2014-07-07
Android開發(fā)系列二之窗口Activity的生命周期
這篇文章主要介紹了Android學(xué)習(xí)系列二之窗口Activity的生命周期的相關(guān)資料,需要的朋友可以參考下2016-05-05

