從手指接觸屏幕到MotionEvent被傳送到Activity或者View，中間究竟經歷了什么？Android中觸摸事件到底是怎么來的呢？源頭是哪呢？本文就直觀的描述一個整個流程，不求甚解，只求了解。

Android觸摸事件模型

觸摸事件肯定要先捕獲才能傳給窗口，因此，首先應該有一個線程在不斷的監聽屏幕，一旦有觸摸事件，就將事件捕獲；其次，還應該存在某種手段可以找到目標窗口，因為可能有多個App的多個界面為用戶可見，必須確定這個事件究竟通知那個窗口；最后才是目標窗口如何消費事件的問題。

十分鐘讓你了解Android觸摸事件原理（InputManagerService）

InputManagerService是Android為了處理各種用戶操作而抽象的一個服務，自身可以看做是一個Binder服務實體，在SystemServer進程啟動的時候實例化，并注冊到ServiceManager中去，不過這個服務對外主要是用來提供一些輸入設備的信息的作用，作為Binder服務的作用比較?。?/p>

private void startOtherServices() {
 ...
 inputManager = new InputManagerService(context);
 wm = WindowManagerService.main(context, inputManager,
 mFactoryTestMode != FactoryTest.FACTORY_TEST_LOW_LEVEL,
 !mFirstBoot, mOnlyCore);
 ServiceManager.addService(Context.WINDOW_SERVICE, wm);
 ServiceManager.addService(Context.INPUT_SERVICE, inputManager);
 ...
 }

InputManagerService跟WindowManagerService幾乎同時被添加，從一定程度上也能說明兩者幾乎是相生的關系，而觸摸事件的處理也確實同時涉及兩個服務，最好的證據就是WindowManagerService需要直接握著InputManagerService的引用，如果對照上面的處理模型，InputManagerService主要負責觸摸事件的采集，而WindowManagerService負責找到目標窗口。接下來，先看看InputManagerService如何完成觸摸事件的采集。

如何捕獲觸摸事件

InputManagerService會單獨開一個線程專門用來讀取觸摸事件，

NativeInputManager::NativeInputManager(jobject contextObj,
 jobject serviceObj, const sp<Looper>& looper) :
 mLooper(looper), mInteractive(true) {
 ...
 sp<EventHub> eventHub = new EventHub();
 mInputManager = new InputManager(eventHub, this, this);
}

這里有個EventHub，它主要是利用linux的inotify和epoll機制，監聽設備事件：包括設備插拔及各種觸摸、按鈕事件等，可以看做是一個不同設備的集線器，主要面向的是/dev/input目錄下的設備節點，比如說/dev/input/event0上的事件就是輸入事件，通過EventHub的getEvents就可以監聽并獲取該事件：

在new InputManager時候，會新建一個InputReader對象及InputReaderThread Loop線程，這個loop線程的主要作用就是通過EventHub的getEvents獲取Input事件

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);
}
 
bool InputReaderThread::threadLoop() {
 mReader->loopOnce();
 return true;
}
 
void InputReader::loopOnce() {
 int32_t oldGeneration;
 int32_t timeoutMillis;
 bool inputDevicesChanged = false;
 Vector<InputDeviceInfo> inputDevices;
 { 
 ...<!--監聽事件-->
 size_t count = mEventHub->getEvents(timeoutMillis, mEventBuffer, EVENT_BUFFER_SIZE);
 ....<!--處理事件-->
 processEventsLocked(mEventBuffer, count);
 ...
 <!--通知派發-->
 mQueuedListener->flush();
 }

通過上面流程，輸入事件就可以被讀取，經過processEventsLocked被初步封裝成RawEvent，最后發通知，請求派發消息。以上就解決了事件讀取問題，下面重點來看一下事件的分發。

事件的派發

在新建InputManager的時候，不僅僅創建了一個事件讀取線程，還創建了一個事件派發線程，雖然也可以直接在讀取線程中派發，但是這樣肯定會增加耗時，不利于事件的及時讀取，因此，事件讀取完畢后，直接向派發線程發個通知，請派發線程去處理，這樣讀取線程就可以更加敏捷，防止事件丟失，因此InputManager的模型就是如下樣式：

InputReader的mQueuedListener其實就是InputDispatcher對象，所以mQueuedListener->flush()就是通知InputDispatcher事件讀取完畢，可以派發事件了, InputDispatcherThread是一個典型Looper線程，基于native的Looper實現了Hanlder消息處理模型，如果有Input事件到來就被喚醒處理事件，處理完畢后繼續睡眠等待，簡化代碼如下：

bool InputDispatcherThread::threadLoop() {
 mDispatcher->dispatchOnce();
 return true;
}
 
void InputDispatcher::dispatchOnce() {
 nsecs_t nextWakeupTime = LONG_LONG_MAX;
 { 
 <!--被喚醒 ，處理Input消息-->
 if (!haveCommandsLocked()) {
 dispatchOnceInnerLocked(&nextWakeupTime);
 }
 ...
 } 
 nsecs_t currentTime = now();
 int timeoutMillis = toMillisecondTimeoutDelay(currentTime, nextWakeupTime);
 <!--睡眠等待input事件-->
 mLooper->pollOnce(timeoutMillis);
}

以上就是派發線程的模型，dispatchOnceInnerLocked是具體的派發處理邏輯，這里看其中一個分支，觸摸事件：

void InputDispatcher::dispatchOnceInnerLocked(nsecs_t* nextWakeupTime) {
 ...
 case EventEntry::TYPE_MOTION: {
 MotionEntry* typedEntry = static_cast<MotionEntry*>(mPendingEvent);
 ...
 done = dispatchMotionLocked(currentTime, typedEntry,
 &dropReason, nextWakeupTime);
 break;
 }
 
bool InputDispatcher::dispatchMotionLocked(
 nsecs_t currentTime, MotionEntry* entry, DropReason* dropReason, nsecs_t* nextWakeupTime) {
 ... 
 Vector<InputTarget> inputTargets;
 bool conflictingPointerActions = false;
 int32_t injectionResult;
 if (isPointerEvent) {
 <!--關鍵點1 找到目標Window-->
 injectionResult = findTouchedWindowTargetsLocked(currentTime,
 entry, inputTargets, nextWakeupTime, &conflictingPointerActions);
 } else {
 injectionResult = findFocusedWindowTargetsLocked(currentTime,
 entry, inputTargets, nextWakeupTime);
 }
 ...
 <!--關鍵點2 派發-->
 dispatchEventLocked(currentTime, entry, inputTargets);
 return true;
}

從以上代碼可以看出，對于觸摸事件會首先通過findTouchedWindowTargetsLocked找到目標Window，進而通過dispatchEventLocked將消息發送到目標窗口，下面看一下如何找到目標窗口，以及這個窗口列表是如何維護的。

如何為觸摸事件找到目標窗口

Android系統能夠同時支持多塊屏幕，每塊屏幕被抽象成一個DisplayContent對象，內部維護一個WindowList列表對象，用來記錄當前屏幕中的所有窗口，包括狀態欄、導航欄、應用窗口、子窗口等。對于觸摸事件，我們比較關心可見窗口，用adb shell dumpsys SurfaceFlinger看一下可見窗口的組織形式：

那么，如何找到觸摸事件對應的窗口呢，是狀態欄、導航欄還是應用窗口呢，這個時候DisplayContent的WindowList就發揮作用了，DisplayContent握著所有窗口的信息，因此，可以根據觸摸事件的位置及窗口的屬性來確定將事件發送到哪個窗口，當然其中的細節比一句話復雜的多，跟窗口的狀態、透明、分屏等信息都有關系，下面簡單瞅一眼，達到主觀理解的流程就可以了，

int32_t InputDispatcher::findTouchedWindowTargetsLocked(nsecs_t currentTime,
 const MotionEntry* entry, Vector<InputTarget>& inputTargets, nsecs_t* nextWakeupTime,
 bool* outConflictingPointerActions) {
 ...
 sp<InputWindowHandle> newTouchedWindowHandle;
 bool isTouchModal = false;
 <!--遍歷所有窗口-->
 size_t numwindows = mWindowHandles.size();
 for (size_t i = 0; i < numWindows; i++) {
 sp<InputWindowHandle> windowHandle = mWindowHandles.itemAt(i);
 const InputWindowInfo* windowInfo = windowHandle->getInfo();
 if (windowInfo->displayId != displayId) {
 continue; // wrong display
 }
 int32_t flags = windowInfo->layoutParamsFlags;
 if (windowInfo->visible) {
 if (! (flags & InputWindowInfo::FLAG_NOT_TOUCHABLE)) {
 isTouchModal = (flags & (InputWindowInfo::FLAG_NOT_FOCUSABLE
 | InputWindowInfo::FLAG_NOT_TOUCH_MODAL)) == 0;
 <!--找到目標窗口-->
 if (isTouchModal || windowInfo->touchableRegionContainsPoint(x, y)) {
 newTouchedWindowHandle = windowHandle;
 break; // found touched window, exit window loop
 }
 }
 ...

mWindowHandles代表著所有窗口，findTouchedWindowTargetsLocked的就是從mWindowHandles中找到目標窗口，規則太復雜，總之就是根據點擊位置更窗口Z order之類的特性去確定，有興趣可以自行分析。不過這里需要關心的是mWindowHandles，它就是是怎么來的，另外窗口增刪的時候如何保持最新的呢？這里就牽扯到跟WindowManagerService交互的問題了，mWindowHandles的值是在InputDispatcher::setInputWindows中設置的，

void InputDispatcher::setInputWindows(const Vector<sp<InputWindowHandle> >& inputWindowHandles) {
 ...
 mWindowHandles = inputWindowHandles;
 ...

誰會調用這個函數呢？真正的入口是WindowManagerService中的InputMonitor會簡介調用InputDispatcher::setInputWindows，這個時機主要是跟窗口增改刪除等邏輯相關，以addWindow為例：

從上面流程可以理解為什么說WindowManagerService跟InputManagerService是相輔相成的了，到這里，如何找到目標窗口已經解決了，下面就是如何將事件發送到目標窗口的問題了。

如何將事件發送到目標窗口

找到了目標窗口，同時也將事件封裝好了，剩下的就是通知目標窗口，可是有個最明顯的問題就是，目前所有的邏輯都是在SystemServer進程，而要通知的窗口位于APP端的用戶進程，那么如何通知呢？下意識的可能會想到Binder通信，畢竟Binder在Android中是使用最多的IPC手段了，不過Input事件處理這采用的卻不是Binder：高版本的采用的都是Socket的通信方式，而比較舊的版本采用的是Pipe管道的方式。

void InputDispatcher::dispatchEventLocked(nsecs_t currentTime,
 EventEntry* eventEntry, const Vector<InputTarget>& inputTargets) {
 pokeUserActivityLocked(eventEntry);
 for (size_t i = 0; i < inputTargets.size(); i++) {
 const InputTarget& inputTarget = inputTargets.itemAt(i);
 ssize_t connectionIndex = getConnectionIndexLocked(inputTarget.inputChannel);
 if (connectionIndex >= 0) {
 sp<Connection> connection = mConnectionsByFd.valueAt(connectionIndex);
 preparedispatchCycleLocked(currentTime, connection, eventEntry, &inputTarget);
 } else {
 }
 }
}

代碼逐層往下看會發現最后會調用到InputChannel的sendMessage函數，最會通過socket發送到APP端（Socket怎么來的接下來會分析），

這個Socket是怎么來的呢？或者說兩端通信的一對Socket是怎么來的呢？其實還是要牽扯到WindowManagerService，在APP端向WMS請求添加窗口的時候，會伴隨著Input通道的創建，窗口的添加一定會調用ViewRootImpl的setView函數：

ViewRootImpl

public void setView(View view, WindowManager.LayoutParams attrs, View panelParentView) {
 ...
 requestLayout();
 if ((mWindowAttributes.inputFeatures
 & WindowManager.LayoutParams.INPUT_FEATURE_NO_INPUT_CHANNEL) == 0) {
 <!--創建InputChannel容器-->
 mInputChannel = new InputChannel();
 }
 try {
 mOrigWindowType = mWindowAttributes.type;
 mAttachInfo.mRecomputeGlobalAttributes = true;
 collectViewAttributes();
 <!--添加窗口，并請求開辟Socket Input通信通道-->
 res = mWindowSession.addToDisplay(mWindow, mSeq, mWindowAttributes,
 getHostVisibility(), mDisplay.getDisplayId(),
 mAttachInfo.mContentInsets, mAttachInfo.mStableInsets,
 mAttachInfo.mOutsets, mInputChannel);
 }...
 <!--監聽，開啟Input信道-->
 if (mInputChannel != null) {
 if (mInputQueueCallback != null) {
 mInputQueue = new InputQueue();
 mInputQueueCallback.onInputQueueCreated(mInputQueue);
 }
 mInputEventReceiver = new WindowInputEventReceiver(mInputChannel,
 Looper.myLooper());
 }

在IWindowSession.aidl定義中 InputChannel是out類型，也就是說需要服務端進行填充，那么接著看服務端WMS如何填充的呢？

public int addWindow(Session session, IWindow client, int seq,
 WindowManager.LayoutParams attrs, int viewVisibility, int displayId,
 Rect outContentInsets, Rect outStableInsets, Rect outOutsets,
 InputChannel outInputChannel) { 
 ...
 if (outInputChannel != null && (attrs.inputFeatures
 & WindowManager.LayoutParams.INPUT_FEATURE_NO_INPUT_CHANNEL) == 0) {
 String name = win.makeInputChannelName();
 <!--關鍵點1創建通信信道 -->
 InputChannel[] inputChannels = InputChannel.openInputChannelPair(name);
 <!--本地用-->
 win.setInputChannel(inputChannels[0]);
 <!--APP端用-->
 inputChannels[1].transferTo(outInputChannel);
 <!--注冊信道與窗口-->
 mInputManager.registerInputChannel(win.mInputChannel, win.mInputWindowHandle);
 }

WMS首先創建socketpair作為全雙工通道，并分別填充到Client與Server的InputChannel中去；之后讓InputManager將Input通信信道與當前的窗口ID綁定，這樣就能知道哪個窗口用哪個信道通信了；最后通過Binder將outInputChannel回傳到APP端，下面是SocketPair的創建代碼：

status_t InputChannel::openInputChannelPair(const String8& name,
 sp<InputChannel>& outServerChannel, sp<InputChannel>& outClientChannel) {
 int sockets[2];
 if (socketpair(AF_UNIX, SOCK_SEQPACKET, 0, sockets)) {
 status_t result = -errno;
 ...
 return result;
 }
 
 int bufferSize = SOCKET_BUFFER_SIZE;
 setsockopt(sockets[0], SOL_SOCKET, SO_SNDBUF, &bufferSize, sizeof(bufferSize));
 setsockopt(sockets[0], SOL_SOCKET, SO_RCVBUF, &bufferSize, sizeof(bufferSize));
 setsockopt(sockets[1], SOL_SOCKET, SO_SNDBUF, &bufferSize, sizeof(bufferSize));
 setsockopt(sockets[1], SOL_SOCKET, SO_RCVBUF, &bufferSize, sizeof(bufferSize));
 <!--填充到server inputchannel-->
 String8 serverChannelName = name;
 serverChannelName.append(" (server)");
 outServerChannel = new InputChannel(serverChannelName, sockets[0]);
 <!--填充到client inputchannel-->
 String8 clientChannelName = name;
 clientChannelName.append(" (client)");
 outClientChannel = new InputChannel(clientChannelName, sockets[1]);
 return OK;
}

這里socketpair的創建與訪問其實是還是借助文件描述符，WMS需要借助Binder通信向APP端回傳文件描述符fd，這部分只是可以參考Binder知識，主要是在內核層面實現兩個進程fd的轉換，窗口添加成功后，socketpair被創建，被傳遞到了APP端，但是信道并未完全建立，因為還需要一個主動的監聽，畢竟消息到來是需要通知的，先看一下信道模型

APP端的監聽消息的手段是：將socket添加到Looper線程的epoll數組中去，一有消息到來Looper線程就會被喚醒，并獲取事件內容，從代碼上來看，通信信道的打開是伴隨WindowInputEventReceiver的創建來完成的。

信息到來，Looper根據fd找到對應的監聽器：NativeInputEventReceiver，并調用handleEvent處理對應事件

int NativeInputEventReceiver::handleEvent(int receiveFd, int events, void* data) {
 ...
 if (events & ALOOPER_EVENT_INPUT) {
 JNIEnv* env = AndroidRuntime::getJNIEnv();
 status_t status = consumeEvents(env, false /*consumeBatches*/, -1, NULL);
 mMessageQueue->raiseAndClearException(env, "handleReceiveCallback");
 return status == OK || status == NO_MEMORY ? 1 : 0;
 }
 ...

之后會進一步讀取事件，并封裝成JAVA層對象，傳遞給Java層，進行相應的回調處理：

status_t NativeInputEventReceiver::consumeEvents(JNIEnv* env, 
 bool consumeBatches, nsecs_t frameTime, bool* outConsumedBatch) { 
 ...
 for (;;) { 
 uint32_t seq; 
 InputEvent* inputEvent; 
 <!--獲取事件-->
 status_t status = mInputConsumer.consume(&mInputEventFactory, 
 consumeBatches, frameTime, &seq, &inputEvent); 
 ...
 <!--處理touch事件-->
 case AINPUT_EVENT_TYPE_MOTION: {
 MotionEvent* motionEvent = static_cast<MotionEvent*>(inputEvent);
 if ((motionEvent->getAction() & AMOTION_EVENT_ACTION_MOVE) && outConsumedBatch) {
 *outConsumedBatch = true;
 }
 inputEventObj = android_view_MotionEvent_obtainAsCopy(env, motionEvent);
 break;
 } 
 <!--回調處理函數-->
 if (inputEventObj) {
 env->CallVoidMethod(receiverObj.get(),
 gInputEventReceiverClassInfo.dispatchInputEvent, seq, inputEventObj);
 env->DeleteLocalRef(inputEventObj);
 }

所以最后就是觸摸事件被封裝成了inputEvent，并通過InputEventReceiver的dispatchInputEvent（WindowInputEventReceiver）進行處理，這里就返回到我們常見的Java世界了。

目標窗口中的事件處理

最后簡單看一下事件的處理流程，Activity或者Dialog等是如何獲得Touch事件的呢？如何處理的呢？直白的說就是將監聽事件交給ViewRootImpl中的rootView，讓它自己去負責完成事件的消費，究竟最后被哪個View消費了要看具體實現了，而對于Activity與Dialog中的DecorView重寫了View的事件分配函數dispatchTouchEvent，將事件處理交給了CallBack對象處理，至于View及ViewGroup的消費，算View自身的邏輯了。