您好,登錄后才能下訂單哦!
這篇文章主要講解了“Android中如何利用Input子系統監聽線程的啟動”,文中的講解內容簡單清晰,易于學習與理解,下面請大家跟著小編的思路慢慢深入,一起來研究和學習“Android中如何利用Input子系統監聽線程的啟動”吧!
InputManagerService初始化概覽
首先,有幾點共識我們都可以達成:
Android Framework層的Service(Java)都是由system_server進程創建的(由于沒有fork,因此都運行在system_server進程中)
Service創建后就會交給運行在system_server進程中的ServiceManager管理。
因此對于InputManagerService的創建,我們可以在SystemServer的startOtherServices()方法中找到,該方法做了以下事情:
創建InputManagerService對象
將它交給ServiceManager管理
將WindowManagerService的InputMonitor注冊到InputManagerService中作為窗口響應事件后的回調
完成以上工作后啟動InputManagerService。
SystemServer.javastartOtherServices(){ …… inputManager = new InputManagerService(context); …… inputManager.setWindowManagerCallbacks(wm.getInputMonitor()); inputManager.start(); …… }
接下來我們就逐部分學習相應的處理。
InputManagerService對象的創建
創建InputManagerService對象時會完成以下工作:
創建一個負責處理DisplayThread線程中的Message的Handler
調用nativeInit初始化native層的InputManagerService,初始化的時候傳入了DisplayThread的消息隊列
用mPtr保存native層的InputManagerService
初始化完成后將Service添加到LocalServices,通過Map以鍵值對的形式存儲
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()); }
這里可能有人就會問了,為什么InputManagerService要和DisplayThread綁定在一起?大家不妨想想,InputEvent無論如何被獲取、歸類、分發,最終還是要被處理,也就意味著最終它的處理結果都要在UI上體現,那么InputManagerService自然要選擇和UI親近一些的線程在一起了。
但是問題又來了,應用都是運行在自己的主線程里的,難道InputManagerService要一個個綁定么,還是一個個輪詢?這些做法都太過低效,那換個辦法,可不可以和某個管理或非常親近所有應用UI的線程綁定在一起呢?
答案是什么,我在這里先不說,大家可以利用自己的知識想想。
初始化native層的InputManagerService
在nativeInit函數中,將Java層的MessageQueue轉換為native層的MessageQueue,然后再取出Looper用于NativeInputManager的初始化。可見這里的重頭戲就是NativeInputManager的創建,這個過程做了以下事情:
將Java層的Context和InputManagerService轉換為native層的Context和InputManagerService存儲在mContextObj和mServiceObj中
初始化變量
創建EventHub
創建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
看到這里很多人就會想,EventHub是什么?取英語釋義來看,它的意思是事件樞紐。我們在文章開頭的時候也提到過,Input系統的事件來源于驅動/內核,那么我們可以猜測EventHub是處理來自驅動/內核的元事件的樞紐。接下來就在源碼中驗證我們的想法吧。
EventHub的創建過程中做了以下事情:
創建mEpollFd用于監聽是否有數據(有無事件)可讀
創建mINotifyFd將它注冊到DEVICE_PATH(這里路徑就是/dev/input)節點,并將它交給內核用于監聽該設備節點的增刪數據事件。那么只要有數據增刪的事件到來,epoll_wait()就會返回,使得EventHub能收到來自系統的通知,并獲取事件的詳細信息
調用epoll_ctl函數將mEpollFd和mINotifyFd注冊到epoll中
定義int wakeFd[2]作為事件傳輸管道的讀寫兩端,并將讀端注冊到epoll中讓mEpollFd監聽
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); …… }
那么這里拋出一個問題:為什么要把管道的讀端注冊到epoll中?假如EventHub因為getEvents讀不到事件而阻塞在epoll_wait()里,而我們沒有綁定讀端的話,我們要怎么喚醒EventHub?如果綁定了管道的讀端,我們就可以通過向管道的寫端寫數據從而讓EventHub因為得到管道寫端的數據而被喚醒。
InputManager的創建
接下來繼續說InputManager的創建,它的創建就簡單多了,創建一個InputDispatcher對象用于分發事件,一個InputReader對象用于讀事件并把事件交給InputDispatcher分發,,然后調用initialize()初始化,其實也就是創建了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的創建都相對簡單。InputDispatcher會創建自己線程的Looper,以及設置根據傳入的dispatchPolicy設置分發規則。InputReader則會將傳入的InputDispatcher封裝為監聽對象存起來,做一些數據初始化就結束了。
至此,InputManagerService對象的初始化就完成了,根據開頭說的,接下來就會調用InputManagerService的start()方法。
監聽線程InputReader和InputDispatcher的啟動
在start()方法中,做了以下事情:
調用nativeStart方法,其實就是調用InputManager的start()方法
將InputManagerService交給WatchDog監控
注冊觸控點速度、顯示觸控的觀察者,并注冊廣播監控它們
主動調用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(); }
顯而易見這里最值得關注的就是InputManager的start()方法了,可惜這個方法并不值得我們如此關心,因為它做的事情很簡單,就是啟動InputDispatcherThread和InputReaderThread開始監聽。
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關聯起來的呢?
對于InputReadThread:
啟動后循環執行mReader->loopOnce()
loopOnce()中會調用mEventHub->getEvents讀取事件
讀到了事件就會調用processEventsLocked處理事件
處理完成后調用getInputDevicesLocked獲取輸入設備信息
調用mPolicy->notifyInputDevicesChanged函數利用InputManagerService的代理通過Handler發送MSG_DELIVER_INPUT_DEVICES_CHANGED消息,通知輸入設備發生了變化
***調用mQueuedListener->flush(),將事件隊列中的所有事件交給在InputReader中注冊過的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(); }
感謝各位的閱讀,以上就是“Android中如何利用Input子系統監聽線程的啟動”的內容了,經過本文的學習后,相信大家對Android中如何利用Input子系統監聽線程的啟動這一問題有了更深刻的體會,具體使用情況還需要大家實踐驗證。這里是億速云,小編將為大家推送更多相關知識點的文章,歡迎關注!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。