Android Framework------之Input子系统

下面这是基于Android4.2代码的关于Input子系统的笔记。在这篇笔记中，只涉及Android相关的东西，关于Linux内核中对各种输入设备的统一，在本文中不作说明。此外，由于才疏学浅，文中难免有错误的地方，希望各位路过的大神能够予以指出。闲话少叙，先看一张我自己设计的图，如下：

这幅图是为了便于个人理解画出的，里面的注释也比较明白，就不再说明。本文就是以这幅图为基本的思路，简述在Android4.2系统中和Input子系统的相关一些内容。如图，本文将分为以下几个部分叙述：

(0)Input系统的启动

(1)InputReader的功能，以及执行的流程

(2)InputDispatcher的功能，及执行流程

(3)Input子系统中的通信方式是什么？

(4)应用程序是如何接收到并处理事件的

在开始叙述各部分的功能之前，我们还是先说说更个Input系统的来龙去脉，一方面能够知道Input系统从哪儿来，另一方面能对整个系统有个大概的了解，使我们不至于迷失在浩瀚的Android源码中。在Android系统中一说到重要的服务，基本都是要从systemserver进程开始说起，因为他是Android世界的开拓者，创建了Android世界所需要个基础。同样，Input系统也是从systemserver中开始说起，首先创建一个InputManagerService对象，为这个对象设置与WindowManagerService相关的回调函数，然后调用InputManagerService的start函数。

1 inputManager = new InputManagerService(context, wmHandler);
2 inputManager.setWindowManagerCallbacks(wm.getInputMonitor());
3 inputManager.start();

在InputManagerService中start方法会通过JNI调用，启动Native层的InputReaderThread，InputDispatcherThread线程，从而开始Input系统的运行。InputReaderThread主要是执行和InputReader相关的内容，主要是从EventHub中读取事件，预处理事件，然会是根据policy来处理此事件，最后发送一个消息到InputDispatcher中通知事件的产生。紧接着InputDispatcher会开始事件的分发，通过InputChannel把事件分发给WindowManager或者应用程序。说以一个事件的流程是从 Eventhub  ---> InputReader  ---> InputDispatcher  ---> InputPublisher  ---> InputChannel  ---> InputConsumer  --->  WindowManager or Application.这就是整个事件分发的大致流程。

　　由这个大致的流程开始，我们逐步来解析Android系统Input的内容。从Input的启动开始，也就是InputManagerService的创建和线程的启动开始。先看InputManagerService的构造函数，代码如下:

 1     public InputManagerService(Context context, Handler handler) {//这里的handler是WindowManagerService处理消息专用的线程，InputManagerService会把消息发送到这个线程中loop
 2         this.mContext = context;
 3         this.mHandler = new InputManagerHandler(handler.getLooper());//而和InputManagerService相关的消息的处理时在这个对象中完成的
 4 
 5         mUseDevInputEventForAudioJack =
 6                 context.getResources().getBoolean(R.bool.config_useDevInputEventForAudioJack);
 7         Slog.i(TAG, "Initializing input manager, mUseDevInputEventForAudioJack="
 8                 + mUseDevInputEventForAudioJack);
 9         mPtr = nativeInit(this, mContext, mHandler.getLooper().getQueue());//通过JNI调用来启动native层的input系统，然后把返回值存放在mPtr中
10     }

从代码可以看出，InputManagerService的构造是很简单的，只是在最后通过JNI方法初始化了native层的Input系统。接下来我们就看看在native层都做了些什么，代码如下：

 1 static jint nativeInit(JNIEnv* env, jclass clazz,
 2         jobject serviceObj, jobject contextObj, jobject messageQueueObj) {
 3     sp messageQueue = android_os_MessageQueue_getMessageQueue(env, messageQueueObj);
 4     if (messageQueue == NULL) {
 5         jniThrowRuntimeException(env, "MessageQueue is not initialized.");
 6         return 0;
 7     }
 8 　　//这里实例化了NativeInputManagerService的一个对象，使用的Java层的MessageQueue的Looper，意味着Java层消息和Native消息是在同一个MessageQueue中的
 9     NativeInputManager* im = new NativeInputManager(contextObj, serviceObj,
10             messageQueue->getLooper());
11     im->incStrong(0);
12     return reinterpret_cast(im);//把新建的NativeInputManager强制转换，返回给Java层
13 }

在native层初始化的时候，创建了一个名叫NativeInputMnager的对象，这个对象是很重要的，因为它主要负责和系统的其他模块交互，而且InputReader和InputDispatcher都是只运行在Native层中，如果需要调用Java函数也是通过这个对象进行的，另外他实现了InputReaderPolicyInterface和InputDispatcherPolicyInterface，是一个重要的Policy。NativeInputManager在构造过程中，完成了InputManager在native基本运行组件的创建，比如创建了EventHub对象，它是事件的Android系统的起源地，所有的事件都是它从驱动中读取出来的；还创建了InputReaderThread线程用来执行InputReader的功能；InputDispatcherThread用来执行InputDispatcher的功能；同时也创建了InputManager来管理EventHub，InputReader，InputReaderThread，InputDispatcher，InputDispatcherThread这些Native运行的基本对象。这些对象的创建过程中并没有非常重要的调用，这里略过代码。不过要注意一点的是NativeInputManager是InputReaderPolicyInterface和InputDispatcherPolicyInterface的子类，因此在构造InputReader和InputDispatcher的时候要用到NativieInputManager对象。

　　在对象构建完成后，开始执行start方法，让之前创建的这些对象运行起来。start方法也是比较简单的，就是通过JNI调用让native层的Input系统运行起来，然后在Java层把自己列入WatchDog的监视范围内。之后定义下自己需要接受的外部通知等。这个过程看代码的话，比较容易，不再列出。那么到这里位置，整个Input系统就运行起来了，至于其中具体的功能我们再逐步分析。这部分内容叙述完毕。

 

(1)InputReader的功能，以及执行的流程

　　从前面的内容我们可以知道，在InputManager的start方法被调用会，会执行两个线程，分别是InputReaderThread和InputDispatcherThread，虽然它们的启动在代码上有先后之分，但是在实际执行过程中是没有先后的，所以先从哪个线程开始解析Input系统不是很重要的。不过，我是按照从事件的产生到分发开始解析的，所以这里我是选择从InputReader开始。InputReader是Android系统中重要的部分，根据Android文档中的描述，主要功能就是：(1) 从EventHub读取事件，这些事件是元事件，即没有经过加工或者仅仅是简单加工的处理的事件；(2)把这些事件加工处理，生成inputEvent事件，这样封装之后的事件，可以满足Android系统的一些需求；(3)把这些事件发送到事件监听器，即QueuedInputListener，这个监听器可以把事件传递给InputDispatcher。下面我们就从线程开始执行的地方一步一步分析这些功能的实现。既然要看InputReader的功能，我就从InputReader的构造函数说起。前面在说到构造InputManager的时候，就创建了InputReader,当时没有介绍起功能和构造方法，我们从这里开始：

 

 1 InputReader::InputReader(const sp& eventHub,
 2         const sp& policy,
 3         const sp& listener) :
 4         mContext(this), mEventHub(eventHub), mPolicy(policy),
 5         mGlobalMetaState(0), mGeneration(1),
 6         mDisableVirtualKeysTimeout(LLONG_MIN), mNextTimeout(LLONG_MAX),
 7         mConfigurationChangesToRefresh(0) {
 8     mQueuedListener = new QueuedInputListener(listener);//在这里创建了一个QueuedInputListener，注意其参数是listener是InputDispatcher
 9 
10     { // acquire lock
11         AutoMutex _l(mLock);
12 
13         refreshConfigurationLocked(0);
14         updateGlobalMetaStateLocked();
15     } // release lock
16 }

 

在InputReader创建的时候，这里把InputDispatcher作为参数传递进来，然后以InputDispatcher作为参数构造出了QueuedInputListener对象。所以现在有这么一个关系：InputReader持有一个QueuedInputListener，而QueuedInputListener持有InputDispatcher对象。接下来，我们继续以线程为线索，分析我们的代码，接着看

1 bool InputReaderThread::threadLoop() {
2     mReader->loopOnce();
3     return true;
4 }

在这里补充一点内容： Android系统在Native层中实现了一个类似于Java中的线程对象，即C++中的Thread类。这个线程类有个特点就是，当线程开始执行后，不一直重复执行threadLoop方法，知道这个线程的强引用计数变为零为止。所以，这里的threadLoop函数会不停地执行下去，也即是mReader->loopOnce()会循环执行下去，每循环一次就能从EventHub中读取出若干事件。下面我们就以一次循环过程为例，分析此线程的执行，loopOnce的代码如下：

 1 void InputReader::loopOnce() {
 2     int32_t oldGeneration;
 3     int32_t timeoutMillis;
 4     bool inputDevicesChanged = false;
 5     Vector inputDevices;
 6     ...
 7     //如果系统刚刚启动，或者有新的设备加入的话，timeoutMillis一般为0,意味着无需等待，可以立即返回；timeoutMillis一般为-1，意味着无限等待
 8     size_t count = mEventHub->getEvents(timeoutMillis, mEventBuffer, EVENT_BUFFER_SIZE);
 9 
10     { 
11         AutoMutex _l(mLock);
12         mReaderIsAliveCondition.broadcast();
13 
14         if (count) {
15             processEventsLocked(mEventBuffer, count);//开始处理读取出来的元事件
16         }
17 
18         ...
19     } 
20 
21     if (inputDevicesChanged) {
22         mPolicy->notifyInputDevicesChanged(inputDevices);
23     }
24     //把QueuedInputListener中的消息全部都开始处理
25     mQueuedListener->flush();
26 }

整个方法的功能就是，从EventHub中读取出若干事件，然会对这些事件进行预处理，然会把QueuedInputListener中的事件分发出去。这个方法中包含了InputReader的主要功能，所以此线程每循环一次，都会执行完成一次InputReader的主要功能。先说从EventHub读取事件功能:

　　1.1  从EventHub获取事件

　　先简单介绍下EvenHub，这个类的主要功能就是主动监视Input驱动的变化，一旦有事件产生，就从产生事件相应的驱动中读取出这个事件。实现这个监视驱动功能，是通过Linux提供的epoll机制来实现。epoll机制简单地说就是高效地I/O多路复用机制，使用epoll_wait来监听所需要的文件描述符的变化，关于epoll的介绍有很多文章，man中也有详细的介绍。EventHub的主要功能是通过epoll_wait来实现的，所以EventHub所在的线程应该会阻塞在epoll_wait方法中，一直等到epoll_wait设置的超时时间。现在我们开始看看EventHub的实现，在EventHub的构造函数中，建立了一个管道，并把这个管道的读端和写端的文件描述符添加到epoll的监视之下，以便于其他的线程或者进程能够使EventHub所在的线程从epoll_wait的阻塞中返回。EventHub在创建完成之后，第一个被调用的方法就是getEvents，而且这个方法也是EventHub的主要功能，对于这个方法需要仔细分析，我们把getEvents方法也分成了三个部分去解析，分别是：打开设备部分；事件读取部分；等待部分。这三个部分中，以事件的读取部分为重点。设备打开部分一般发生在Input系统建立的时候调用，所以在系统启动完成，稳定之后，这部分内容应该不会再被执行的；而等待部分较为简单。不过这些作为系统必不可少的部分，还是要一一说明的，先说设备打开部分吧，代码如下：

 1 size_t EventHub::getEvents(int timeoutMillis, RawEvent* buffer, size_t bufferSize) {
 2     ...
 3     struct input_event readBuffer[bufferSize];
 4     //这是元事件指针，可以指向一系列的事件，这些事件按照数组的方式存放的
 5     RawEvent* event = buffer;
 6     size_t capacity = bufferSize;
 7     bool awoken = false;
 8     for (;;) {
 9         nsecs_t now = systemTime(SYSTEM_TIME_MONOTONIC);
10         //mNeedToReopenDevices = false; mClosingDevices = 0;mNeedToSendFinishedDeviceScan = false;mOpeningDevices = 0
11         //mNeedToScanDevices = true
12         if (mNeedToScanDevices) {
13             mNeedToScanDevices = false;
14             scanDevicesLocked();
15             mNeedToSendFinishedDeviceScan = true;
16         }
17 　　　　...

EventHub对象在初始化的时候，有很多变量都已经赋值，所以我把代码中判断不成立的代码块暂时都拿掉了，只留下了在Input系统启动时候会执行的内容,也就是scanDevicesLocked方法。在这个方法执行之后，肯定会产生一些设备添加，移除之类的事件，到时候在一一分析。在这个方法中，使用了一个结构体叫RawEvent，使用这个结构体简单地表明事件发生的基本信息，代码如下：

struct RawEvent {
    nsecs_t when;//事件发生的时间，在getEvents中对于事件时间的处理也是值得关注的
    int32_t deviceId;//产生这个事件对应的设备的ID，与具体的硬件无关，其数值和设备打开的顺序有关
    int32_t type;//事件的类型
    int32_t code;//事件对应的事件码
    int32_t value;//事件的内容
};

RawEvent来自两种，一种是在打开设备时自己赋值，不如设备的添加，移除等，这些事件对应的RawEvent都是getEvents自己赋值的，便于InputReader处理；还有一种是来自驱动的产生的事件，由驱动产生的这类事件，在内容中有其自己的定义的类型，就是input_event。 getEvents可以根据input_event产生相应的RawEvent便于InputReader处理。这里要额外说明一点的就是RawEvent的type，如果是由输入设备产生的事件，那么这个type是和输入设备本身的特性相关的，下面列举出Linux中支持的事件类型：

EV_SYN	用于标识独立的事件，这些独立的事件时在时间或者空间上是可以分离的，比如在多点触摸中
EV_KEY	用于标识按键，按钮或者类似按键的设备状态的变化
EV_REL	用于描述 对于轴线相对变化量，如鼠标向左移动5个单位
EV_ABS	用于描述 对于轴线的绝对变化量， 比如在触摸屏上的触摸点的坐标
EV_SW	标识二进制的开关状态
EV_LED	表示设备上的LED是开or关
EV_SND	用于标识发送声音到设备
EV_REP	表示自动重复的设备
V_FF	用于标识发送强制要回馈的命令到设备
EV_PWR	对于Power键的一个特殊状态或者切换输入
EV_FF_STATUS	用于收到需要强制回馈的设备状态
EV_MSC	如果不是这些已存在的状态，那么就用这个标识

这个表格来自于Linux内核文档中的Document/input/event-codes.txt，如果以上有翻译不恰当的地方，可以去参考原文档。上面这些类型是Linux支持的所有的事件类型，一般的一类设备可以支持这些类型中的一个或几个。

在Android系统中，常用的设备由触摸屏，键盘或者鼠标等，这些设备一般是能够产生如下类型的事件：

多点触屏	大多是EV_ABS, EV_KEY, EV_SYN,有的还设置了EV_MSC
键盘	EV_KEY, EV_SW
鼠标	EV_REL, EV_KEY, EV_ABS

 这个表格仅仅是一般性而言，具体情况还需要参考相应的设备驱动文件。这里之所以介绍这些东西，是因为在InputReader在预处理这些事件的时候会使用type这个类型。了解了这些之后，继续看EventHub是如何打开这些设备的。 EventHub是通过扫描/dev/input/目录下所有可用的设备，然后逐一打开这些设备，打开这些设备过程中，EventHub又做了一些Input系统必要的工作，比如构造Device对象，把这些设备加入到epoll的监视队列中等，时间戳的设定等。在构造Device对象的时候，是通过InputDeviceIdentifier来构造的，主要思路就是通过ioctl函数从内容中读取出一些必要的信息，然后把这些信息经过InputDeviceIdentifier存入Device中，然后再通过ioctl函数测试设备的属性，把这些属性信息也存入Device中。代码如下：

 

 1 status_t EventHub::openDeviceLocked(const char *devicePath) {
 2     ...
 3     InputDeviceIdentifier identifier;
 4 
 5     // 获取设备的名字，如果成功获取到设备的名字，把它存入InputDeviceIdentifier中
 6     if(ioctl(fd, EVIOCGNAME(sizeof(buffer) - 1), &buffer) < 1) {
 7         //fprintf(stderr, "could not get device name for %s, %s\n", devicePath, strerror(errno));
 8     } else {
 9         buffer[sizeof(buffer) - 1] = '\0';
10         identifier.name.setTo(buffer);
11     }
12     ...
13 
14     //构造EventHub所需要的对象Device，这里的fd是刚刚打开的设备的文件描述符
15     int32_t deviceId = mNextDeviceId++;//从这里可以看出，deviceId是与设备无关的，和打开顺序有关
16     Device* device = new Device(fd, deviceId, String8(devicePath), identifier);
17 
18     // 测试设备能够产生的事件的类型，这些事件类型在前文中已经说到过。这里就是Android支持的事件类型，是Kernel的一个子集
19     ioctl(fd, EVIOCGBIT(EV_KEY, sizeof(device->keyBitmask)), device->keyBitmask);
20     ioctl(fd, EVIOCGBIT(EV_ABS, sizeof(device->absBitmask)), device->absBitmask);
21     ioctl(fd, EVIOCGBIT(EV_REL, sizeof(device->relBitmask)), device->relBitmask);
22     ioctl(fd, EVIOCGBIT(EV_SW, sizeof(device->swBitmask)), device->swBitmask);
23     ioctl(fd, EVIOCGBIT(EV_LED, sizeof(device->ledBitmask)), device->ledBitmask);
24     ioctl(fd, EVIOCGBIT(EV_FF, sizeof(device->ffBitmask)), device->ffBitmask);
25     ioctl(fd, EVIOCGPROP(sizeof(device->propBitmask)), device->propBitmask);
26     ...
27     //根据前面获取到的设备属性，检测设备是鼠标，键盘，手柄等，然后把这些信息继续存入Device
28     if (test_bit(BTN_MOUSE, device->keyBitmask)
29             && test_bit(REL_X, device->relBitmask)
30             && test_bit(REL_Y, device->relBitmask)) {
31         device->classes |= INPUT_DEVICE_CLASS_CURSOR;
32     }
33     ...

 

这部分代码，把InputDeviceIdentifier转化为了Device，因为Device能够存储更多的信息，是EventHub所需要的。在打开设备的时候对这些Device完成了初始化。然后就是把这些设备加入epoll的监视中，代码如下：

1 epoll_ctl(mEpollFd, EPOLL_CTL_ADD, fd, &eventItem)

如此之后，只要设备有输入事件的产生，通过epoll就能从阻塞中返回。之后就是设置设备的硬件时钟。在报告事件的时候，我们要使用的时钟是monotonic clock, 这时钟的特点就是在每次开机的时候初始化为0。事件发生时的时间戳在input系统中使用非常广泛，而且Input系统会假设事件的时间戳是monotonic的时间点。最后把这些设备添加到EventHub的一个Vector中，类似如下格式：

deviceId	Device*
1	Device*
2	Device*
...	...

这个数组将会在EventHub中广泛地使用，经常使用的方式是通过deviceId获取Device设备。到这里，打开设备的工作已经完成，而且为EventHub的工作创建了一些有用的变量和数组等。EventHub中的第一个功能，打开设备已经完成。接着我们在看看事件等待部分，最后再说事件的读取。其实事件的等待部分很简单，主要的代码就一行，如下：

epoll_wait(mEpollFd, mPendingEventItems, EPOLL_MAX_EVENTS, timeoutMillis);

注意代码中的最后一个参数timeoutMillis，前面已经说到过，一般来说这个参数是-1，意味着线程会在这个地方阻塞，无限等待下去，直到有事件的发生，而在新的设备加入的时候，这个值为0，意味着可以立即返回。所以，在系统启动完成后，如果没有事件发生的话，InputReaderThread线程会阻塞在这里，一直等待事件的发生。最后，我们看看事件的读取部分，代码如下：

 1         bool deviceChanged = false;
 2         while (mPendingEventIndex < mPendingEventCount) {
 3             const struct epoll_event& eventItem = mPendingEventItems[mPendingEventIndex++];
 4             ...//这里省略了对于其他的epoll类型的处理。如果是EPOLLIN类型的事件，意味着epoll监视的文件描述符中有写入事件，这类事件是输入事件，
 5             Device* device = mDevices.valueAt(deviceIndex);
 6             if (eventItem.events & EPOLLIN) {//从产生事件的描述符中读取出事件，放入readerBuffer
 7                 int32_t readSize = read(device->fd, readBuffer,
 8                         sizeof(struct input_event) * capacity);
 9                 if (readSize == 0 || (readSize < 0 && errno == ENODEV)) {
10                     deviceChanged = true;
11                     closeDeviceLocked(device);
12                 } else if (readSize < 0) {
13                     if (errno != EAGAIN && errno != EINTR) {
14                         ALOGW("could not get event (errno=%d)", errno);
15                     }
16                 } else if ((readSize % sizeof(struct input_event)) != 0) {
17                     ALOGE("could not get event (wrong size: %d)", readSize);
18                 } else {
19                     int32_t deviceId = device->id == mBuiltInKeyboardId ? 0 : device->id;
20 　　　　　　　　　　　　//在设备上产生的事件的个数
21                     size_t count = size_t(readSize) / sizeof(struct input_event);
22                     for (size_t i = 0; i < count; i++) {
23                         const struct input_event& iev = readBuffer[i];
24                         ...//这里省略了对于事件时间戳的设定，考虑的因素挺多，虽时间戳对于输入事件很重要，但是不应该是本次讨论的重点
25                         event->when = now;
26                         event->deviceId = deviceId;
27                         event->type = iev.type;
28                         event->code = iev.code;
29                         event->value = iev.value;
30                         event += 1;
31                     }
32                     capacity -= count;
33                     if (capacity == 0) {
34                         mPendingEventIndex -= 1;
35                         break;
36                     }
37                 }
38             } 
39             ...
40         }

其实这段代码也是非常简单的，基本过程就是，监视到有事件的产生，把事件读取出来，不过这里读出的事件是input_event类型的，然后在逐个把input_event事件转化为InputReader需要的RawEvent类型的事件，放入InputReader提供给EventHub的数组中（通过getEvents参数传递进来的）。说起来很简单，其实也很简单。上面这些代码就是读取事件的核心部分。总结一下，EventHub负责打开/dev/input/目录下的所有设备，然后为每一个设备创建一个Device,并把这个Device放入EventHub所定义的数组们Device中。之后，就是把这个设备纳入监视范围。然后就是开始等待事件的发生，一旦有事件发生，就从产生事件的设备中读取出这些设备，把这些事件转化为RawEvent类型放入InputReader提供的事件数组中，之后返回。到这里，从EventHub获取事件就结束了。

　　1.2  InputReader对元事件的处理

 　　由上节的内容，我们知道，从EventHub获得的事件有两种，一种是设备添加，移除类的；另一种是由输入设备产生的事件。InputReader在处理这两类事件稍微有点不一样。先看设备添加类型的事件，这些添加设备事件的处理，为InputReader的工作打下了基础，因为InputReader可以根据添加的设备定义一些数据结构，为以后处理由此设备产生的事件打下基础。接着我们从代码开始看看InputReader对于元事件的处理： 

 1 void InputReader::processEventsLocked(const RawEvent* rawEvents, size_t count) {
 2     for (const RawEvent* rawEvent = rawEvents; count;) {
 3         int32_t type = rawEvent->type;
 4         size_t batchSize = 1;
 5         if (type < EventHubInterface::FIRST_SYNTHETIC_EVENT) {
 6             int32_t deviceId = rawEvent->deviceId;
 7             while (batchSize < count) {
 8                 if (rawEvent[batchSize].type >= EventHubInterface::FIRST_SYNTHETIC_EVENT
 9                         || rawEvent[batchSize].deviceId != deviceId) {
10                     break;
11                 }
12                 batchSize += 1;
13             }
14             //有输入设备产生的事件，在这个方法中处理
15             processEventsForDeviceLocked(deviceId, rawEvent, batchSize);
16         } else {
17             switch (rawEvent->type) {//设备添加类的事件在这里处理
18             case EventHubInterface::DEVICE_ADDED:
19                 addDeviceLocked(rawEvent->when, rawEvent->deviceId);//这个方法中创建了InputReader所必须的一些数据结构
20                 break;
21             case EventHubInterface::DEVICE_REMOVED:
22                 removeDeviceLocked(rawEvent->when, rawEvent->deviceId);
23                 break;
24             case EventHubInterface::FINISHED_DEVICE_SCAN:
25                 handleConfigurationChangedLocked(rawEvent->when);
26                 break;
27             default:
28                 ALOG_ASSERT(false); // can't happen
29                 break;
30             }
31         }
32         count -= batchSize;
33         rawEvent += batchSize;
34     }
35 }

 先从设备添加类的事件说起，看看在添加设备的时候，都创建了那些数据结构。对于addDeviceLocked的源码，这里就不列举出来，主要说说在InputReader在功能实现时用的变量有那些，分别是是InputDevice，InputMapper。InputDevice代表输入设备的一个状态；InputMapper是某一类事件是如何处理的；两者之间的关系是，一个InputDevice可以产生多种类型的事件，因此他可以对应多个InputMapper。另外，在InputReader中也保存了一个vector来保存InputDevice，这个Vector的名字也叫mDevices，和EventHub中的mDevices类似，不过保存的内容有些不同。在InputReader的mDevices中保存的,而在EventHub中保存的是,不过两者的id是一致的，而且每个InputDevice都是通过Devices来构造的。能够完成加工RawEvent工作的还是通过不同的InputMapper来完成的，这些InputMapper根据Android系统支持的类型分成了一下几类，

InputMapper类型	能够处理的事件的类型
SwitchInputMapper	EV_SW, EV_SYN
KeyboardInputMapper	EV_KEY, EV_SYN, EV_MSC
CursorInputMapper	EV_KEY, EV_SYN, EV_REL
TouchInputMapper	EV_KEY, EV_SYN, EV_REL
SingleTouchInputMapper	EV_KEY, EV_SYN, EV_REL, EV_ABS
MultiTouchInputMapper	EV_KEY, EV_SYN, EV_REL, EV_ABS
JoyStickInputMapper	EV_ABS, EV_SYN
VibratorInputMapper	--

这里就基本完成了对于添加设备类的事件的处理，接下来就看是分析对于输入设备产生的元事件的处理。对于输入事件的处理主要是通过方法processEventsForDeviceLocked进行的，在这个方法执行之前，已经找到了产生这个事件的输入设备了，然后把输入设备作为参数传递进去，processEventsForDeviceLocked方法根据deviceId找到相应的InputDevice，然后调用InputDevice的process方法进行处理这个事件。下面，结合InputDevice的process方法的这段代码，我们一起看看输入事件是如何处理的，代码如下：

 1 void InputDevice::process(const RawEvent* rawEvents, size_t count) {
 2     size_t numMappers = mMappers.size();
 3     for (const RawEvent* rawEvent = rawEvents; count--; rawEvent++) {
 4             ...//省略了一些与判断的处理，留下核心部分的代码
 5             for (size_t i = 0; i < numMappers; i++) {
 6                 InputMapper* mapper = mMappers[i];
 7                 mapper->process(rawEvent);//让各个InputMapper去处理元事件，注意参数还是RawEvent类型
 8             }
 9     }
10     
11 }

在这个方法中，注意有内外两个循环，外循环是逐一取出元事件，内循环是让每一个InputMapper都处理这个事件。之所以让每一个InputMapper都进行处理元事件，而不是只要对应的InputMapper去处理，是因为担心只让对应的InputMapper处理元事件会产生副作用，比如For example, joystick movement events and gamepad button presses are handled by different mappers but they should be dispatched in the order received. 对于每一个InputMapper都要处理元事件，我们不做一一分析，仅仅拿出典型的键盘输入事件分析。处理过程如下：

 1 void KeyboardInputMapper::process(const RawEvent* rawEvent) {
 2     switch (rawEvent->type) {
 3     case EV_KEY: {
 4         int32_t scanCode = rawEvent->code;
 5         int32_t usageCode = mCurrentHidUsage;
 6         mCurrentHidUsage = 0;
 7 
 8         if (isKeyboardOrGamepadKey(scanCode)) {
 9             int32_t keyCode;
10             uint32_t flags;
11             if (getEventHub()->mapKey(getDeviceId(), scanCode, usageCode, &keyCode, &flags)) {
12                 keyCode = AKEYCODE_UNKNOWN;
13                 flags = 0;
14             }
15             processKey(rawEvent->when, rawEvent->value != 0, keyCode, scanCode, flags);
16         }
17         break;
18     }
19  ...//省略了对于其他事件类型EV_SYN， EV_MSC的处理代码
20 }
21 
22 
23 void KeyboardInputMapper::processKey(nsecs_t when, bool down, int32_t keyCode,
24         int32_t scanCode, uint32_t policyFlags) {
25     ...//省略了对于元事件处理过程的代码，主要就是发生事件，事件代码，扫描码，是按下还是弹起，
26 　　　　//总之，用于构建下面NotifyKeyArgs的参数大都是在这里获取的。
27     NotifyKeyArgs args(when, getDeviceId(), mSource, policyFlags,
28             down ? AKEY_EVENT_ACTION_DOWN : AKEY_EVENT_ACTION_UP,
29             AKEY_EVENT_FLAG_FROM_SYSTEM, keyCode, scanCode, newMetaState, downTime);
30     getListener()->notifyKey(&args);
31 }

这是InputReader对于元事件处理的过程。在处理完成后，在最后调用了一个重要的方法getListener()->notifyKey(&args)方法。在InputReader处理各种元事件的时候，基本过程都是这样的，把元事件中的各项信息构建一个NotifyArgs，然后通过QueuedInputListener来通知InputDispatcher。由此，InputReader的处理过程开始进入了和InputDispatcher交互的阶段。其实在QueuedInputListener中对于notifyKey的实现非常简单，仅仅是把这些事件的参数压入队列而已，并没有做太多的操作就返回了。

　　1.3   InputReader把事件发送到InputDispatcher

 　　前面我们已经知道了，InputReader把元事件处理完毕后，构造了一个NotifyArgs，并把这个对象压入了QueuedInputListener的队列中，然后就返回了。当时我们并不知道如何把这些队列中的事件发送的InputDispatcher中的。这里，就给出了这个过程。InputReader调用QueuedInputListener的flush方法，把QueuedInputListener队列中的所有事件都发送到InputDispatcher中。下面我们就分析这个过程，从QueuedInputListener的flush方法说起，代码如下：

1 void QueuedInputListener::flush() {
2     size_t count = mArgsQueue.size();//前面，我们就是把NotifyArgs放入了mArgsQueue中
3     for (size_t i = 0; i < count; i++) {
4         NotifyArgs* args = mArgsQueue[i];
5         args->notify(mInnerListener);//逐个取出NotifyArgs，然后调用notify方法，注意这里面的参数是mInnerListener，是InputDispatcher
6         delete args;
7     }
8     mArgsQueue.clear();
9 }

这里从队列中逐个取出NotifyArgs,然后调用他们的notify方法。在QueuedInputListener创建的时候，我们传入构造函数的的参数是一个InputDispatcher，在这里就使用到了，把这个InputDispatcher作为参数向下传递。在NotifyArgs的notify方法中，基本都类似于

1 62void NotifyKeyArgs::notify(const sp& listener) const {
2 63    listener->notifyKey(this);//调用InputDispatcher的对应的方法。
3 64}

　　到这里，我们对于InputReader的功能的分析就完成了。总结一下，基本过程说就是：InputReader从EventHub中读取出来元事件，预处理加工这些元事件成为NotifyArgs，然后通过QueuedInputListener把他们通知给InputDispatcher。整个Input的流程图太大，在这里显示不完全。现在仅仅拿出，和InputReader功能相关的部分的流程图，图中是以一个键盘事件的处理过程。图如下：

2.   InputDispatcher的功能和流程

 　　在开始介绍InputDispatcher的功能之前，先看看Android文档对于其功能的描述：把输入事件发送到他的目标中去。他的目标可能是应用程序，也可能是WindowManagerService。如果是应用程序的话，可以通过registerInputChannel来定义输入事件的目标。我们已经了解InputDispatcher的唯一一个功能就是分发事件。知道了其功能之后，我们就开始分析InputDispatcher是如何实现这些功能的吧。先看他的构造函数，InputDispatcher创建了一个Looper，代码如下：

 

1  mLooper = new Looper(false);

 

这意味着，InputDispatcher有自己的Looper，没有和别人共用，信息也是自己在循环的。这个Looper是native层的Looper，由C++代码实现。在构建Looper过程中，新建了一个管道，这个管道仅仅起到了唤醒Looper，让其能从阻塞等待中返回。Looper中创建的管道是实现Looper功能的重要的方式，是通用的，不是仅仅为了InputDispatcher准备的。看完构造函数之后，我们接着分析InputDispatcher的功能，接着上节中的QueuedInputListener通知InputDispatcher有新的按键事件说起。这里还是接着上面的以按键的处理，接着看InputDispatcher是如何实现分发的，代码如下：

 1 void InputDispatcher::notifyKey(const NotifyKeyArgs* args) {
 2     ...
 3     KeyEvent event;//在这里通过传递进来的NotifyArgs为参数，构建KeyEvent
 4     event.initialize(args->deviceId, args->source, args->action,
 5             flags, args->keyCode, args->scanCode, metaState, 0,
 6             args->downTime, args->eventTime);
 7 　　//通过NativeInputManager把这个KeyEvent最终传递给WindowManagerService去处理
 8     mPolicy->interceptKeyBeforeQueueing(&event, /*byref*/ policyFlags);
 9     ...
10     bool needWake;
11     ...
12         int32_t repeatCount = 0;//这下面构建KeyEntry
13         KeyEntry* newEntry = new KeyEntry(args->eventTime,
14                 args->deviceId, args->source, policyFlags,
15                 args->action, flags, args->keyCode, args->scanCode,
16                 metaState, repeatCount, args->downTime);
17 
18         needWake = enqueueInboundEventLocked(newEntry);
19         mLock.unlock();
20 
21     if (needWake) {//唤醒等待Looper
22         mLooper->wake();
23     }
24 }

我们先从代码中的line 8开始，这行代码的意思是，把KeyEvent发送出去，至于目的地是哪儿，在InputDispatcherPolicy中会有决定。是NativeInputManager实现了这个Policy，所以代码的执行会进入NativeInputManager中。

　事件在入队前(before enqueue)的处理

　　　　在文章的前面已经说到过，NativeInputManager负责和系统的其他模块交互--是其功能之一。把这个KeyEvent传递到NativeInputManager之后，继续分发，最终会把这个KeyEvent传递到PhoneWindowManager中去处理这个事件，传递过程如下：NativeInputManager->interceptKeyBeforeQueueing  ----> InputManagerService.interceptKeyBeforeQueueing ----> InputMonitor.interceptKeyBeforeQueueing ---->  PhoneWindowManager.interceptKeyBeforeQueueing.大致过程是这样的，具体细节不再赘述。在传递过程中是跨线程的。通过这一系列的方法的名字可以看出，是在事件进入InputDispatcher的队列之前，进行的一些处理。在PhoneWindowManager处理事件之后，会有一个返回值来标记这一事件处理的结果是怎样的，为后面的事件进入队列做准备。在PhoneWindowManager对事件进行前期的拦截处理过程时，一般首先把事件都标记上PASS_TO_USER，即这个事件要交给应用程序去处理，但是在处理过程中决定，有些事件是没必要传递给应用程序的，比如：在通过过程中按下音量相关的事件，挂断电话的事件，power键的处理，以及拨打电话的事件。这些事件的处理结果都是不必传递到应用程序的，这个结果最为返回值，最终会一步一步地返回到NativeInputManager中,这个返回值会作为NativeInputManager的policyFlags的一部分，供InputDispatcher使用。在PhoneWindowManager对事件处理完成后，才会把这个事件构造成为一个形式为EventEntry放入队列。到这里，我们的工作仍在InputReaderThread的线程中，虽然是对InputDispatcher的操作。接下来才是真正进入InputDispatcherTread线程对InputDispatcher操作。通过InputDispatcher的mLooper的wake方法，唤醒InputDispatcherThread线程。关于Looper如何在wake时是如何通过管道的方式去实现的，这个过程应该放在一篇单独的文章中详细地去说明，在以后的文章中，我会说到Looper在native实现时的一些特点的。这里，我们知道InputDispatcherThread线程被唤醒了。如果你已忘记InputDispatcherThread线程是何时被阻塞，那就回头再重新看看吧。学习别人的思路就是这样，反复回头看，才能不至于迷失在别人的思维中。然后就开始执行InputDispatcher的threadLoop函数，之后就调用InputDispatcher的dispatchOnce方法，代码如下：

 1 void InputDispatcher::dispatchOnce() {
 2     nsecs_t nextWakeupTime = LONG_LONG_MAX;//应该是64位二进制所能表示的最大值，大概是2^63-1，即9223372036854775807
 3     { 
 4         AutoMutex _l(mLock);
 5         mDispatcherIsAliveCondition.broadcast();
 6 　　　　//如果没有等待执行的命令的话，就开始一次循环分发。在循环过程中，可能会有一些命令产生。这里的命令大概是模式设计中的：命令模式吧
 7         if (!haveCommandsLocked()) {
 8             dispatchOnceInnerLocked(&nextWakeupTime);
 9         }
10 　　　　//如果任何等待执行的命令的话，那么就执行这些命令；假如有命令已经执行了，那么下次poll的时候直接唤醒
11         if (runCommandsLockedInterruptible()) {
12             nextWakeupTime = LONG_LONG_MIN;//#define LONG_LONG_MIN  (-__LONG_LONG_MAX__-1LL)， 即-9223372036854775808
13         }
14     } // release lock
15 
16     nsecs_t currentTime = now();
17     int timeoutMillis = toMillisecondTimeoutDelay(currentTime, nextWakeupTime);
18     mLooper->pollOnce(timeoutMillis);
19 }

 InputDispatcher的主要功能就在这段代码中，这是个轮廓。要想知道具体的功能的实现，还要需要逐步分析下去。先看line7和line8中的代码，如果是一次正常的分发循环（dispatch loop）的话，应该是没有等待执行的命令。为什么会没有等待执行的命令，在后面会说到原因，先不要着急。所以接下就开始dispatchOnceInnerLocke方法，从这个方法的名字可以看出，这应该是功能的核心实现部分。看其代码是如何实现的：

 1 void InputDispatcher::dispatchOnceInnerLocked(nsecs_t* nextWakeupTime) {
 2     nsecs_t currentTime = now();
 3 　　　//如果等待处理的事件不存在的话
 4     if (! mPendingEvent) {
 5         if (mInboundQueue.isEmpty()) {
 6             ...//省略了，当等待处理事件不存在且事件队列为空的时候的处理
 7         } else {//从事件队列的头部取出一个事件
 8             mPendingEvent = mInboundQueue.dequeueAtHead();
 9             traceInboundQueueLengthLocked();
10         }
11         if (mPendingEvent->policyFlags & POLICY_FLAG_PASS_TO_USER) {
12         　　//通知某些Activity一些事件的发生，通过这个方法的名字可以联想一下，一些社交网站中的“捅一下”应用，或者QQ中的震动窗口功能，
13             pokeUserActivityLocked(mPendingEvent);//这个方法的功能就类似于那些作用。只不过这里主要是用来“捅一下”PowerManagerService的
14         }
15 
16         // Get ready to dispatch the event.
17         resetANRTimeoutsLocked();
18     }
19 　　//现在我们有事件需要开始处理了
20     ALOG_ASSERT(mPendingEvent != NULL);
21     bool done = false;
22     DropReason dropReason = DROP_REASON_NOT_DROPPED;//在开始处理之前，所有的事件都不必丢弃
23     if (!(mPendingEvent->policyFlags & POLICY_FLAG_PASS_TO_USER)) {
24         dropReason = DROP_REASON_POLICY;
25     } else if (!mDispatchEnabled) {
26         dropReason = DROP_REASON_DISABLED;
27     }
28 
29     if (mNextUnblockedEvent == mPendingEvent) {
30         mNextUnblockedEvent = NULL;
31     }
32 
33     switch (mPendingEvent->type) {
34 ...//省略了对于config change类别的事件的处理
35 ...//省略了对于设备重置事件的处理
36     case EventEntry::TYPE_KEY: {
37         KeyEntry* typedEntry = static_cast(mPendingEvent);
38         if (isAppSwitchDue) {//下面这些内容，是对于事件是否需要丢弃的分析
39             if (isAppSwitchKeyEventLocked(typedEntry)) {
40                 resetPendingAppSwitchLocked(true);
41                 isAppSwitchDue = false;
42             } else if (dropReason == DROP_REASON_NOT_DROPPED) {
43                 dropReason = DROP_REASON_APP_SWITCH;
44             }
45         }
46         if (dropReason == DROP_REASON_NOT_DROPPED
47                 && isStaleEventLocked(currentTime, typedEntry)) {
48             dropReason = DROP_REASON_STALE;
49         }
50         if (dropReason == DROP_REASON_NOT_DROPPED && mNextUnblockedEvent) {
51             dropReason = DROP_REASON_BLOCKED;
52         }//无论事件是否要被丢弃，都要经过如下的处理
53         done = dispatchKeyLocked(currentTime, typedEntry, &dropReason, nextWakeupTime);
54         break;
55     }
56     ...//省略了对于motion事件的处理
57     }
58     ...
59 }

这个方法中的大部分功能都已经在代码中注释了，主要就是取出事件，分析是否需要丢弃，然后就是开始按照类型分发事件，我们假设的是按键事件，所以接下来就是调用dispatchKeyLocked方法来分发。

 1 bool InputDispatcher::dispatchKeyLocked(nsecs_t currentTime, KeyEntry* entry,
 2         DropReason* dropReason, nsecs_t* nextWakeupTime) {
 3     if (! entry->dispatchInProgress) {
 4         ...//省略了对于重复事件在各种情况下的处理
 5     }
 6 
 7    ...//在入队列之前，对于事件有个一次intercept，这里是对事件的intercept结果的处理
 8     Vector inputTargets;
 9     int32_t injectionResult = findFocusedWindowTargetsLocked(currentTime,
10             entry, inputTargets, nextWakeupTime);//寻找事件发送到的目标窗口
11      // 分发事件
12     dispatchEventLocked(currentTime, entry, inputTargets);
13     return true;
14 }

这个方法中主要就是寻找到事件应该分发到的目标，可能是应用窗口.这个目标应用的窗口寻找与应用程序启动时设置到窗口有关。在下一小节中会说到这个窗口是如何找到的。其代码不是很复杂，自己看看的话也很容易能够明白。其他的内容在上面的注释中也有说明。下面还是将注意力集中在事件分发上，注意这里传入dispatchEventLocked的参数中inputTargets是复数，也就是说可能有多个目标。所以在方法dispatchEventLocked中就是根据每一个target对应的inputChannel找到connection，然后 prepareDispatchCycleLocked使用这个connection把事件逐个分发到target中。 在prepareDispatchCycleLocked方法中，主要就是根据事件是否可以分割，分别把事件放入队列。在入队列的之后，InputPublisher的发布事件的队列就不再为空，然后会调用 startDispatchCycleLocked方法，通过InputPublisher开始发布事件。大致过程如此，为了减少篇幅，这里就不再列出代码了。流程图如下：

 

整个的流程图太大了，不太方便，这里仅仅是其中的一部分。说明一点：图中Looper到InputDispatcher中的dispatcherOnce不是调用关系，只是Looper把其所在的进程即InputDispatcherThread线程给唤醒，所以开始执行dispatchOnce。这里到最后就是调用InputPublisher的publishKeyEvent方法，把事件发布出去。在前面我们说到过这么一个问题，等待执行的命令为什么在一次正常的事件分发之后应该为空？这些命令产生的地方分别在pokeUserActivity方法中， 和dispatchKeyLocked中等等在使用postCommand把命令放入队列的地方。在上面这个过程执行完毕后，会返回到dispatchOnce方法中，接着往下执行，也就是执行代码：

runCommandsLockedInterruptible()

也就是前面dispatchOnce方法的line 11. 这个方法的功能就是执行之前放入命令队列的命令。具体的代码不再列出。到这里，关于InputDispatcher的功能--唯一的一个功能--事件分发，就算介绍完了。

 

3   通信方式

　　从这节开始介绍Input子系统是如何实现通信的。其实InputReaderThread与InputDispatcherThread之间， InputDispatcherThread和WindowManagerService所在线程之间的通信是相对简单的，因为他们在相同的进程---systemServer中，因此可以通过使用同一个对象就可以完成通信。这里就不多做介绍。主要是分析InputDispatcherThread与应用程序之间传递事件时的通信----socket通信，以及Input和应用程序是如何利用socket方式完成事件的传递的。

　　在开始之前，还是再续点闲话吧，要不然直接开始下面的分析，会让人觉得很突兀。我之所以能找到思路从下面的这个节点分析，是因为在写这篇文章之前，我已经对Input系统有了大概的了解了，对于其中的通信方式也有了了解的。从通信方式的建立，反推一步一步地找到了ViewRootImpl中的。在文章中没有按照我寻找线索的方式去写，因为我觉得那么写的话有点混乱，而且要时刻保持紧张的心态去分析，太累。所以才能这么开始的，希望能够获得理解。在每个Activity创建的时候，都会拥有其相应的ViewRootImpl。这个知识点在网络上很多文章分析Activity的启动过程中都会详细描述的，这里不再赘述。ViewRootImpl就代表一个Activity建立能够接收事件的渠道。这个建立过程在ViewRootImpl的setView中。在setView中的代码很多，功能也需要仔细分析，这里仅仅列出和Input相关的代码，如下：

 1     public void setView(View view, WindowManager.LayoutParams attrs, View panelParentView) {
 2         synchronized (this) {
 3             if (mView == null) {
 4                 //如果这个Window的属性中设置了不再需要InputChannel，那么就可以不用创建InputChannel。
 5                 //我们是需要一个InputChannel的。
 6                 if ((mWindowAttributes.inputFeatures
 7                         & WindowManager.LayoutParams.INPUT_FEATURE_NO_INPUT_CHANNEL) == 0) {
 8                     mInputChannel = new InputChannel();
 9                 }
10                 try {
11                     mOrigWindowType = mWindowAttributes.type;
12                     mAttachInfo.mRecomputeGlobalAttributes = true;
13                     collectViewAttributes();
14                     //这里是把InputChannel最终传递到WindowManagerService中，用于传递渠道的建立
15                     res = mWindowSession.addToDisplay(mWindow, mSeq, mWindowAttributes,
16                             getHostVisibility(), mDisplay.getDisplayId(),
17                             mAttachInfo.mContentInsets, mInputChannel);
18                 } 
19                 ...    
20                 //DecorView是RootViewSurfaceTaker的一个实例，
21                 if (view instanceof RootViewSurfaceTaker) {
22                 //虽然这行代码会被执行，但是得到的最终值还是null。在整个代码中，我并没有找到InputQueueCallback对象创建的地方
23                     mInputQueueCallback =
24                         ((RootViewSurfaceTaker)view).willYouTakeTheInputQueue();
25                 }
26                 if (mInputChannel != null) {
27                     if (mInputQueueCallback != null) {
28                         mInputQueue = new InputQueue(mInputChannel);
29                         mInputQueueCallback.onInputQueueCreated(mInputQueue);
30                     } else {
31                         //这里创建了一个WindowInputEventReceiver，注意参数是前面创建的InputChannel和本Activity所在线程的Looper，
32                         mInputEventReceiver = new WindowInputEventReceiver(mInputChannel,
33                                 Looper.myLooper());
34                     }
35                 }
36             ...
37             }
38         }
39     }

这段代码就是我们分析通信机制在应用端建立的轮廓。后面的大部分内容都是基于这段代码分析进行的，只不过是这段代码的层层深入而已。在之前，我们一直没有介绍在事件传递中一个重要的类InputChannel，这里就详细说明下。在Native层的InputChannel就是一个通道，仅仅是一个通道，仅仅具有通信功能，不包含其他的。至于从数据流动方向，与InputChannel无关。数据流向是有InputPublisher和InputConsumer在组合了InputChannel后决定的。先看在代码line 8中，创建一个InputChannel实例，它是一个Java对象，通过它的构造函数可以看出，只是创建了一个对象，并没有进行任何实例化的操作。之后，就是把这个对象作为参数传递到了WindowManagerService中，有addWindow来使用。把InputChannel由应用程序传递到WindowManageService的过程，涉及到的是Binder通信，不是文章的重点，不多说。需要知道的是，mWindowSession.addToDisplay最后会传递到WindowManagerService的addWindow方法。通过代码看看InputChannel是如何使用的，代码如下：

 1 public int addWindow(Session session, IWindow client, int seq,
 2             WindowManager.LayoutParams attrs, int viewVisibility, int displayId,
 3             Rect outContentInsets, InputChannel outInputChannel) {
 4             ...
 5             if (outInputChannel != null && (attrs.inputFeatures
 6                     & WindowManager.LayoutParams.INPUT_FEATURE_NO_INPUT_CHANNEL) == 0) {
 7                     //这个名字是根据对象的hashcode和窗口的一些属性转化为字符串后建立的。
 8                 String name = win.makeInputChannelName();
 9                 InputChannel[] inputChannels = InputChannel.openInputChannelPair(name);            
10                 win.setInputChannel(inputChannels[0])；
11                 inputChannels[1].transferTo(outInputChannel);            
12                 mInputManager.registerInputChannel(win.mInputChannel, win.mInputWindowHandle);
13             }
14             ...
15     }

 

 

 

 

 

 

 

 

 

 

转载于:https://www.cnblogs.com/haiming/p/3318614.html