本文主要從系統(tǒng)源碼的角度帶你一步步了解Android Input子系統(tǒng)。

從我個(gè)人的理解來看，Android的Input系統(tǒng)其實(shí)就是系統(tǒng)級(jí)的事件處理、分發(fā)框架，它需要的功能模塊大致有：事件讀取、事件分類、事件分發(fā)。那么我們就從整個(gè)Input系統(tǒng)的輸入源入手，了解事件是如何被輸入到Input系統(tǒng)中的。

在看代碼前我們先想一想，如果要我們?cè)O(shè)計(jì)一個(gè)事件分發(fā)框架的輸入讀取模塊，要考慮到哪些子模塊：

• 事件生成模塊(當(dāng)用戶對(duì)設(shè)備進(jìn)行操作產(chǎn)生InputEvent，硬件產(chǎn)生中斷將事件交給驅(qū)動(dòng)，驅(qū)動(dòng)交給內(nèi)核，內(nèi)核交給framework)
• 事件監(jiān)聽模塊(這里就很像設(shè)計(jì)一個(gè)服務(wù)器，為了及時(shí)響應(yīng)來自客戶端的請(qǐng)求，則需要啟動(dòng)一個(gè)線程監(jiān)聽)
• 事件讀取模塊
• 事件分發(fā)模塊

那么現(xiàn)在我們最起碼可以知道整個(gè)學(xué)習(xí)的起點(diǎn)了，就是Input系統(tǒng)中，負(fù)責(zé)監(jiān)聽的線程是誰，監(jiān)聽的過程中它們做了什么。 在開始之前，給大家分享一張我根據(jù)本文內(nèi)容畫的圖：

InputManagerService初始化概覽

首先，有幾點(diǎn)共識(shí)我們都可以達(dá)成：

• Android Framework層的Service(Java)都是由system_server進(jìn)程創(chuàng)建的(由于沒有fork，因此都運(yùn)行在system_server進(jìn)程中)
• Service創(chuàng)建后就會(huì)交給運(yùn)行在system_server進(jìn)程中的ServiceManager管理。

因此對(duì)于InputManagerService的創(chuàng)建，我們可以在SystemServer的startOtherServices()方法中找到，該方法做了以下事情：

• 創(chuàng)建InputManagerService對(duì)象
• 將它交給ServiceManager管理
• 將WindowManagerService的InputMonitor注冊(cè)到InputManagerService中作為窗口響應(yīng)事件后的回調(diào)
• 完成以上工作后啟動(dòng)InputManagerService。 

SystemServer.javastartOtherServices(){ 
    …… 
    inputManager = new InputManagerService(context); 
    …… 
    inputManager.setWindowManagerCallbacks(wm.getInputMonitor()); 
    inputManager.start(); 
    …… 
} 

 接下來我們就逐部分學(xué)習(xí)相應(yīng)的處理。

InputManagerService對(duì)象的創(chuàng)建

創(chuàng)建InputManagerService對(duì)象時(shí)會(huì)完成以下工作：

• 創(chuàng)建一個(gè)負(fù)責(zé)處理DisplayThread線程中的Message的Handler
• 調(diào)用nativeInit初始化native層的InputManagerService，初始化的時(shí)候傳入了DisplayThread的消息隊(duì)列
• 用mPtr保存native層的InputManagerService
• 初始化完成后將Service添加到LocalServices，通過Map以鍵值對(duì)的形式存儲(chǔ) 

InputManagerService.javapublic InputManagerService(Context context) {    this.mContext = context;    this.mHandler = new InputManagerHandler(DisplayThread.get().getLooper()); 
 
    mUseDevInputEventForAudioJack = 
            context.getResources().getBoolean(R.bool.config_useDevInputEventForAudioJack); 
    Slog.i(TAG, "Initializing input manager, mUseDevInputEventForAudioJack=" 
            + mUseDevInputEventForAudioJack); 
    mPtr = nativeInit(this, mContext, mHandler.getLooper().getQueue()); 
 
    LocalServices.addService(InputManagerInternal.class, new LocalService()); 
} 

 這里可能有人就會(huì)問了，為什么InputManagerService要和DisplayThread綁定在一起?大家不妨想想，InputEvent無論如何被獲取、歸類、分發(fā)，最終還是要被處理，也就意味著最終它的處理結(jié)果都要在UI上體現(xiàn)，那么InputManagerService自然要選擇和UI親近一些的線程在一起了。

但是問題又來了，應(yīng)用都是運(yùn)行在自己的主線程里的，難道InputManagerService要一個(gè)個(gè)綁定么，還是一個(gè)個(gè)輪詢?這些做法都太過低效，那換個(gè)辦法，可不可以和某個(gè)管理或非常親近所有應(yīng)用UI的線程綁定在一起呢?

答案是什么，我在這里先不說，大家可以利用自己的知識(shí)想想。

初始化native層的InputManagerService

在nativeInit函數(shù)中，將Java層的MessageQueue轉(zhuǎn)換為native層的MessageQueue，然后再取出Looper用于NativeInputManager的初始化?？梢娺@里的重頭戲就是NativeInputManager的創(chuàng)建，這個(gè)過程做了以下事情：

• 將Java層的Context和InputManagerService轉(zhuǎn)換為native層的Context和InputManagerService存儲(chǔ)在mContextObj和mServiceObj中
• 初始化變量
• 創(chuàng)建EventHub
• 創(chuàng)建InputManager 

com_android_server_input_InputManagerService.cpp 
 
NativeInputManager::NativeInputManager(jobject contextObj, 
        jobject serviceObj, const sp<Looper>& looper) : 
        mLooper(looper), mInteractive(true) { 
    JNIEnv* env = jniEnv(); 
 
    mContextObj = env->NewGlobalRef(contextObj); 
    mServiceObj = env->NewGlobalRef(serviceObj); 
 
    {        AutoMutex _l(mLock); 
        mLocked.systemUiVisibility = ASYSTEM_UI_VISIBILITY_STATUS_BAR_VISIBLE; 
        mLocked.pointerSpeed = 0; 
        mLocked.pointerGesturesEnabled = true; 
        mLocked.showTouches = false; 
    } 
    mInteractive = true; 
 
    sp<EventHub> eventHub = new EventHub(); 
    mInputManager = new InputManager(eventHub, this, this); 
} 

 EventHub

看到這里很多人就會(huì)想，EventHub是什么?取英語釋義來看，它的意思是事件樞紐。我們?cè)谖恼麻_頭的時(shí)候也提到過，Input系統(tǒng)的事件來源于驅(qū)動(dòng)/內(nèi)核，那么我們可以猜測(cè)EventHub是處理來自驅(qū)動(dòng)/內(nèi)核的元事件的樞紐。接下來就在源碼中驗(yàn)證我們的想法吧。

EventHub的創(chuàng)建過程中做了以下事情：

• 創(chuàng)建mEpollFd用于監(jiān)聽是否有數(shù)據(jù)(有無事件)可讀
• 創(chuàng)建mINotifyFd將它注冊(cè)到DEVICE_PATH(這里路徑就是/dev/input)節(jié)點(diǎn)，并將它交給內(nèi)核用于監(jiān)聽該設(shè)備節(jié)點(diǎn)的增刪數(shù)據(jù)事件。那么只要有數(shù)據(jù)增刪的事件到來，epoll_wait()就會(huì)返回，使得EventHub能收到來自系統(tǒng)的通知，并獲取事件的詳細(xì)信息
• 調(diào)用epoll_ctl函數(shù)將mEpollFd和mINotifyFd注冊(cè)到epoll中
• 定義int wakeFd[2]作為事件傳輸管道的讀寫兩端，并將讀端注冊(cè)到epoll中讓mEpollFd監(jiān)聽 

EventHub.cpp 
 
EventHub::EventHub(void) : 
        mBuiltInKeyboardId(NO_BUILT_IN_KEYBOARD), mNextDeviceId(1), mControllerNumbers(), 
        mOpeningDevices(0), mClosingDevices(0), 
        mNeedToSendFinishedDeviceScan(false), 
        mNeedToReopenDevices(false), mNeedToScanDevices(true), 
        mPendingEventCount(0), mPendingEventIndex(0), mPendingINotify(false) { 
    acquire_wake_lock(PARTIAL_WAKE_LOCK, WAKE_LOCK_ID); 
 
    mEpollFd = epoll_create(EPOLL_SIZE_HINT); 
    LOG_ALWAYS_FATAL_IF(mEpollFd < 0, "Could not create epoll instance.  errno=%d", errno); 
 
    mINotifyFd = inotify_init(); 
    int result = inotify_add_watch(mINotifyFd, DEVICE_PATH, IN_DELETE | IN_CREATE); 
    …… 
    result = epoll_ctl(mEpollFd, EPOLL_CTL_ADD, mINotifyFd, &eventItem); 
    …… 
    int wakeFds[2]; 
    result = pipe(wakeFds); 
    …… 
    mWakeReadPipeFd = wakeFds[0]; 
    mWakeWritePipeFd = wakeFds[1]; 
 
    result = fcntl(mWakeReadPipeFd, F_SETFL, O_NONBLOCK); 
    …… 
    result = fcntl(mWakeWritePipeFd, F_SETFL, O_NONBLOCK); 
    …… 
    result = epoll_ctl(mEpollFd, EPOLL_CTL_ADD, mWakeReadPipeFd, &eventItem); 
    …… 
} 

那么這里拋出一個(gè)問題：為什么要把管道的讀端注冊(cè)到epoll中?假如EventHub因?yàn)間etEvents讀不到事件而阻塞在epoll_wait()里，而我們沒有綁定讀端的話，我們要怎么喚醒EventHub?如果綁定了管道的讀端，我們就可以通過向管道的寫端寫數(shù)據(jù)從而讓EventHub因?yàn)榈玫焦艿缹懚说臄?shù)據(jù)而被喚醒。

InputManager的創(chuàng)建

接下來繼續(xù)說InputManager的創(chuàng)建，它的創(chuàng)建就簡(jiǎn)單多了，創(chuàng)建一個(gè)InputDispatcher對(duì)象用于分發(fā)事件，一個(gè)InputReader對(duì)象用于讀事件并把事件交給InputDispatcher分發(fā)，，然后調(diào)用initialize()初始化，其實(shí)也就是創(chuàng)建了InputReaderThread和InputDispatcherThread。 

InputManager.cpp 
 
InputManager::InputManager(        const sp<EventHubInterface>& eventHub,        const sp<InputReaderPolicyInterface>& readerPolicy,        const sp<InputDispatcherPolicyInterface>& dispatcherPolicy) { 
    mDispatcher = new InputDispatcher(dispatcherPolicy); 
    mReader = new InputReader(eventHub, readerPolicy, mDispatcher); 
    initialize(); 
}void InputManager::initialize() { 
    mReaderThread = new InputReaderThread(mReader); 
    mDispatcherThread = new InputDispatcherThread(mDispatcher); 
} 

 InputDispatcher和InputReader的創(chuàng)建都相對(duì)簡(jiǎn)單。InputDispatcher會(huì)創(chuàng)建自己線程的Looper，以及設(shè)置根據(jù)傳入的dispatchPolicy設(shè)置分發(fā)規(guī)則。InputReader則會(huì)將傳入的InputDispatcher封裝為監(jiān)聽對(duì)象存起來，做一些數(shù)據(jù)初始化就結(jié)束了。

至此，InputManagerService對(duì)象的初始化就完成了，根據(jù)開頭說的，接下來就會(huì)調(diào)用InputManagerService的start()方法。

監(jiān)聽線程InputReader和InputDispatcher的啟動(dòng)

在start()方法中，做了以下事情：

• 調(diào)用nativeStart方法，其實(shí)就是調(diào)用InputManager的start()方法
• 將InputManagerService交給WatchDog監(jiān)控
• 注冊(cè)觸控點(diǎn)速度、顯示觸控的觀察者，并注冊(cè)廣播監(jiān)控它們
• 主動(dòng)調(diào)用updateXXX方法更新(初始化) 

InputManagerService.javapublic void start() { 
    Slog.i(TAG, "Starting input manager"); 
    nativeStart(mPtr);    // Add ourself to the Watchdog monitors. 
    Watchdog.getInstance().addMonitor(this); 
 
    registerPointerSpeedSettingObserver(); 
    registerShowTouchesSettingObserver(); 
    registerAccessibilityLargePointerSettingObserver(); 
 
    mContext.registerReceiver(new BroadcastReceiver() {        @Override 
        public void onReceive(Context context, Intent intent) { 
            updatePointerSpeedFromSettings(); 
            updateShowTouchesFromSettings(); 
            updateAccessibilityLargePointerFromSettings(); 
        } 
    }, new IntentFilter(Intent.ACTION_USER_SWITCHED), null, mHandler); 
 
    updatePointerSpeedFromSettings(); 
    updateShowTouchesFromSettings(); 
    updateAccessibilityLargePointerFromSettings(); 
} 

 顯而易見這里最值得關(guān)注的就是InputManager的start()方法了，可惜這個(gè)方法并不值得我們?nèi)绱岁P(guān)心，因?yàn)樗龅氖虑楹芎?jiǎn)單，就是啟動(dòng)InputDispatcherThread和InputReaderThread開始監(jiān)聽。 

status_t InputManager::start() { 
    status_t result = mDispatcherThread->run("InputDispatcher", PRIORITY_URGENT_DISPLAY);    if (result) { 
        ALOGE("Could not start InputDispatcher thread due to error %d.", result);        return result; 
    } 
 
    result = mReaderThread->run("InputReader", PRIORITY_URGENT_DISPLAY);    if (result) { 
        ALOGE("Could not start InputReader thread due to error %d.", result); 
 
        mDispatcherThread->requestExit();        return result; 
    }    return OK; 
} 

 那么InputReaderThread線程是怎么和EventHub關(guān)聯(lián)起來的呢?

對(duì)于InputReadThread：

• 啟動(dòng)后循環(huán)執(zhí)行mReader->loopOnce()
• loopOnce()中會(huì)調(diào)用mEventHub->getEvents讀取事件
• 讀到了事件就會(huì)調(diào)用processEventsLocked處理事件
• 處理完成后調(diào)用getInputDevicesLocked獲取輸入設(shè)備信息
• 調(diào)用mPolicy->notifyInputDevicesChanged函數(shù)利用InputManagerService的代理通過Handler發(fā)送MSG_DELIVER_INPUT_DEVICES_CHANGED消息，通知輸入設(shè)備發(fā)生了變化
• ***調(diào)用mQueuedListener->flush()，將事件隊(duì)列中的所有事件交給在InputReader中注冊(cè)過的InputDispatcher 

bool InputReaderThread::threadLoop() { 
    mReader->loopOnce();    return true; 
}void InputReader::loopOnce() { 
    …… 
 
    size_t count = mEventHub->getEvents(timeoutMillis, mEventBuffer, EVENT_BUFFER_SIZE); 
 
    { // acquire lock 
        AutoMutex _l(mLock); 
        mReaderIsAliveCondition.broadcast();        if (count) { 
            processEventsLocked(mEventBuffer, count); 
        } 
 
    ……        if (oldGeneration != mGeneration) { 
            inputDevicesChanged = true; 
            getInputDevicesLocked(inputDevices); 
        } 
    } // release lock 
 
    // Send out a message that the describes the changed input devices. 
    if (inputDevicesChanged) { 
        mPolicy->notifyInputDevicesChanged(inputDevices); 
    } 
 
    …… 
    mQueuedListener->flush(); 
} 

至此，Input系統(tǒng)有關(guān)事件輸入模塊的學(xué)習(xí)就結(jié)束了，在后續(xù)的文章中會(huì)繼續(xù)學(xué)習(xí)Input系統(tǒng)的事件歸類、分發(fā)流程，感興趣的朋友可以留意關(guān)注。