Android应用程序键盘（Keyboard）消息处理机制分析

在Android系统中，键盘按键事件是由WindowManagerService服务来管理的，然后再以消息的形式来分发给应用程序处理，不过和普通消息不一样，它是由硬件中断触发的；在上一篇文章《Android应用程序消息处理机制（Looper、Handler）分析》中，我们分析了Android应用程序的消息处理机制，本文将结合这种消息处理机制来详细分析Android应用程序是如何获得键盘按键消息的。

        在系统启动的时候，SystemServer会启动窗口管理服务WindowManagerService，WindowManagerService在启动的时候就会通过系统输入管理器InputManager来总负责监控键盘消息。这些键盘消息一般都是分发给当前激活的Activity窗口来处理的，因此，当前激活的Activity窗口在创建的时候，会到WindowManagerService中去注册一个接收键盘消息的通道，表明它要处理键盘消息，而当InputManager监控到有键盘消息时，就会分给给它处理。当当前激活的Activity窗口不再处于激活状态时，它也会到WindowManagerService中去反注册之前的键盘消息接收通道，这样，InputManager就不会再把键盘消息分发给它来处理。

        由于本文的内容比较多，在接下面的章节中，我们将分为五个部分来详细描述Android应用程序获得键盘按键消息的过程，每一个部分都是具体描述键盘消息处理过程中的一个过程。结合上面的键盘消息处理框架，这四个过程分别是InputManager的启动过程、应用程序注册键盘消息接收通道的过程、InputManager分发键盘消息给应用程序的过程以及应用程序注销键盘消息接收通道的过程。为了更好地理解Android应用程序获得键盘按键消息的整个过程，建议读者首先阅读Android应用程序消息处理机制（Looper、Handler）分析一文，理解了Android应用程序的消息处理机制后，就能很好的把握本文的内容。

        1. InputManager的启动过程分析 

        前面说过，Android系统的键盘事件是由InputManager来监控的，而InputManager是由窗口管理服务WindowManagerService来启动的。

        从前面一篇文章Android系统进程Zygote启动过程的源代码分析中，我们知道在Android系统中，Zygote进程负责启动系统服务进程SystemServer，而系统服务进程SystemServer负责启动系统中的各种关键服务，例如我们在前面两篇文章Android应用程序安装过程源代码分析和Android系统默认Home应用程序（Launcher）的启动过程源代码分析中提到的Package管理服务PackageManagerService和Activity管理服务ActivityManagerService。这里我们所讨论的窗口管理服务WindowManagerService也是由SystemServer来启动的，具体的启动过程这里就不再详述了，具体可以参考PackageManagerService和ActivityManagerService的启动过程。

       了解了WindowManagerService的启动过程之后，我们就可以继续分析InputManager的启动过程了。我们先来看一下InputManager启动过程的序列图，然后根据这个序列图来一步步分析它的启动过程：

Step 1. WindowManagerService.main

        这个函数定义在frameworks/base/services/java/com/android/server/WindowManagerService.java文件中：

 public class WindowManagerService extends IWindowManager.Stub
         implements Watchdog.Monitor {
     ......

     public static WindowManagerService main(Context context,
             PowerManagerService pm, boolean haveInputMethods) {
         WMThread thr = new WMThread(context, pm, haveInputMethods);
         thr.start();

         synchronized (thr) {
             while (thr.mService == null) {
                 try {
                     thr.wait();
                 } catch (InterruptedException e) {
                 }
             }
             return thr.mService;
         }
     }

     ......
 }

        它通过一个线程WMThread实例来执行全局唯一的WindowManagerService实例的启动操作。这里调用WMThread实例thr的start成员函数时，会进入到WMThread实例thr的run函数中去。

        Step 2. WMThread.run

        这个函数定义在frameworks/base/services/java/com/android/server/WindowManagerService.java文件中：

 public class WindowManagerService extends IWindowManager.Stub
         implements Watchdog.Monitor {
     ......

     static class WMThread extends Thread {
         ......

         public void run() {
             ......

             WindowManagerService s = new WindowManagerService(mContext, mPM,
                 mHaveInputMethods);
             ......
         }
     }


     ......
 }

       这里执行的主要操作就是创建一个WindowManagerService实例，这样会调用到WindowManagerService构造函数中去。

       Step 3. WindowManagerService<init>

       WindowManagerService类的构造函数定义在frameworks/base/services/java/com/android/server/WindowManagerService.java文件中：

 public class WindowManagerService extends IWindowManager.Stub
         implements Watchdog.Monitor {
     ......

     final InputManager mInputManager;

     ......

     private WindowManagerService(Context context, PowerManagerService pm,
             boolean haveInputMethods) {
         ......

         mInputManager = new InputManager(context, this);

         ......

         mInputManager.start();

         ......
     }


     ......
 }

         这里我们只关心InputManager的创建过程，而忽略其它无关部分。首先是创建一个InputManager实例，然后再调用它的start成员函数来监控键盘事件。在创建InputManager实例的过程中，会执行一些初始化工作，因此，我们先进入到InputManager类的构造函数去看看，然后再回过头来分析它的start成员函数。

         Step 4. InputManager<init>@java

         Java层的InputManager类的构造函数定义在frameworks/base/services/java/com/android/server/InputManager.java文件中：

 public class InputManager {
     ......

     public InputManager(Context context, WindowManagerService windowManagerService) {
         this.mContext = context;
         this.mWindowManagerService = windowManagerService;

         this.mCallbacks = new Callbacks();

         init();
     }

     ......
 }

        这里只是简单地初始化InputManager类的一些成员变量，然后调用init函数进一步执行初始化操作。

        Step 5. InputManager.init

        这个函数定义在frameworks/base/services/java/com/android/server/InputManager.java文件中：

 public class InputManager {
     ......

     private void init() {
         Slog.i(TAG, "Initializing input manager");
         nativeInit(mCallbacks);
     }

     ......
 }

       函数init通过调用本地方法nativeInit来执行C++层的相关初始化操作。

       Step 6. InputManager.nativeInit

       这个函数定义在frameworks/base/services/jni$ vi com_android_server_InputManager.cpp文件中：

 static void android_server_InputManager_nativeInit(JNIEnv* env, jclass clazz,
         jobject callbacks) {
     if (gNativeInputManager == NULL) {
         gNativeInputManager = new NativeInputManager(callbacks);
     } else {
         LOGE("Input manager already initialized.");
         jniThrowRuntimeException(env, "Input manager already initialized.");
     }
 }

        这个函数的作用是创建一个NativeInputManager实例，并保存在gNativeInputManager变量中。由于是第一次调用到这里，因此，gNativeInputManager为NULL，于是就会new一个NativeInputManager对象出来，这样就会执行NativeInputManager类的构造函数来执其它的初始化操作。

       Step 7. NativeInputManager<init>

       NativeInputManager类的构造函数定义在frameworks/base/services/jni$ vi com_android_server_InputManager.cpp文件中：

 NativeInputManager::NativeInputManager(jobject callbacksObj) :
     mFilterTouchEvents(-1), mFilterJumpyTouchEvents(-1), mVirtualKeyQuietTime(-1),
     mMaxEventsPerSecond(-1),
     mDisplayWidth(-1), mDisplayHeight(-1), mDisplayOrientation(ROTATION_0) {
     JNIEnv* env = jniEnv();

     mCallbacksObj = env->NewGlobalRef(callbacksObj);

     sp<EventHub> eventHub = new EventHub();
     mInputManager = new InputManager(eventHub, this, this);
 }

        这里只要是创建了一个EventHub实例，并且把这个EventHub作为参数来创建InputManager对象。注意，这里的InputManager类是定义在C++层的，和前面在Java层的InputManager不一样，不过它们是对应关系。EventHub类是真正执行监控键盘事件操作的地方，后面我们会进一步分析到，现在我们主要关心InputManager实例的创建过程，它会InputManager类的构造函数里面执行一些初始化操作。

        Step 8. InputManager<init>@C++

        C++层的InputManager类的构造函数定义在frameworks/base/libs/ui/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();
 }

        这里主要是创建了一个InputDispatcher对象和一个InputReader对象，并且分别保存在成员变量mDispatcher和mReader中。InputDispatcher类是负责把键盘消息分发给当前激活的Activity窗口的，而InputReader类则是通过EventHub类来实现读取键盘事件的，后面我们会进一步分析。创建了这两个对象后，还要调用initialize函数来执行其它的初始化操作。

        Step 9. InputManager.initialize

        这个函数定义在frameworks/base/libs/ui/InputManager.cpp 文件中：

 void InputManager::initialize() {
     mReaderThread = new InputReaderThread(mReader);
     mDispatcherThread = new InputDispatcherThread(mDispatcher);
 }

        这个函数创建了一个InputReaderThread线程实例和一个InputDispatcherThread线程实例，并且分别保存在成员变量mReaderThread和mDispatcherThread中。这里的InputReader实列mReader就是通过这里的InputReaderThread线程实列mReaderThread来读取键盘事件的，而InputDispatcher实例mDispatcher则是通过这里的InputDispatcherThread线程实例mDisptacherThread来分发键盘消息的。

        至此，InputManager的初始化工作就完成了，在回到Step 3中继续分析InputManager的进一步启动过程之前，我们先来作一个小结，看看这个初始化过程都做什么事情：

        A. 在Java层中的WindowManagerService中创建了一个InputManager对象，由它来负责管理Android应用程序框架层的键盘消息处理；

        B. 在C++层也相应地创建一个InputManager本地对象来负责监控键盘事件；

        C. 在C++层中的InputManager对象中，分别创建了一个InputReader对象和一个InputDispatcher对象，前者负责读取系统中的键盘消息，后者负责把键盘消息分发出去；

        D. InputReader对象和一个InputDispatcher对象分别是通过InputReaderThread线程实例和InputDispatcherThread线程实例来实键盘消息的读取和分发的。

        有了这些对象之后，万事就俱备了，回到Step 3中，调用InputManager类的start函数来执行真正的启动操作。

        Step 10. InputManager.start

        这个函数定义在frameworks/base/services/java/com/android/server/InputManager.java文件中：

 public class InputManager {
     ......

     public void start() {
         Slog.i(TAG, "Starting input manager");
         nativeStart();
     }

     ......
 }

        这个函数通过调用本地方法nativeStart来执行进一步的启动操作。

        Step 11. InputManager.nativeStart

        这个函数定义在frameworks/base/services/jni$ vi com_android_server_InputManager.cpp文件中：

 static void android_server_InputManager_nativeStart(JNIEnv* env, jclass clazz) {
     if (checkInputManagerUnitialized(env)) {
         return;
     }

     status_t result = gNativeInputManager->getInputManager()->start();
     if (result) {
         jniThrowRuntimeException(env, "Input manager could not be started.");
     }
 }

        这里的gNativeInputManager对象是在前面的Step 6中创建的，通过它的getInputManager函数可以返回C++层的InputManager对象，接着调用这个InputManager对象的start函数。

        Step 12. InputManager.start

        这个函数定义在frameworks/base/libs/ui/InputManager.cpp 文件中：

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

     result = mReaderThread->run("InputReader", PRIORITY_URGENT_DISPLAY);
     if (result) {
         LOGE("Could not start InputReader thread due to error %d.", result);

         mDispatcherThread->requestExit();
         return result;
     }

     return OK;
 }

        这个函数主要就是分别启动一个InputDispatcherThread线程和一个InputReaderThread线程来读取和分发键盘消息的了。这里的InputDispatcherThread线程对象mDispatcherThread和InputReaderThread线程对象是在前面的Step 9中创建的，调用了它们的run函数后，就会进入到它们的threadLoop函数中去，只要threadLoop函数返回true，函数threadLoop就会一直被循环调用，于是这两个线程就起到了不断地读取和分发键盘消息的作用。

        我们先来分析InputDispatcherThread线程分发消息的过程，然后再回过头来分析InputReaderThread线程读取消息的过程。

        Step 13. InputDispatcherThread.threadLoop

        这个函数定义在frameworks/base/libs/ui/InputDispatcher.cpp文件中：

 bool InputDispatcherThread::threadLoop() {
     mDispatcher->dispatchOnce();
     return true;
 }

        这里的成员变量mDispatcher即为在前面Step 8中创建的InputDispatcher对象，调用它的dispatchOnce成员函数执行一次键盘消息分发的操作。

        Step 14. InputDispatcher.dispatchOnce

        这个函数定义在frameworks/base/libs/ui/InputDispatcher.cpp文件中：

 void InputDispatcher::dispatchOnce() {
     nsecs_t keyRepeatTimeout = mPolicy->getKeyRepeatTimeout();
     nsecs_t keyRepeatDelay = mPolicy->getKeyRepeatDelay();

     nsecs_t nextWakeupTime = LONG_LONG_MAX;
     { // acquire lock
         AutoMutex _l(mLock);
         dispatchOnceInnerLocked(keyRepeatTimeout, keyRepeatDelay, & nextWakeupTime);

         if (runCommandsLockedInterruptible()) {
             nextWakeupTime = LONG_LONG_MIN;  // force next poll to wake up immediately
         }
     } // release lock

     // Wait for callback or timeout or wake.  (make sure we round up, not down)
     nsecs_t currentTime = now();
     int32_t timeoutMillis;
     if (nextWakeupTime > currentTime) {
         uint64_t timeout = uint64_t(nextWakeupTime - currentTime);
         timeout = (timeout + 999999LL) / 1000000LL;
         timeoutMillis = timeout > INT_MAX ? -1 : int32_t(timeout);
     } else {
         timeoutMillis = 0;
     }

     mLooper->pollOnce(timeoutMillis);
 }

        这个函数很简单，把键盘消息交给dispatchOnceInnerLocked函数来处理，这个过程我们在后面再详细分析，然后调用mLooper->pollOnce函数等待下一次键盘事件的发生。这里的成员变量mLooper的类型为Looper，它定义在C++层中，具体可以参考前面 Android应用程序消息处理机制（Looper、Handler）分析 一文。

        Step 15. Looper.pollOnce

        这个函数定义在frameworks/base/libs/utils/Looper.cpp文件中，具体可以参考前面Android应用程序消息处理机制（Looper、Handler）分析一文，这里就不再详述了。总的来说，就是在Looper类中，会创建一个管道，当调用Looper类的pollOnce函数时，如果管道中没有内容可读，那么当前线程就会进入到空闲等待状态；当有键盘事件发生时，InputReader就会往这个管道中写入新的内容，这样就会唤醒前面正在等待键盘事件发生的线程。

        InputDispatcher类分发消息的过程就暂时分析到这里，后面会有更进一步的分析，现在，我们回到Step 12中，接着分析InputReader类读取键盘事件的过程。在调用了InputReaderThread线程类的run就函数后，同样会进入到InputReaderThread线程类的threadLoop函数中去。

        Step 16. InputReaderThread.threadLoop

        这个函数定义在frameworks/base/libs/ui/InputReader.cpp文件中：

 bool InputReaderThread::threadLoop() {
     mReader->loopOnce();
     return true;
 }

       这里的成员变量mReader即为在前面Step 8中创建的InputReader对象，调用它的loopOnce成员函数执行一次键盘事件的读取操作。

       Step 17. InputReader.loopOnce

       这个函数定义在frameworks/base/libs/ui/InputReader.cpp文件中：

 void InputReader::loopOnce() {
     RawEvent rawEvent;
     mEventHub->getEvent(& rawEvent);

 #if DEBUG_RAW_EVENTS
     LOGD("Input event: device=0x%x type=0x%x scancode=%d keycode=%d value=%d",
         rawEvent.deviceId, rawEvent.type, rawEvent.scanCode, rawEvent.keyCode,
         rawEvent.value);
 #endif

     process(& rawEvent);
 }

        这里通过成员函数mEventHub来负责键盘消息的读取工作，如果当前有键盘事件发生或者有键盘事件等待处理，通过mEventHub的getEvent函数就可以得到这个事件，然后交给process函数进行处理，这个函数主要就是唤醒前面的InputDispatcherThread线程，通知它有新的键盘事件发生了，它需要进行一次键盘消息的分发操作了，这个函数我们后面再进一步详细分析；如果没有键盘事件发生或者没有键盘事件等待处理，那么调用mEventHub的getEvent函数时就会进入等待状态。

        Step 18. EventHub.getEvent

        这个函数定义在frameworks/base/libs/ui/EventHub.cpp文件中：

 bool EventHub::getEvent(RawEvent* outEvent)
 {
     outEvent->deviceId = 0;
     outEvent->type = 0;
     outEvent->scanCode = 0;
     outEvent->keyCode = 0;
     outEvent->flags = 0;
     outEvent->value = 0;
     outEvent->when = 0;

     // Note that we only allow one caller to getEvent(), so don't need
     // to do locking here...  only when adding/removing devices.

     if (!mOpened) {
         mError = openPlatformInput() ? NO_ERROR : UNKNOWN_ERROR;
         mOpened = true;
         mNeedToSendFinishedDeviceScan = true;
     }

     for (;;) {
         // Report any devices that had last been added/removed.
         if (mClosingDevices != NULL) {
             device_t* device = mClosingDevices;
             LOGV("Reporting device closed: id=0x%x, name=%s\n",
                 device->id, device->path.string());
             mClosingDevices = device->next;
             if (device->id == mFirstKeyboardId) {
                 outEvent->deviceId = 0;
             } else {
                 outEvent->deviceId = device->id;
             }
             outEvent->type = DEVICE_REMOVED;
             outEvent->when = systemTime(SYSTEM_TIME_MONOTONIC);
             delete device;
             mNeedToSendFinishedDeviceScan = true;
             return true;
         }

         if (mOpeningDevices != NULL) {
             device_t* device = mOpeningDevices;
             LOGV("Reporting device opened: id=0x%x, name=%s\n",
                 device->id, device->path.string());
             mOpeningDevices = device->next;
             if (device->id == mFirstKeyboardId) {
                 outEvent->deviceId = 0;
             } else {
                 outEvent->deviceId = device->id;
             }
             outEvent->type = DEVICE_ADDED;
             outEvent->when = systemTime(SYSTEM_TIME_MONOTONIC);
             mNeedToSendFinishedDeviceScan = true;
             return true;
         }

         if (mNeedToSendFinishedDeviceScan) {
             mNeedToSendFinishedDeviceScan = false;
             outEvent->type = FINISHED_DEVICE_SCAN;
             outEvent->when = systemTime(SYSTEM_TIME_MONOTONIC);
             return true;
         }

         // Grab the next input event.
         for (;;) {
             // Consume buffered input events, if any.
             if (mInputBufferIndex < mInputBufferCount) {
                 const struct input_event& iev = mInputBufferData[mInputBufferIndex++];
                 const device_t* device = mDevices[mInputDeviceIndex];

                 LOGV("%s got: t0=%d, t1=%d, type=%d, code=%d, v=%d", device->path.string(),
                     (int) iev.time.tv_sec, (int) iev.time.tv_usec, iev.type, iev.code, iev.value);
                 if (device->id == mFirstKeyboardId) {
                     outEvent->deviceId = 0;
                 } else {
                     outEvent->deviceId = device->id;
                 }
                 outEvent->type = iev.type;
                 outEvent->scanCode = iev.code;
                 if (iev.type == EV_KEY) {
                     status_t err = device->layoutMap->map(iev.code,
                         & outEvent->keyCode, & outEvent->flags);
                     LOGV("iev.code=%d keyCode=%d flags=0x%08x err=%d\n",
                         iev.code, outEvent->keyCode, outEvent->flags, err);
                     if (err != 0) {
                         outEvent->keyCode = AKEYCODE_UNKNOWN;
                         outEvent->flags = 0;
                     }
                 } else {
                     outEvent->keyCode = iev.code;
                 }
                 outEvent->value = iev.value;

                 // Use an event timestamp in the same timebase as
                 // java.lang.System.nanoTime() and android.os.SystemClock.uptimeMillis()
                 // as expected by the rest of the system.
                 outEvent->when = systemTime(SYSTEM_TIME_MONOTONIC);
                 return true;
             }

             // Finish reading all events from devices identified in previous poll().
             // This code assumes that mInputDeviceIndex is initially 0 and that the
             // revents member of pollfd is initialized to 0 when the device is first added.
             // Since mFDs[0] is used for inotify, we process regular events starting at index 1.
             mInputDeviceIndex += 1;
             if (mInputDeviceIndex >= mFDCount) {
                 break;
             }

             const struct pollfd& pfd = mFDs[mInputDeviceIndex];
             if (pfd.revents & POLLIN) {
                 int32_t readSize = read(pfd.fd, mInputBufferData,
                     sizeof(struct input_event) * INPUT_BUFFER_SIZE);
                 if (readSize < 0) {
                     if (errno != EAGAIN && errno != EINTR) {
                         LOGW("could not get event (errno=%d)", errno);
                     }
                 } else if ((readSize % sizeof(struct input_event)) != 0) {
                     LOGE("could not get event (wrong size: %d)", readSize);
                 } else {
                     mInputBufferCount = readSize / sizeof(struct input_event);
                     mInputBufferIndex = 0;
                 }
             }
         }

         ......

         mInputDeviceIndex = 0;

         // Poll for events.  Mind the wake lock dance!
         // We hold a wake lock at all times except during poll().  This works due to some
         // subtle choreography.  When a device driver has pending (unread) events, it acquires
         // a kernel wake lock.  However, once the last pending event has been read, the device
         // driver will release the kernel wake lock.  To prevent the system from going to sleep
         // when this happens, the EventHub holds onto its own user wake lock while the client
         // is processing events.  Thus the system can only sleep if there are no events
         // pending or currently being processed.
         release_wake_lock(WAKE_LOCK_ID);

         int pollResult = poll(mFDs, mFDCount, -1);

         acquire_wake_lock(PARTIAL_WAKE_LOCK, WAKE_LOCK_ID);

         if (pollResult <= 0) {
             if (errno != EINTR) {
                 LOGW("poll failed (errno=%d)\n", errno);
                 usleep(100000);
             }
         }

     }
 }

        这个函数比较长，我们一步一步来分析。

        首先，如果是第一次进入到这个函数中时，成员变量mOpened的值为false，于是就会调用openPlatformInput函数来打开系统输入设备，在本文中，我们主要讨论的输入设备就是键盘了。打开了这些输入设备文件后，就可以对这些输入设备进行是监控了。如果不是第一次进入到这个函数，那么就会分析当前有没有输入事件发生，如果有，就返回这个事件，否则就会进入等待状态，等待下一次输入事件的发生。在我们这个场景中，就是等待下一次键盘事件的发生了。

       我们先分析openPlatformInput函数的实现，然后回过头来分析这个getEvent函数的具体的实现。

       Step 19. EventHub.openPlatformInput

       这个函数定义在frameworks/base/libs/ui/EventHub.cpp文件中：

 bool EventHub::openPlatformInput(void)
 {
     ......

     res = scanDir(device_path);
     if(res < 0) {
         LOGE("scan dir failed for %s\n", device_path);
     }

     return true;
 }

        这个函数主要是扫描device_path目录下的设备文件，然后打开它们，这里的变量device_path定义在frameworks/base/libs/ui/EventHub.cpp文件开始的地方：

 static const char *device_path = "/dev/input";

        在设备目录/dev/input中，一般有三个设备文件存在，分别是event0、mice和mouse0设备文件，其中，键盘事件就包含在event0设备文件中了。

        Step 20. EventHub.scanDir

        这个函数定义在frameworks/base/libs/ui/EventHub.cpp文件中：

 int EventHub::scanDir(const char *dirname)
 {
     char devname[PATH_MAX];
     char *filename;
     DIR *dir;
     struct dirent *de;
     dir = opendir(dirname);
     if(dir == NULL)
         return -1;
     strcpy(devname, dirname);
     filename = devname + strlen(devname);
     *filename++ = '/';
     while((de = readdir(dir))) {
         if(de->d_name[0] == '.' &&
             (de->d_name[1] == '\0' ||
             (de->d_name[1] == '.' && de->d_name[2] == '\0')))
             continue;
         strcpy(filename, de->d_name);
         openDevice(devname);
     }
     closedir(dir);
     return 0;
 }

       根据上面一步的分析，这个函数主要就是调用openDevice函数来分别打开/dev/input/event0、/dev/input/mice和/dev/input/mouse0三个设备文件了。

       Step 21. EventHub.openDevice
       这个函数定义在frameworks/base/libs/ui/EventHub.cpp文件中：

 int EventHub::openDevice(const char *deviceName) {
     int version;
     int fd;
     struct pollfd *new_mFDs;
     device_t **new_devices;
     char **new_device_names;
     char name[80];
     char location[80];
     char idstr[80];
     struct input_id id;

     LOGV("Opening device: %s", deviceName);

     AutoMutex _l(mLock);

     fd = open(deviceName, O_RDWR);
     if(fd < 0) {
         LOGE("could not open %s, %s\n", deviceName, strerror(errno));
         return -1;
     }

     ......

     int devid = 0;
     while (devid < mNumDevicesById) {
         if (mDevicesById[devid].device == NULL) {
             break;
         }
         devid++;
     }

     ......

     mDevicesById[devid].seq = (mDevicesById[devid].seq+(1<<SEQ_SHIFT))&SEQ_MASK;
     if (mDevicesById[devid].seq == 0) {
         mDevicesById[devid].seq = 1<<SEQ_SHIFT;
     }

     new_mFDs = (pollfd*)realloc(mFDs, sizeof(mFDs[0]) * (mFDCount + 1));
     new_devices = (device_t**)realloc(mDevices, sizeof(mDevices[0]) * (mFDCount + 1));
     if (new_mFDs == NULL || new_devices == NULL) {
         LOGE("out of memory");
         return -1;
     }
     mFDs = new_mFDs;
     mDevices = new_devices;

     ......

     device_t* device = new device_t(devid|mDevicesById[devid].seq, deviceName, name);
     if (device == NULL) {
         LOGE("out of memory");
         return -1;
     }

     device->fd = fd;
     mFDs[mFDCount].fd = fd;
     mFDs[mFDCount].events = POLLIN;
     mFDs[mFDCount].revents = 0;

     // Figure out the kinds of events the device reports.

     uint8_t key_bitmask[sizeof_bit_array(KEY_MAX + 1)];
     memset(key_bitmask, 0, sizeof(key_bitmask));

     LOGV("Getting keys...");
     if (ioctl(fd, EVIOCGBIT(EV_KEY, sizeof(key_bitmask)), key_bitmask) >= 0) {
         // See if this is a keyboard.  Ignore everything in the button range except for
         // gamepads which are also considered keyboards.
         if (containsNonZeroByte(key_bitmask, 0, sizeof_bit_array(BTN_MISC))
             || containsNonZeroByte(key_bitmask, sizeof_bit_array(BTN_GAMEPAD),
             sizeof_bit_array(BTN_DIGI))
             || containsNonZeroByte(key_bitmask, sizeof_bit_array(KEY_OK),
             sizeof_bit_array(KEY_MAX + 1))) {
                 device->classes |= INPUT_DEVICE_CLASS_KEYBOARD;

                 device->keyBitmask = new uint8_t[sizeof(key_bitmask)];
                 if (device->keyBitmask != NULL) {
                     memcpy(device->keyBitmask, key_bitmask, sizeof(key_bitmask));
                 } else {
                     delete device;
                     LOGE("out of memory allocating key bitmask");
                     return -1;
                 }
         }
     }

     ......

     if ((device->classes & INPUT_DEVICE_CLASS_KEYBOARD) != 0) {
         char tmpfn[sizeof(name)];
         char keylayoutFilename[300];

         // a more descriptive name
         device->name = name;

         // replace all the spaces with underscores
         strcpy(tmpfn, name);
         for (char *p = strchr(tmpfn, ' '); p && *p; p = strchr(tmpfn, ' '))
             *p = '_';

         // find the .kl file we need for this device
         const char* root = getenv("ANDROID_ROOT");
         snprintf(keylayoutFilename, sizeof(keylayoutFilename),
             "%s/usr/keylayout/%s.kl", root, tmpfn);
         bool defaultKeymap = false;
         if (access(keylayoutFilename, R_OK)) {
             snprintf(keylayoutFilename, sizeof(keylayoutFilename),
                 "%s/usr/keylayout/%s", root, "qwerty.kl");
             defaultKeymap = true;
         }
         status_t status = device->layoutMap->load(keylayoutFilename);
         if (status) {
             LOGE("Error %d loading key layout.", status);
         }

         // tell the world about the devname (the descriptive name)
         if (!mHaveFirstKeyboard && !defaultKeymap && strstr(name, "-keypad")) {
             // the built-in keyboard has a well-known device ID of 0,
             // this device better not go away.
             mHaveFirstKeyboard = true;
             mFirstKeyboardId = device->id;
             property_set("hw.keyboards.0.devname", name);
         } else {
             // ensure mFirstKeyboardId is set to -something-.
             if (mFirstKeyboardId == 0) {
                 mFirstKeyboardId = device->id;
             }
         }
         char propName[100];
         sprintf(propName, "hw.keyboards.%u.devname", device->id);
         property_set(propName, name);

         // 'Q' key support = cheap test of whether this is an alpha-capable kbd
         if (hasKeycodeLocked(device, AKEYCODE_Q)) {
             device->classes |= INPUT_DEVICE_CLASS_ALPHAKEY;
         }

         // See if this device has a DPAD.
         if (hasKeycodeLocked(device, AKEYCODE_DPAD_UP) &&
             hasKeycodeLocked(device, AKEYCODE_DPAD_DOWN) &&
             hasKeycodeLocked(device, AKEYCODE_DPAD_LEFT) &&
             hasKeycodeLocked(device, AKEYCODE_DPAD_RIGHT) &&
             hasKeycodeLocked(device, AKEYCODE_DPAD_CENTER)) {
                 device->classes |= INPUT_DEVICE_CLASS_DPAD;
         }

         // See if this device has a gamepad.
         for (size_t i = 0; i < sizeof(GAMEPAD_KEYCODES)/sizeof(GAMEPAD_KEYCODES[0]); i++) {
             if (hasKeycodeLocked(device, GAMEPAD_KEYCODES[i])) {
                 device->classes |= INPUT_DEVICE_CLASS_GAMEPAD;
                 break;
             }
         }

         LOGI("New keyboard: device->id=0x%x devname='%s' propName='%s' keylayout='%s'\n",
             device->id, name, propName, keylayoutFilename);
     }

     ......

     mDevicesById[devid].device = device;
     device->next = mOpeningDevices;
     mOpeningDevices = device;
     mDevices[mFDCount] = device;

     mFDCount++;
     return 0;
 }

         函数首先根据文件名来打开这个设备文件：

 fd = open(deviceName, O_RDWR);

        系统中所有输入设备文件信息都保存在成员变量mDevicesById中，因此，先在mDevicesById找到一个空位置来保存当前打开的设备文件信息：

 mDevicesById[devid].seq = (mDevicesById[devid].seq+(1<<SEQ_SHIFT))&SEQ_MASK;
 if (mDevicesById[devid].seq == 0) {
     mDevicesById[devid].seq = 1<<SEQ_SHIFT;
 }

        找到了空闲位置后，就为这个输入设备文件创建相应的device_t信息：

 mDevicesById[devid].seq = (mDevicesById[devid].seq+(1<<SEQ_SHIFT))&SEQ_MASK;
 if (mDevicesById[devid].seq == 0) {
     mDevicesById[devid].seq = 1<<SEQ_SHIFT;
 }

 new_mFDs = (pollfd*)realloc(mFDs, sizeof(mFDs[0]) * (mFDCount + 1));
 new_devices = (device_t**)realloc(mDevices, sizeof(mDevices[0]) * (mFDCount + 1));
 if (new_mFDs == NULL || new_devices == NULL) {
     LOGE("out of memory");
     return -1;
 }
 mFDs = new_mFDs;
 mDevices = new_devices;

 ......

 device_t* device = new device_t(devid|mDevicesById[devid].seq, deviceName, name);
 if (device == NULL) {
     LOGE("out of memory");
     return -1;
 }

 device->fd = fd;

        同时，这个设备文件还会保存在数组mFDs中：

 mFDs[mFDCount].fd = fd;
 mFDs[mFDCount].events = POLLIN;
 mFDs[mFDCount].revents = 0;

       接下来查看这个设备是不是键盘：

 // Figure out the kinds of events the device reports.

 uint8_t key_bitmask[sizeof_bit_array(KEY_MAX + 1)];
 memset(key_bitmask, 0, sizeof(key_bitmask));

 LOGV("Getting keys...");
 if (ioctl(fd, EVIOCGBIT(EV_KEY, sizeof(key_bitmask)), key_bitmask) >= 0) {
     // See if this is a keyboard.  Ignore everything in the button range except for
     // gamepads which are also considered keyboards.
     if (containsNonZeroByte(key_bitmask, 0, sizeof_bit_array(BTN_MISC))
         || containsNonZeroByte(key_bitmask, sizeof_bit_array(BTN_GAMEPAD),
         sizeof_bit_array(BTN_DIGI))
         || containsNonZeroByte(key_bitmask, sizeof_bit_array(KEY_OK),
         sizeof_bit_array(KEY_MAX + 1))) {
             device->classes |= INPUT_DEVICE_CLASS_KEYBOARD;

             device->keyBitmask = new uint8_t[sizeof(key_bitmask)];
             if (device->keyBitmask != NULL) {
                 memcpy(device->keyBitmask, key_bitmask, sizeof(key_bitmask));
             } else {
                 delete device;
                 LOGE("out of memory allocating key bitmask");
                 return -1;
             }
     }
 }

        如果是的话，还要继续进一步初始化前面为这个设备文件所创建的device_t结构体，主要就是把结构体device的classes成员变量的INPUT_DEVICE_CLASS_KEYBOARD位置为1了，以表明这是一个键盘。
        如果是键盘设备，初始化工作还未完成，还要继续设置键盘的布局等信息：

 if ((device->classes & INPUT_DEVICE_CLASS_KEYBOARD) != 0) {
     char tmpfn[sizeof(name)];
     char keylayoutFilename[300];

     // a more descriptive name
     device->name = name;

     // replace all the spaces with underscores
     strcpy(tmpfn, name);
     for (char *p = strchr(tmpfn, ' '); p && *p; p = strchr(tmpfn, ' '))
         *p = '_';

     // find the .kl file we need for this device
     const char* root = getenv("ANDROID_ROOT");
     snprintf(keylayoutFilename, sizeof(keylayoutFilename),
         "%s/usr/keylayout/%s.kl", root, tmpfn);
     bool defaultKeymap = false;
     if (access(keylayoutFilename, R_OK)) {
         snprintf(keylayoutFilename, sizeof(keylayoutFilename),
             "%s/usr/keylayout/%s", root, "qwerty.kl");
         defaultKeymap = true;
     }
     status_t status = device->layoutMap->load(keylayoutFilename);
     if (status) {
         LOGE("Error %d loading key layout.", status);
     }

     // tell the world about the devname (the descriptive name)
     if (!mHaveFirstKeyboard && !defaultKeymap && strstr(name, "-keypad")) {
         // the built-in keyboard has a well-known device ID of 0,
         // this device better not go away.
         mHaveFirstKeyboard = true;
         mFirstKeyboardId = device->id;
         property_set("hw.keyboards.0.devname", name);
     } else {
         // ensure mFirstKeyboardId is set to -something-.
         if (mFirstKeyboardId == 0) {
             mFirstKeyboardId = device->id;
         }
     }
     char propName[100];
     sprintf(propName, "hw.keyboards.%u.devname", device->id);
     property_set(propName, name);

     // 'Q' key support = cheap test of whether this is an alpha-capable kbd
     if (hasKeycodeLocked(device, AKEYCODE_Q)) {
         device->classes |= INPUT_DEVICE_CLASS_ALPHAKEY;
     }

     // See if this device has a DPAD.
     if (hasKeycodeLocked(device, AKEYCODE_DPAD_UP) &&
         hasKeycodeLocked(device, AKEYCODE_DPAD_DOWN) &&
         hasKeycodeLocked(device, AKEYCODE_DPAD_LEFT) &&
         hasKeycodeLocked(device, AKEYCODE_DPAD_RIGHT) &&
         hasKeycodeLocked(device, AKEYCODE_DPAD_CENTER)) {
             device->classes |= INPUT_DEVICE_CLASS_DPAD;
     }

     // See if this device has a gamepad.
     for (size_t i = 0; i < sizeof(GAMEPAD_KEYCODES)/sizeof(GAMEPAD_KEYCODES[0]); i++) {
         if (hasKeycodeLocked(device, GAMEPAD_KEYCODES[i])) {
             device->classes |= INPUT_DEVICE_CLASS_GAMEPAD;
             break;
         }
     }

     LOGI("New keyboard: device->id=0x%x devname='%s' propName='%s' keylayout='%s'\n",
         device->id, name, propName, keylayoutFilename);
 }

        到这里，系统中的输入设备文件就打开了。

        回到Step 18中，我们继续分析EventHub.getEvent函数的实现。

        在中间的for循环里面，首先会检查当前是否有输入设备被关闭，如果有，就返回一个设备移除的事件给调用方：

 // Report any devices that had last been added/removed.
 if (mClosingDevices != NULL) {
     device_t* device = mClosingDevices;
     LOGV("Reporting device closed: id=0x%x, name=%s\n",
         device->id, device->path.string());
     mClosingDevices = device->next;
     if (device->id == mFirstKeyboardId) {
         outEvent->deviceId = 0;
     } else {
         outEvent->deviceId = device->id;
     }
     outEvent->type = DEVICE_REMOVED;
     outEvent->when = systemTime(SYSTEM_TIME_MONOTONIC);
     delete device;
     mNeedToSendFinishedDeviceScan = true;
     return true;
 }

        接着，检查当前是否有新的输入设备加入进来：

 if (mOpeningDevices != NULL) {
     device_t* device = mOpeningDevices;
     LOGV("Reporting device opened: id=0x%x, name=%s\n",
         device->id, device->path.string());
     mOpeningDevices = device->next;
     if (device->id == mFirstKeyboardId) {
         outEvent->deviceId = 0;
     } else {
         outEvent->deviceId = device->id;
     }
     outEvent->type = DEVICE_ADDED;
     outEvent->when = systemTime(SYSTEM_TIME_MONOTONIC);
     mNeedToSendFinishedDeviceScan = true;
     return true;
 }

        接着，再检查是否需要结束监控输入事件：

 if (mNeedToSendFinishedDeviceScan) {
     mNeedToSendFinishedDeviceScan = false;
     outEvent->type = FINISHED_DEVICE_SCAN;
     outEvent->when = systemTime(SYSTEM_TIME_MONOTONIC);
     return true;
 }

        最后，就是要检查当前是否有还未处理的输入设备事件发生了：

 // Grab the next input event.
 for (;;) {
     // Consume buffered input events, if any.
     if (mInputBufferIndex < mInputBufferCount) {
         const struct input_event& iev = mInputBufferData[mInputBufferIndex++];
         const device_t* device = mDevices[mInputDeviceIndex];

         LOGV("%s got: t0=%d, t1=%d, type=%d, code=%d, v=%d", device->path.string(),
             (int) iev.time.tv_sec, (int) iev.time.tv_usec, iev.type, iev.code, iev.value);
         if (device->id == mFirstKeyboardId) {
             outEvent->deviceId = 0;
         } else {
             outEvent->deviceId = device->id;
         }
         outEvent->type = iev.type;
         outEvent->scanCode = iev.code;
         if (iev.type == EV_KEY) {
             status_t err = device->layoutMap->map(iev.code,
                 & outEvent->keyCode, & outEvent->flags);
             LOGV("iev.code=%d keyCode=%d flags=0x%08x err=%d\n",
                 iev.code, outEvent->keyCode, outEvent->flags, err);
             if (err != 0) {
                 outEvent->keyCode = AKEYCODE_UNKNOWN;
                 outEvent->flags = 0;
             }
         } else {
             outEvent->keyCode = iev.code;
         }
         outEvent->value = iev.value;

         // Use an event timestamp in the same timebase as
         // java.lang.System.nanoTime() and android.os.SystemClock.uptimeMillis()
         // as expected by the rest of the system.
         outEvent->when = systemTime(SYSTEM_TIME_MONOTONIC);
         return true;
     }

     // Finish reading all events from devices identified in previous poll().
     // This code assumes that mInputDeviceIndex is initially 0 and that the
     // revents member of pollfd is initialized to 0 when the device is first added.
     // Since mFDs[0] is used for inotify, we process regular events starting at index 1.
     mInputDeviceIndex += 1;
     if (mInputDeviceIndex >= mFDCount) {
         break;
     }

     const struct pollfd& pfd = mFDs[mInputDeviceIndex];
     if (pfd.revents & POLLIN) {
         int32_t readSize = read(pfd.fd, mInputBufferData,
             sizeof(struct input_event) * INPUT_BUFFER_SIZE);
         if (readSize < 0) {
             if (errno != EAGAIN && errno != EINTR) {
                 LOGW("could not get event (errno=%d)", errno);
             }
         } else if ((readSize % sizeof(struct input_event)) != 0) {
             LOGE("could not get event (wrong size: %d)", readSize);
         } else {
             mInputBufferCount = readSize / sizeof(struct input_event);
             mInputBufferIndex = 0;
         }
     }
 }

        未处理的输入事件保存在成员变量mInputBufferData中，如果有的话，就可以直接返回了，否则的话，就要通过系统调用poll来等待输入设备上发生新的事件了，在我们这个场景中，就是等待键盘有键被按下或者松开了。：

 int pollResult = poll(mFDs, mFDCount, -1);

        这里的mFDs包含了我们所要监控的输入设备的打开文件描述符，这是在前面的openPlatformInput函数中初始化的。

        Step 22. poll

        这是一个Linux系统的文件操作系统调用，它用来查询指定的文件列表是否有有可读写的，如果有，就马上返回，否则的话，就阻塞线程，并等待驱动程序唤醒，重新调用poll函数，或超时返回。在我们的这个场景中，就是要查询是否有键盘事件发生，如果有的话，就返回，否则的话，当前线程就睡眠等待键盘事件的发生了。

        这样，InputManager的启动过程就分析完了，下面我们再分析应用程序注册键盘消息接收通道的过程。

        2. 应用程序注册键盘消息接收通道的过程分析

        InputManager启动以后，就开始负责监控键盘输入事件了。当InputManager监控到键盘输入事件时，它应该把这个键盘事件分发给谁呢？当然是要把这个键盘消息分发给当前激活的Activity窗口了，不过，当前激活的Activity窗口还需要主动注册一个键盘消息接收通道到InputManager中去，InputManager才能把这个键盘消息分发给它处理。那么，当前被激活的Activity窗口又是什么时候去注册这个键盘消息接收通道的呢？在前面一篇文章Android应用程序启动过程源代码分析中，我们分析Android应用程序的启动过程时，在Step 33中分析到ActivityThread类的handleLaunchActivity函数中，我们曾经说过，当函数handleLaunchActivity调用performLaunchActivity函数来加载这个完毕应用程序的默认Activity后，再次回到handleLaunchActivity函数时，会调用handleResumeActivity函数来使这个Activity进入Resumed状态。在调用handleResumeActivity函数的过程中，ActivityThread会通过android.view.WindowManagerImpl类为该Activity创建一个ViewRoot实例，并且会通过调用ViewRoot类的setView成员函数把与该Activity关联的View设置到这个ViewRoot中去，而Activity正是通过ViewRoot类的setView成员函数来注册键盘消息接收通道的。

        有了这些背影知识后，接下来，我们就可以从ViewRoot.setView函数开始分析应用程序注册键盘消息接收通道的过程了。首先看一下这个注册过程的序列图，然后再详细分析每一个步骤：

Step 1. ViewRoot.setView

        这个函数定义在frameworks/base/core/java/android/view/ViewRoot.java文件中：

 public final class ViewRoot extends Handler implements ViewParent,
         View.AttachInfo.Callbacks {
     ......

     public void setView(View view, WindowManager.LayoutParams attrs,
             View panelParentView) {
         ......

         synchronized (this) {
             if (mView == null) {
                 ......

                 // Schedule the first layout -before- adding to the window
                 // manager, to make sure we do the relayout before receiving
                 // any other events from the system.
                 requestLayout();
                 mInputChannel = new InputChannel();
                 try {
                     res = sWindowSession.add(mWindow, mWindowAttributes,
                         getHostVisibility(), mAttachInfo.mContentInsets,
                         mInputChannel);
                 } catch (RemoteException e) {
                     ......
                 } finally {
                     ......
                 }

                 ......

                 if (view instanceof RootViewSurfaceTaker) {
                     mInputQueueCallback =
                         ((RootViewSurfaceTaker)view).willYouTakeTheInputQueue();
                 }
                 if (mInputQueueCallback != null) {
                     mInputQueue = new InputQueue(mInputChannel);
                     mInputQueueCallback.onInputQueueCreated(mInputQueue);
                 } else {
                     InputQueue.registerInputChannel(mInputChannel, mInputHandler,
                         Looper.myQueue());
                 }

                 ......
             }
         }
     }

 }

        这个函数中与注册键盘消息接收通道（InputChannel）相关的逻辑主要有三处，一是调用requestLayout函数来通知InputManager，这个Activity窗口是当前被激活的窗口，二是调用sWindowSession（WindowManagerService内部类Session的远程接口）的add成员函数来把键盘消息接收通道的一端注册在InputManager中，三是调用InputQueue的registerInputChannel成员函数来把键盘消息接收通道的另一端注册在本应用程序的消息循环（Looper）中。这样，当InputManager监控到有键盘消息时，就会先找到当前被激活的窗口，然后找到其在InputManager中对应的键盘消息接收通道，通过这个通道在InputManager中的一端来通知在应用程序消息循环中的另一端，就把键盘消息分发给当前激活的Activity窗口了。

        在接下来的内容中，我们首先描述requestLayout函数是如何告诉InputManager当前的Activity窗口便是激活窗口的，接着再回过头来分析应用程序是如何把键盘消息接收通道的一端注册到InputManager中去的，最后分析应用程序是如何键盘消息接收通道的另一端注册到本应用程序的消息循环中去了。

        Step 2. ViewRoot.requestLayout

        这个函数定义在frameworks/base/core/java/android/view/ViewRoot.java文件中：

 public final class ViewRoot extends Handler implements ViewParent,
         View.AttachInfo.Callbacks {
     ......

     public void requestLayout() {
         ......
         mLayoutRequested = true;
         scheduleTraversals();
     }

     ......
 }

        这个函数调用了scheduleTraversals函数来进一步执行操作，由于篇幅关系，我们就不详细描述scheduleTraversals函数了，简单来说，在scheduleTraversals函数中，会通过sendEmptyMessage(DO_TRAVERSAL)发送一个消息到应用程序的消息队列中，这个消息最终由ViewRoot的handleMessage函数处理，而ViewRoot的handleMessage函数把这个消息交给ViewRoot类的performTraversals来处理，在performTraversals函数中，又会调用ViewRoot类的relayoutWindow函数来进一步执行操作，最后在relayoutWindow函数中，就会通过WindowManagerService内部类Session的远程接口sWindowSession的relayout函数来进入到WindowManagerService中。

        Step 3. WindowManagerService.Session.relayout

        这个函数定义在frameworks/base/services/java/com/android/server/WindowManagerService.java 文件中：

 public class WindowManagerService extends IWindowManager.Stub
         implements Watchdog.Monitor {
     ......

     private final class Session extends IWindowSession.Stub
             implements IBinder.DeathRecipient {
         ......

         public int relayout(IWindow window, WindowManager.LayoutParams attrs,
                 int requestedWidth, int requestedHeight, int viewFlags,
                 boolean insetsPending, Rect outFrame, Rect outContentInsets,
                 Rect outVisibleInsets, Configuration outConfig, Surface outSurface) {
             //Log.d(TAG, ">>>>>> ENTERED relayout from " + Binder.getCallingPid());
             int res = relayoutWindow(this, window, attrs,
                     requestedWidth, requestedHeight, viewFlags, insetsPending,
                     outFrame, outContentInsets, outVisibleInsets, outConfig, outSurface);
             //Log.d(TAG, "<<<<<< EXITING relayout to " + Binder.getCallingPid());
             return res;
         }

         ......
     }

     ......
 }

        这个函数只是简单地调用WindowManagerService的成员函数relayoutWIndow来进一步处理。

        Step 4. WindowManagerService.relayoutWIndow

        这个函数定义在frameworks/base/services/java/com/android/server/WindowManagerService.java 文件中：

 public class WindowManagerService extends IWindowManager.Stub
         implements Watchdog.Monitor {
     ......

     public int relayoutWindow(Session session, IWindow client,
             WindowManager.LayoutParams attrs, int requestedWidth,
             int requestedHeight, int viewVisibility, boolean insetsPending,
             Rect outFrame, Rect outContentInsets, Rect outVisibleInsets,
             Configuration outConfig, Surface outSurface) {
         ......

         synchronized(mWindowMap) {
             ......

             mInputMonitor.updateInputWindowsLw();
         }

         ......
     }

     ......
 }

         这个函数又会继续调用mInputMonitor的updateInputWindowsLw成员函数来更新当前的输入窗口，mInputMonitor是WindowManagerService的成员变量，它的类型为InputMonitor。

         Step 5. InputMonitor.updateInputWindowsLw

         这个函数定义在frameworks/base/services/java/com/android/server/WindowManagerService.java 文件中：

 public class WindowManagerService extends IWindowManager.Stub
         implements Watchdog.Monitor {
     ......

     final class InputMonitor {
         ......

         /* Updates the cached window information provided to the input dispatcher. */
         public void updateInputWindowsLw() {
             // Populate the input window list with information about all of the windows that
             // could potentially receive input.
             // As an optimization, we could try to prune the list of windows but this turns
             // out to be difficult because only the native code knows for sure which window
             // currently has touch focus.
             final ArrayList<WindowState> windows = mWindows;
             final int N = windows.size();
             for (int i = N - 1; i >= 0; i--) {
                 final WindowState child = windows.get(i);
                 if (child.mInputChannel == null || child.mRemoved) {
                     // Skip this window because it cannot possibly receive input.
                     continue;
                 }

                 ......

                 // Add a window to our list of input windows.
                 final InputWindow inputWindow = mTempInputWindows.add();

                 ......
             }

             // Send windows to native code.
             mInputManager.setInputWindows(mTempInputWindows.toNullTerminatedArray());

             ......
         }

         ......
     }

     ......
 }

        这个函数将当前系统中带有InputChannel的Activity窗口都设置为InputManager的输入窗口，但是后面我们会看到，只有当前激活的窗口才会响应键盘消息。

        Step 6. InputManager.setInputWindows

        这个函数定义在frameworks/base/services/java/com/android/server/InputManager.java文件中：

 public class InputManager {
     ......

     public void setInputWindows(InputWindow[] windows) {
         nativeSetInputWindows(windows);
     }

     ......
 }

        这个函数调用了本地方法nativeSetInputWindows来进一步执行操作。
        Step 7. InputManager.nativeSetInputWindows

        这个函数定义在frameworks/base/services/jni/com_android_server_InputManager.cpp 文件中：

 static void android_server_InputManager_nativeSetInputWindows(JNIEnv* env, jclass clazz,
         jobjectArray windowObjArray) {
     if (checkInputManagerUnitialized(env)) {
         return;
     }

     gNativeInputManager->setInputWindows(env, windowObjArray);
 }

        这里的gNativeInputManager我们前面分析InputManager的启动过程时已经见过了，这是一个本地InputManager对象，通过它进一步设置当前系统的输入窗口。

        Step 8. NativeInputManager.setInputWindows

        这个函数定义在frameworks/base/services/jni/com_android_server_InputManager.cpp 文件中：

 void NativeInputManager::setInputWindows(JNIEnv* env, jobjectArray windowObjArray) {
     Vector<InputWindow> windows;

     jsize length = env->GetArrayLength(windowObjArray);
     for (jsize i = 0; i < length; i++) {
         jobject inputTargetObj = env->GetObjectArrayElement(windowObjArray, i);
         if (! inputTargetObj) {
             break; // found null element indicating end of used portion of the array
         }

         windows.push();
         InputWindow& window = windows.editTop();
         bool valid = populateWindow(env, inputTargetObj, window);
         if (! valid) {
             windows.pop();
         }

         env->DeleteLocalRef(inputTargetObj);
     }

     mInputManager->getDispatcher()->setInputWindows(windows);
 }

        这个函数首先将Java层的Window转换成C++层的InputWindow，然后放在windows向量中，最后将这些输入窗口设置到InputDispatcher中去。

        Step 9. InputDispatcher.setInputWindows

        这个函数定义在frameworks/base/libs/ui/InputDispatcher.cpp文件中：

 void InputDispatcher::setInputWindows(const Vector<InputWindow>& inputWindows) {
     ......

     { // acquire lock
         AutoMutex _l(mLock);

         // Clear old window pointers.
         sp<InputChannel> oldFocusedWindowChannel;
         if (mFocusedWindow) {
             oldFocusedWindowChannel = mFocusedWindow->inputChannel;
             mFocusedWindow = NULL;
         }

         mWindows.clear();

         // Loop over new windows and rebuild the necessary window pointers for
         // tracking focus and touch.
         mWindows.appendVector(inputWindows);

         size_t numWindows = mWindows.size();
         for (size_t i = 0; i < numWindows; i++) {
             const InputWindow* window = & mWindows.itemAt(i);
             if (window->hasFocus) {
                 mFocusedWindow = window;
                 break;
             }
         }

         ......

     } // release lock

     ......
 }

        这里InputDispatcher的成员变量mFocusedWindow就代表当前激活的窗口的。这个函数首先清空mFocusedWindow，然后再通过一个for循环检查当前的输入窗口中的哪一个窗口是获得焦点的，获得焦点的输入窗口即为当前激活的窗口。

        这样，InputManager就把当前激活的Activity窗口保存在InputDispatcher中了，后面就可以把键盘消息分发给它来处理。

        回到Step 1中的ViewRoot.setView函数中，接下来就调用下面语句来注册键盘消息接收通道的一端到InputManager中去：

 mInputChannel = new InputChannel();
 try {
     res = sWindowSession.add(mWindow, mWindowAttributes,
             getHostVisibility(), mAttachInfo.mContentInsets,
             mInputChannel);
 } catch (RemoteException e) {
     ......
 } finally {
     ......
 }

        前面说过，这里的sWindowSession是WindowManagerService内部类Session的一个远程接口，通过它可以进入到WindowManagerService中去。

        Step 10. WindowManagerService.Session.add

        这个函数定义在frameworks/base/services/java/com/android/server/WindowManagerService.java 文件中：

 public class WindowManagerService extends IWindowManager.Stub
         implements Watchdog.Monitor {
     ......

     private final class Session extends IWindowSession.Stub
             implements IBinder.DeathRecipient {
         ......

         public int add(IWindow window, WindowManager.LayoutParams attrs,
                 int viewVisibility, Rect outContentInsets, InputChannel outInputChannel) {
             return addWindow(this, window, attrs, viewVisibility, outContentInsets,
                 outInputChannel);
         }

         ......
     }

     ......
 }

        这里调用WindowManagerService类的addWindow函数来进一步执行操作。

        Step 11. WindowManagerService.addWindow

        这个函数定义在frameworks/base/services/java/com/android/server/WindowManagerService.java 文件中：

 public class WindowManagerService extends IWindowManager.Stub
         implements Watchdog.Monitor {
     ......

     public int addWindow(Session session, IWindow client,
             WindowManager.LayoutParams attrs, int viewVisibility,
             Rect outContentInsets, InputChannel outInputChannel) {
         ......

         WindowState win = null;

         synchronized(mWindowMap) {
             ......

             win = new WindowState(session, client, token,
                 attachedWindow, attrs, viewVisibility);

             ......

             if (outInputChannel != null) {
                 String name = win.makeInputChannelName();
                 InputChannel[] inputChannels = InputChannel.openInputChannelPair(name);
                 win.mInputChannel = inputChannels[0];
                 inputChannels[1].transferToBinderOutParameter(outInputChannel);
                 mInputManager.registerInputChannel(win.mInputChannel);
             }

             ......
         }

         ......
     }

     ......
 }

        这里的outInputChannel即为前面在Step 1中创建的InputChannel，它不为NULL，因此，这里会通过InputChannel.openInputChannelPair函数来创建一对输入通道，其中一个位于WindowManagerService中，另外一个通过outInputChannel参数返回到应用程序中：

 inputChannels[1].transferToBinderOutParameter(outInputChannel);

        创建输入通道之前，WindowManagerService会为当前Activity窗口创建一个WindowState对象win，用来记录这个Activity窗口的状态信息。当创建这对输入管道成功以后，也会把其中的一个管道保存在这个WindowState对象win的成员变量mInputChannel中，后面要注销这个管道的时候，就是从这个WindownState对象中取回这个管道的：

 win.mInputChannel = inputChannels[0];

        接下来我们就看一下InputChannel.openInputChannelPair函数的实现。

        Step 12. InputChannel.openInputChannelPair

        这个函数定义在frameworks/base/core/java/android/view/InputChannel.java文件中：

 public final class InputChannel implements Parcelable {
     ......

     /**
     * Creates a new input channel pair.  One channel should be provided to the input
     * dispatcher and the other to the application's input queue.
     * @param name The descriptive (non-unique) name of the channel pair.
     * @return A pair of input channels.  They are symmetric and indistinguishable.
     */
     public static InputChannel[] openInputChannelPair(String name) {
         ......

         return nativeOpenInputChannelPair(name);
     }

     ......
 }

         这个函数调用本地方法nativeOpenInputChannelPair来进一步执行操作。

         Step 13. InputChannel.nativeOpenInputChannelPair
         这个函数定义在frameworks/base/core/jni/android_view_InputChannel.cpp文件中：

 static jobjectArray android_view_InputChannel_nativeOpenInputChannelPair(JNIEnv* env,
         jclass clazz, jstring nameObj) {
      const char* nameChars = env->GetStringUTFChars(nameObj, NULL);
      String8 name(nameChars);
      env->ReleaseStringUTFChars(nameObj, nameChars);

      sp<InputChannel> serverChannel;
      sp<InputChannel> clientChannel;
      status_t result = InputChannel::openInputChannelPair(name, serverChannel, clientChannel);

      if (result) {
          LOGE("Could not open input channel pair.  status=%d", result);
          jniThrowRuntimeException(env, "Could not open input channel pair.");
          return NULL;
      }

      // TODO more robust error checking
      jobject serverChannelObj = android_view_InputChannel_createInputChannel(env,
          new NativeInputChannel(serverChannel));
      jobject clientChannelObj = android_view_InputChannel_createInputChannel(env,
          new NativeInputChannel(clientChannel));

      jobjectArray channelPair = env->NewObjectArray(2, gInputChannelClassInfo.clazz, NULL);
      env->SetObjectArrayElement(channelPair, 0, serverChannelObj);
      env->SetObjectArrayElement(channelPair, 1, clientChannelObj);
      return channelPair;
 }

        这个函数根据传进来的参数name在C++层分别创建两个InputChannel，一个作为Server端使用，一个作为Client端使用，这里的Server端即是指InputManager，而Client端即是指应用程序。这两个本地的InputChannel是通过InputChannel::openInputChannelPair函数创建的，创建完成后，再相应地在Java层创建相应的两个InputChannel，然后返回。

        Step 14. InputChannel.openInputChannelPair
        这个函数定义在frameworks/base/libs/ui/InputTransport.cpp文件中：

 status_t InputChannel::openInputChannelPair(const String8& name,
         sp<InputChannel>& outServerChannel, sp<InputChannel>& outClientChannel) {
     status_t result;

     int serverAshmemFd = ashmem_create_region(name.string(), DEFAULT_MESSAGE_BUFFER_SIZE);
     if (serverAshmemFd < 0) {
         ......
     } else {
         result = ashmem_set_prot_region(serverAshmemFd, PROT_READ | PROT_WRITE);
         if (result < 0) {
             ......
         } else {
             // Dup the file descriptor because the server and client input channel objects that
             // are returned may have different lifetimes but they share the same shared memory region.
             int clientAshmemFd;
             clientAshmemFd = dup(serverAshmemFd);
             if (clientAshmemFd < 0) {
                 ......
             } else {
                 int forward[2];
                 if (pipe(forward)) {
                     ......
                 } else {
                     int reverse[2];
                     if (pipe(reverse)) {
                         ......
                     } else {
                         String8 serverChannelName = name;
                         serverChannelName.append(" (server)");
                         outServerChannel = new InputChannel(serverChannelName,
                             serverAshmemFd, reverse[0], forward[1]);

                         String8 clientChannelName = name;
                         clientChannelName.append(" (client)");
                         outClientChannel = new InputChannel(clientChannelName,
                             clientAshmemFd, forward[0], reverse[1]);
                         return OK;
                     }
                     ......
                 }
                 ......
             }
         }
     }
     ......
 }

        在阅读这个函数之前，我们首先了解一下C++层的InputChannel的构造函数：

 InputChannel::InputChannel(const String8& name, int32_t ashmemFd, int32_t receivePipeFd,
     int32_t sendPipeFd) :
     mName(name), mAshmemFd(ashmemFd), mReceivePipeFd(receivePipeFd), mSendPipeFd(sendPipeFd) {
     ......
 }

        为了创建一个InputChannel，我们需要准备四个参数，一个是输入通道的名称name，一个是 匿名共享内存 文件描述符，一个是管道的读端文件描述符，一个是管道的写端文件描述符。在上面的openInputChannelPair函数，输入通道的名称已经作为参数传递进来，因此，还需要创建匿名共享内存文件，还有管道。这里需要创建两个管道，一个称为前向管道（forward pipe），一个称为反向管道（reverse pipe），它们交叉使用在Server端和Client端的InputChannel中，这样就使入Server和Client可以互相通信了。

        具体来说，Server端和Client端的InputChannel分别是这样构成的：

        Server Input Channel:  ashmem - reverse(read) - forward(write)

        Client Input Channel:   ashmem - forward(read) - reverse(write)
        前面我们在Android应用程序消息处理机制（Looper、Handler）分析一文中学习Android应用程序的消息处理机制时知道，管道可以用作进程间通信，其中一个进程在管道的读端等待新的内空可读，另一个进程在管道的写端写入新的内容以唤醒在管道读端等待的进程，这样就实现了进程间通信。在我们这个情景中，Client端可以在前向管道（forward pipe）的读端睡眠等待新的内容可读，而Server端可以通过向前向管道（forward pipe）的写端写入新的内容来唤醒Client端，同样，把前向管道（forward pipe）换成反向管道（reverse pipe），也能实现Client端唤醒Server端。在后面我们分析InputDispatcher分发键盘消息时，会看到它们的用法。

        有了这些背景知识后，相信上面的openInputChannelPair的代码就容易理解了，这里就不再详述了。

        创建好了这两个输入通道后，回到Step 11中的WindowManagerService.addWindow函数中，一方面它把刚才创建的Client端的输入通道通过outInputChannel参数返回到应用程序中：

 inputChannels[1].transferToBinderOutParameter(outInputChannel);

       另一方面，它还要把刚才创建的Server端的输入通道注册到InputManager中：

 mInputManager.registerInputChannel(win.mInputChannel);

       Step 15. InputManager.registerInputChannel

       这个函数定义在frameworks/base/services/java/com/android/server/InputManager.java文件中：

 public class InputManager {
     ......

     /**
     * Registers an input channel so that it can be used as an input event target.
     * @param inputChannel The input channel to register.
     */
     public void registerInputChannel(InputChannel inputChannel) {
         if (inputChannel == null) {
             throw new IllegalArgumentException("inputChannel must not be null.");
         }

         nativeRegisterInputChannel(inputChannel, false);
     }

     ......
 }

         它通过调用本地方法nativeRegisterInputChannel来执行进一步的操作。

         Step 16. InputManager.nativeRegisterInputChannel

         这个函数定义在frameworks/base/services/jni/com_android_server_InputManager.cpp 文件中：

 static void android_server_InputManager_nativeRegisterInputChannel(JNIEnv* env, jclass clazz,
         jobject inputChannelObj, jboolean monitor) {
     ......

     sp<InputChannel> inputChannel = android_view_InputChannel_getInputChannel(env,
        inputChannelObj);
     ......

     status_t status = gNativeInputManager->registerInputChannel(
        env, inputChannel, inputChannelObj, monitor);

     ......
 }

        这里首先通过Java层的InputChannel对象获得C++层的InputChannel对象，它们之间的对应关系是在前面的Step 13中设置好的，接着调用NativeInputManager的registerInputChannel执行进一步的操作。

        Step 17. NativeInputManager.registerInputChannel

        这个函数定义在frameworks/base/services/jni/com_android_server_InputManager.cpp 文件中：

 status_t NativeInputManager::registerInputChannel(JNIEnv* env,
         const sp<InputChannel>& inputChannel, jobject inputChannelObj, bool monitor) {
     ......

     status = mInputManager->getDispatcher()->registerInputChannel(inputChannel, monitor);

     ......
 }

        这个函数主要是调用了InputDispatcher的registerInputChannel来真正执行注册输入通道的操作。

        Step 18. InputDispatcher.registerInputChannel
        这个函数定义在frameworks/base/libs/ui/InputDispatcher.cpp文件中：

 status_t InputDispatcher::registerInputChannel(const sp<InputChannel>& inputChannel, bool monitor) {
     ......

     { // acquire lock
         AutoMutex _l(mLock);

         if (getConnectionIndexLocked(inputChannel) >= 0) {
             LOGW("Attempted to register already registered input channel '%s'",
                 inputChannel->getName().string());
             return BAD_VALUE;
         }

         sp<Connection> connection = new Connection(inputChannel);
         status_t status = connection->initialize();
         if (status) {
             LOGE("Failed to initialize input publisher for input channel '%s', status=%d",
                 inputChannel->getName().string(), status);
             return status;
         }

         int32_t receiveFd = inputChannel->getReceivePipeFd();
         mConnectionsByReceiveFd.add(receiveFd, connection);

         if (monitor) {
             mMonitoringChannels.push(inputChannel);
         }

         mLooper->addFd(receiveFd, 0, ALOOPER_EVENT_INPUT, handleReceiveCallback, this);

         runCommandsLockedInterruptible();
     } // release lock
     return OK;
 }

        这个函数首先会通过getConnectionIndexLocked检查从参数传进来的InputChannel是否已经注册过了，如果已经注册过了，就返回一个BAD_VALUE值了，否则的话，就会创建一个Connection对象来封装即将要注册的inputChannel，我们可以不关心这个Connection对象的实现，接着还通过调用inputChannel->getReceivePipeFd获得一个管
道的读端描述符。回忆一下Step 14中的InputChannel.openInputChannelPair函数，我们创建了一个Server端的InputChannel，就是对应这里的inputChannel了，这个inputChannel的Receive Pipe Fd就是我们前面说的反向管道的读端描述符了。有了这个Receive Pipe Fd后，就以它作为Key值来把前面创建的Connection对象保存在InputDispatcher中，这样就基本完成键盘消息接收通道的注册了。但是，注册的工作还未完成，最后，还要把这个Receive Pipe Fd添加到InputDispatcher的成员变量mLooper中去，这里的成员变量mLooper的类型为Looper，我们在前面介绍InputManager的启动过程的Step 15中已经见过了，这里就不再详述了，不过这里仍然值得介绍一下它的addFd函数。

        在前面一篇文章Android应用程序消息处理机制（Looper、Handler）分析中，我们在介绍到Android应用程序的消息循环一节时，曾经说过，在Looper类内部，会创建一个管道，然后Looper会睡眠在这个管道的读端，等待另外一个线程来往这个管道的写端写入新的内容，从而唤醒等待在这个管道读端的线程，除此之外，Looper还可以同时睡眠等待在其它的文件描述符上，因为它是通过Linux系统的epoll机制来批量等待指定的文件有新的内容可读的。这些其它的文件描述符就是通过Looper类的addFd成函数添加进去的了，在添加的时候，还可以指定回调函数，即当这个文件描述符所指向的文件有新的内容可读时，Looper就会调用这个hanldeReceiveCallback函数，有兴趣的读者可以自己研究一下Looper类的addFd函数的实现，它位于frameworks/base/libs/utils/Looper.cpp文件中。

        分析到这里，Server端的InputChannel就注册完成了。回忆一下前面介绍InputManager启动过程的Step 14，这时InputDispatcherThread同时睡眠在InputDispatcher的成员变量mLooper内部的管道的读端以及这里的Server端InputChannel里面的反向管道的读端上，mLooper内部的管道的读端等待键盘事件的发生而被唤醒，而Server端InputChannel里面的反向管道的读端等待Client端InputChannel里面的反向管道的写端被写入新的内容而被唤醒。

        Server端的InputChannel注册完成后，回到Step 11中的WindowManagerService.addWindow函数，接下来就是把Client端的InputChannel转换成addWindow的参数outInputChannel中，然后返回到Step 1中的ViewRoot.setView函数中，继续执行Client端的InputChannel的注册过程，即为应用程序这一侧注册键盘消息接收通道：

 if (view instanceof RootViewSurfaceTaker) {
     mInputQueueCallback =
         ((RootViewSurfaceTaker)view).willYouTakeTheInputQueue();
 }
 if (mInputQueueCallback != null) {
     mInputQueue = new InputQueue(mInputChannel);
     mInputQueueCallback.onInputQueueCreated(mInputQueue);
 } else {
     InputQueue.registerInputChannel(mInputChannel, mInputHandler,
         Looper.myQueue());
 }

        这里的变量view一般不为RootViewSurfaceTaker的实例，因此，最后会执行下面语句：

 InputQueue.registerInputChannel(mInputChannel, mInputHandler,
     Looper.myQueue());

        它调用InputQueue的registerInputChannel函数为应用程序注册键盘消息接收通道，这里的mInputChannel即为我们在前面Step 14中创建的Client端的InputChannel；Looper.myQueue函数返回的便是应用程序主线程的消息队列，具体可以参考前面一篇文章 Android应用程序消息处理机制（Looper、Handler）分析 ；参数mInputHandler是一个回调对象，当有键盘事件发生时，这个mInputHandler的handleKey函数就会被调用，在后面的分析中，我们将会看到。

        Step 19. InputQueue.registerInputChannel

        这个函数定义在frameworks/base/core/java/android/view/InputQueue.java文件中：

 public final class InputQueue {
     ......

     public static void registerInputChannel(InputChannel inputChannel, InputHandler inputHandler,
             MessageQueue messageQueue) {
         ......

         synchronized (sLock) {
             ......

             nativeRegisterInputChannel(inputChannel, inputHandler, messageQueue);
         }
     }

     ......
 }

         这个函数调用本地方法nativeRegisterInputChannel函数来执行进一步的操作。

         Step 20. InputQueue.nativeRegisterInputChannel

         这个函数定义在frameworks/base/core/jni/android_view_InputQueue.cpp文件中：

 static void android_view_InputQueue_nativeRegisterInputChannel(JNIEnv* env, jclass clazz,
         jobject inputChannelObj, jobject inputHandlerObj, jobject messageQueueObj) {
     status_t status = gNativeInputQueue.registerInputChannel(
        env, inputChannelObj, inputHandlerObj, messageQueueObj);

     ......
 }

        这里继续调用NativeInputQueue的registerInputChannel函数来执行真正的键盘消息接收通道的工作。

        Step 21. NativeInputQueue.registerInputChannel

        这个函数定义在frameworks/base/core/jni/android_view_InputQueue.cpp文件中：

 status_t NativeInputQueue::registerInputChannel(JNIEnv* env, jobject inputChannelObj,
         jobject inputHandlerObj, jobject messageQueueObj) {
     sp<InputChannel> inputChannel = android_view_InputChannel_getInputChannel(env,
         inputChannelObj);
     ......

     sp<Looper> looper = android_os_MessageQueue_getLooper(env, messageQueueObj);

     { // acquire lock
         AutoMutex _l(mLock);

         if (getConnectionIndex(inputChannel) >= 0) {
             LOGW("Attempted to register already registered input channel '%s'",
                 inputChannel->getName().string());
             return BAD_VALUE;
         }

         uint16_t connectionId = mNextConnectionId++;
         sp<Connection> connection = new Connection(connectionId, inputChannel, looper);
         status_t result = connection->inputConsumer.initialize();
         if (result) {
             LOGW("Failed to initialize input consumer for input channel '%s', status=%d",
                 inputChannel->getName().string(), result);
             return result;
         }

         connection->inputHandlerObjGlobal = env->NewGlobalRef(inputHandlerObj);

         int32_t receiveFd = inputChannel->getReceivePipeFd();
         mConnectionsByReceiveFd.add(receiveFd, connection);

         looper->addFd(receiveFd, 0, ALOOPER_EVENT_INPUT, handleReceiveCallback, this);
     } // release lock

     ......
     return OK;
 }

        这里注册应用程序的InputChannel的逻辑和前面介绍的Step 18中在InputDispatcher中注册Server端的InputChannel是一样的，所不同的是，这里用的looper是应用程序主线程中的消息循环对象Looper，而添加到这个looper对象中的Receive Pipe Fd是前面在Step 14中创建的前向管道的读端文件描述符，而使用的回调函数是NativeInputQueue的成员函数handleReceiveCallback。

        介绍到这里，应用程序注册键盘消息接收通道的过程就分析完成了。这个过程比较复杂，这里小结一下：

        A. 即将会被激活的Activity窗口，会通知InputManager，它是当前激活的窗口，因此，一旦发生键盘事件的时候，InputManager就把这个键盘事件抛给这个Activity处理；

        B. 应用程序会为这个Activity窗口和InputManager之间创建一个键盘消息接收通道，这个通道的一端由一个Server端的InputChannel构成，另一端由Client端的InputChannel构成，Server端的InputChannel注册在由InputManager所管理的InputDispatcher中，而Client端的InputChannel注册在由应用程序主线程的消息循环对象Looper中；

        C. 注册在InputDispatcher中的InputChannel由一个反向管道的读端和一个前向管道的写端组成，而注册在应用程序主线程的消息循环对象Looper中的InputChannel由这个前向管道的读端和反向管道的写端组成，这种交叉结构使得当有键盘事件发生时，InputDispatcher可以把这个事件通知给应用程序。

        应用程序注册好键盘消息接收通道后，接下来就开始分析InputManager分发键盘消息给应用程序的过程了。

        3. InputManager分发键盘消息给应用程序的过程分析

        在分析InputManager分发键盘消息给应用程序的过程之前，我们先假设现在没有键盘事件发生，因此，InputManager中的InputReader正在睡眠等待键盘事件的发生，而InputManager中的InputDispatcher正在等待InputReader从睡眠中醒过来并且唤醒它，而应用程序也正在消息循环中等待InputDispatcher从睡眠中醒过来并且唤醒它。这时候，用户按下键盘中的一个键，于是，一系列唤醒的事件就依次发生了，一直到应用程序中正在显示的Activity得到通知，有键盘事件发生了。我们先来看这个过程的序列图，然后再详细分析每一个步骤：

 Step 1. InputReader.pollOnce

        Step 2. EventHub.getEvent

        这两个函数分别定义在frameworks/base/libs/ui/InputReader.cpp和frameworks/base/libs/ui/EventHub.cpp文件中，前面我们在分析InputManager的启动过程的Step 17和Step 18时，已经看到过这两个函数了。InputReaderThread线程会不民地循环调用InputReader.pollOnce函数来读入键盘事件，而实际的键盘事件读入操作是由EventHub.getEvent函数来进行的。如果当前没有键盘事件发生，InputReaderThread线程就会睡眠在EventHub.getEvent函数上，而当键盘事件发生后，就会把这个事件封装成一个RawEvent对象，然后返回到pollOnce函数中，执行process函数进一步处理：

 void InputReader::loopOnce() {
     RawEvent rawEvent;
     mEventHub->getEvent(& rawEvent);

     ......

     process(& rawEvent);
 }

        Step 3. InputReader.process

        这个函数定义在frameworks/base/libs/ui/InputReader.cpp文件中：

 void InputReader::process(const RawEvent* rawEvent) {
     switch (rawEvent->type) {
     case EventHubInterface::DEVICE_ADDED:
         addDevice(rawEvent->deviceId);
         break;