深入Android S (12.0) 探索Framework之输入子系统InputReader的流程

Framework层之输入系统

第一篇深入Android S (12.0) 探索Framework之输入系统IMS的构成与启动
第二篇深入Android S (12.0) 探索Framework之输入子系统InputReader的流程

文章目录

Framework层之输入系统
前言
一、基础知识
- 1、输入子系统
- 2、INotify 与 Epoll
- - 2.1、INotify 机制
  - 2.2、Epoll 机制
- 3、小结
二、InputReader 的总体流程
- 1、InputReader::loopOnce()
- - 1.1、EventHub::getEvents()
  - - 1.1.1、EventHub::closeAllDevicesLocked()
    - 1.1.2、EventHub::scanDevicesLocked()
    - 1.1.3、EventHub::scanDirLocked()
    - 1.1.4、EventHub::openDeviceLocked()
    - 1.1.5、EventHub::registerDeviceForEpollLocked()
    - 1.1.6、EventHub::addDeviceLocked()
    - 1.1.7、EventHub::readNotifyLocked()
  - 1.2、InputReader::processEventsLocked()
  - - 1.2.1、 InputReader::processEventsForDeviceLocked()
    - 1.2.2、 InputDevice::process()
    - 1.2.3、 InputMapper::process()
    - 1.2.4、 TouchInputMapper::process()
    - 1.2.5、 TouchInputMapper::sync()
    - - 1.2.5.1、 MultiTouchInputMapper::syncTouch()
      - 1.2.5.2、 TouchInputMapper::processRawTouches()
    - 1.2.6、 TouchInputMapper::cookAndDispatch()
    - - 1.2.6.1、TouchInputMapper::cookPointerData()
      - 1.2.6.2、TouchInputMapper::rotateAndScale()
      - 1.2.6.3、TouchInputMapper::dispatchTouches()
    - 1.2.7、TouchInputMapper::dispatchMotion()
    - - 1.2.7.1、InputReader::ContextImpl::getListener()
      - 1.2.7.2、QueueInputListener::notifyMotion()
  - 1.3、QueuedInputListener::flush()
  - - 1.3.1、NotifyMotionArgs::notify()
    - 1.3.2、InputClassifer::notifyMotion()
  - 1.4、InputDispatcher::notifyMotion()
总结

前言

上一篇文章深入探索了 Android Framework 的输入系统 IMS 的构成与启动，对 IMS 的重要成员有了初步的理解，然后通过源码对 IMS 的整个启动流程进行分析，在 IMS 启动并准备就绪后，输入系统就可以从设备节点源源不断的抽取输入事件，并交给事件处理者进行加工处理，即输入子系统 InputReader。本篇将深入探索 InputReader 的工作流程，它是如何从设备节点将输入事件交给 InputDispatcher 的派发队列的？

一、基础知识

1、输入子系统

Android 设备可以同时连接多个输入设备，如：触摸屏、键盘以及鼠标等，用户在任何一个设备上的输入都会对应产生一个中断，经由 Linux 内核的中断处理以及设备驱动转换成一个事件 Event，并传递给用户空间的应用程序进行处理。通过上篇文章的分析我们知道 InputReader 只有一个承载其运行的线程 InputThreadImpl，而每个输入设备都有自己配套的驱动程序，其数据接口也不尽相同，Linux 内核是怎么在一个线程里面把所有的用户输入都给捕获的？这个需要对 Linux 内核的输入子系统 (Input Subsystem) 有所了解，它在各种各样的设备驱动程序上抽象出了一个抽象接口层，只要底层的设备驱动程序按照这层抽象接口来实现，上层应用就可以通过统一的接口来访问所有的输入设备。该抽象层有三个重要的概念：input handler、input handle 和 input_dev，它们的关系如下图：
输入子系统

input_dev：表示底层的驱动；
input_handler：表示某一类输入设备的处理方法，相当于一个上层驱动（注意：一个 input_dev 可以有多个 input_handler，同样，一个 input_handler 可以用于多种输入设备，即多对多的关系）；
input_handle：用于关联某个 input_dev 和某个 input_handler，对应上图中的紫色圆点，每个 input_handle 都会生产一个文件节点，通过 input_handle 可以找到对应的 input_handler 和 input_dev；

通过 Linux 内核的 input system 获取用户输入的流程简述如下：

输入设备通过 input_register_dev 将自己的驱动程序注册到 Input 系统；
各种 Handler 通过 input_register_handler 将自己注册到 Input 系统；
每一个注册进来的 input_dev 或 input_handler 都会通过 input_connect() 函数寻找对方，生成对应的 input_handle，并在路径 dev/input/ 下生成一个设备节点文件；
应用程序通过打开 input_handle 对应的文件节点，打开其对应的 input_dev 和 input_handler。当用户按键/触摸屏幕时，底层驱动就能捕获到并交给对应的上层驱动 Handler 进行处理，然后返回给应用程序；

因此，只要打开 dev/input/ 下的所有 event* 设备文件，就可以获取所有输入设备的输入事件，不管是触摸屏的，还是通过 USB 连接的设备等。

2、INotify 与 Epoll

Reader 子系统是通过读取输入端的设备节点，来获取输入的原始事件，也就是其需要处理输入设备以及原始事件两种类型的对象。设备节点的新建与删除表示输入设备是否可用，设备节点中是否有内容可读表示是否有新的原始事件到来，那么，如何监控设备节点的新建与删除动作？以及如何确定节点中有内容可读呢？最简单的办法是在线程循环中不断地轮询，然而这样的效率非常低，更会导致电量在无谓的轮询中消耗。不过 Android 使用由 Linux 提供的两套机制 INotify 与 Epoll 优雅地解决了这两个问题。

2.1、INotify 机制

INotify 是 Linux 内核所提供的一种文件系统变化通知机制，它可以为应用程序监控文件系统的变化，如文件的新建、删除、读写等。INotify 机制内有两个基本对象，分别为 inotify 对象与 watch 对象，都使用文件描述符表示。

inotify 对象对应一个队列，应用程序可以向 inotify 对象添加多个监听，当被监听的事件发生时，可以通过 read() 函数从 inotify 对象中将事件信息读取出来。

watch 对象则用来描述文件系统的变化事件的监听，它是一个二元组，包括监听目标和事件掩码两个元素。监听目标是文件系统的一个路径，可以是文件也可以是文件夹。事件掩码则表示了需要监听的事件类型，掩码中的每一位代表一种事件。可以监听的事件种类很多，其中就包括文件的创建(IN_CREATE)与删除(IN_DELETE)。

以下代码即可将一个用于监听输入设备节点的创建与删除的 watch 对象添加到 inotify 对象中：

int wd = inotify_add_watch (inotifyFd, “/dev/input”, IN_CREATE | IN_DELETE);

通过 inotify_add_watch() 函数完成 watch 对象的添加后，当 /dev/input/ 下的设备节点发生创建与删除操作时，都会将相应的事件信息写入 inotifyFd 所描述的 inotify 对象中，此时可以通过 read() 函数从 inotifyFd 描述符中将事件信息读取出来。

事件信息使用结构体 inotify_event 来描述：
xref: /bionic/libc/kernel/uapi/linux/inotify.h

struct inotify_event {
	__s32 wd; // 事件对应的 watch 对象的描述符
	__u32 mask; // 事件类型，如文件被删除则此处值为 IN_DELETE
	__u32 cookie; // 缓存
	__u32 len; // name 字段的长度
	char name[0]; // 可变长的字段，用于存储产生此事件的文件路径
};

当监听事件发生时，可以通过 read() 函数将一个或多个未读取的事件信息读取出来：

int res = read(mINotifyFd, event_buf, sizeof(event_buf));

其中 events_buf 是 inotify_event 的数组指针，能够读取的事件数量取决于数组的长度。成功读取事件信息后，便可根据 inotify_event 结构体的字段判断事件类型以及产生事件的文件路径。

总结 INotify 机制的使用过程：

通过 inotify_init() 函数创建一个 inotify 对象；
通过 inotify_add_watch() 函数将一个或多个监听添加到 inotify 对象中；
通过 read() 函数从 inotify 对象中读取监听事件。当没有新事件发生时，inotify 对象中无任何可读数据。

通过 INotify 机制避免了轮询文件系统的问题，但还有一个问题需解决，INotify 机制并不是通过回调的方式通知事件，而需要使用者主动从 INotify 对象中进行事件读取。那么何时才是读取的最佳时机呢？这需要借助 Linux 内核的 Epoll 机制。

2.2、Epoll 机制

无论是从设备节点中获取原始输入事件还是从 inotify 对象中读取文件系统事件，这些事件都是偶发的。也就是说，大部分情况下设备节点、inotify 对象这些文件描述符中都是无数据可读的，同时又希望有事件到来时可以尽快地对事件做出反应。

Linux 内核的 Epoll 机制可以很好的解决该问题，Epoll 可以使用一次等待监听多个描述符的可读/可写状态。等到返回时携带了可读的描述符或自定义的数据，使用者据此读取所需的数据后可以再次进入等待。不需要为每个描述符创建独立的线程进行阻塞读取，避免了系统资源浪费的同时又可以获得较快的响应速度。

Epoll 机制的接口只有三个函数，如下：

epoll_create (int max_fds) : 创建一个 epoll 对象的描述符，之后对 epoll 的操作均使用这个描述符完成。max_fds 参数表示此 epoll 对象可以监听的描述符的最大数量；
epoll_ctl (int epfd，int op，int fd，struct epoll_event* event) : 用于管理注册事件的函数，该函数可以增加/删除/修改事件的注册；
int epoll_wait (int epfd，struct epoll_event*events，int maxevents，int timeout) : 用于等待事件到来。当该函数返回时，events 数组参数中将会包含产生事件的文件描述符。

EventHub 是 InputReader 用于打开和关闭 input 设备节点，监听和读取 input 事件的对象，接下来以 EventHub 的构造函数为例来分析 Epoll 的用法，其代码如下：
xref: /frameworks/native/services/inputflinger/reader/EventHub.cpp

EventHub::EventHub(void)
      : mBuiltInKeyboardId(NO_BUILT_IN_KEYBOARD),
        mNextDeviceId(1),
        mControllerNumbers(),
        mOpeningDevices(nullptr),
        mClosingDevices(nullptr),
        mNeedToSendFinishedDeviceScan(false),
        mNeedToReopenDevices(false),
        mNeedToScanDevices(true),
        mPendingEventCount(0),
        mPendingEventIndex(0),
        mPendingINotify(false) {
    ensureProcessCanBlockSuspend();
	// 创建 Epoll 对象的描述符，监听设备节点是否有数据可读(有无事件发生)
    mEpollFd = epoll_create1(EPOLL_CLOEXEC);
    LOG_ALWAYS_FATAL_IF(mEpollFd < 0, "Could not create epoll instance: %s", strerror(errno));
	// 创建 INotify 对象，用于监听设备节点的路径 /dev/input 是否有变化，如有设备增删则对应的设备节点的文件也会增删
    mINotifyFd = inotify_init();
    // 添加 watch 监听存储设备节点的路径 DEVICE_PATH 的创建与删除，当有设备节点发生变化时，通过 INotify 对象可以读取事件的详细信息
    mInputWd = inotify_add_watch(mINotifyFd, DEVICE_PATH, IN_DELETE | IN_CREATE);
    LOG_ALWAYS_FATAL_IF(mInputWd < 0, "Could not register INotify for %s: %s", DEVICE_PATH,
            			strerror(errno));
    if (isV4lScanningEnabled()) {
        mVideoWd = inotify_add_watch(mINotifyFd, VIDEO_DEVICE_PATH, IN_DELETE | IN_CREATE);
        LOG_ALWAYS_FATAL_IF(mVideoWd < 0, "Could not register INotify for %s: %s",
                    		VIDEO_DEVICE_PATH, strerror(errno));
    } else {
        mVideoWd = -1;
        ALOGI("Video device scanning disabled");
    }
    // 构建 epoll_event 结构体，并为每一个需要监控的描述符填充该结构体，以描述监控事件
    struct epoll_event eventItem = {};
    eventItem.events = EPOLLIN | EPOLLWAKEUP; // 事件掩码，指明需要监听的事件类型，可读
    eventItem.data.fd = mINotifyFd; // 数据字段，设置需要监听的描述符，这里是 mINotifyFd，即监听设备节点的路径
    // 调用 epoll_ctl() 函数将 INotify 对象注册到 Epoll 中，监听其文件描述符对应的文件夹下是否有设备节点的增删信息
    // 第一个参数即前面创建的 Epoll 对象的描述符，第二个参数表示具体操作，这里 ADD 表示增加注册事件
    // 第三个参数表示需要监听的描述符，第四个参数是描述监听事件的详细信息的 epoll_event 结构体
    int result = epoll_ctl(mEpollFd, EPOLL_CTL_ADD, mINotifyFd, &eventItem);
    LOG_ALWAYS_FATAL_IF(result != 0, "Could not add INotify to epoll instance.  errno=%d", errno);
	// 创建匿名管道 wakeFds，并将读端交给 Epoll，写端交给 InputReader，用于唤醒 Epoll，避免其阻塞在 epoll_wait()
    int wakeFds[ 2];
    result = pipe(wakeFds);
    LOG_ALWAYS_FATAL_IF(result != 0, "Could not create wake pipe.  errno=%d", errno);
	// mWakeReaderFD 和 mWakeWriterFD 对应管道的两端
    mWakeReadPipeFd = wakeFds[0];
    mWakeWritePipeFd = wakeFds[1];

    result = fcntl(mWakeReadPipeFd, F_SETFL, O_NONBLOCK);
    LOG_ALWAYS_FATAL_IF(result != 0, "Could not make wake read pipe non-blocking.  errno=%d", errno);
    result = fcntl(mWakeWritePipeFd, F_SETFL, O_NONBLOCK);
    LOG_ALWAYS_FATAL_IF(result != 0, "Could not make wake write pipe non-blocking.  errno=%d", errno);

    eventItem.data.fd = mWakeReadPipeFd;
    // epoll_ctl() 函数可重复调用，将多个文件描述符的多种事件监听注册到 Epoll 对象中
    // 将匿名管道的读取端的描述符也注册到 Epoll 中，用于监听读取端的可读事件，当写入端有任意数据写入时
    // 管道的读取端就有数据可读，使得 epoll_wait() 得以返回，从而达到唤醒 InputReader 线程的目的，避免其一直阻塞
	result = epoll_ctl(mEpollFd, EPOLL_CTL_ADD, mWakeReadPipeFd, & eventItem);
	LOG_ALWAYS_FATAL_IF(result != 0, "Could not add wake read pipe to epoll instance.  errno=%d", errno);
}

Epoll 的具体用法，在 EventHub 的构造函数中都已注释，代码中 epoll_event 结构体的定义如下：
xref: /bionic/libc/include/bits/epoll_event.h

// epoll_event 的可能数据类型的并集
typedef union epoll_data {
	void* ptr;
	int fd;
	uint32_t u32;
	uint64_t u64;
} epoll_data_t; // 同一时间使用者只能使用其中一个字段
// 表示epoll()事件的类型
struct epoll_event {
	// 事件掩码，指明需要监听的事件种类，掩码的每一位代表了一种事件
	// 常用的事件有 EPOLLIN(可读)、EPOLLOUT(可写)、EPOLLERR(描述符发生错误)、EPOLLHUP(描述符被挂起)等
	uint32_t events;
	epoll_data_t data; // 可自定义的数据，当此事件发生时该数据降原封不动地返回给使用者
}

events：表示事件掩码，指明需要监听的事件种类，掩码的每一位代表了一种事件，常用的事件有 EPOLLIN(可读)、EPOLLOUT(可写)、EPOLLERR(描述符发生错误)、EPOLLHUP(描述符被挂起) 等。
data：是一个数据集，使用者可以将一些自定义数据加入事件通知中，当此事件发生时，用户设置的 data 字段将会返回给使用者。在 EventHub 的构造函数中，将 epoll_event.data.fd 设置为 mINotifyFd，也即需要监听的文件描述符，事件发生时便可据此得知引发事件的描述符。当然也可以设置 epoll_event.data.fd 为其他便于识别的数据。

最后，在监听注册完后，可以通过 epoll_wait() 函数等待事件到来，该函数将会使调用者陷入等待状态，直到其注册的事件之一发生之后才会返回，并且携带刚刚发生的事件的详细信息。epoll_wait() 函数的声明如下：

int epoll_wait(int epfd, struct epoll_event * events, int maxevents, int timeout);

epfd：是由 epoll_create() 函数创建的 Epoll 对象描述符；
events：是 epoll_event 数组，当函数返回时，事件的信息将被填充至此；
maxevents：表示此次调用最多可以获取的事件数，当然 events 参数须能够容纳这么多的事件；
timeout：表示等待超时的时间。

epoll_wait() 函数的返回值表示获取了多少个事件，待 epoll_wait() 函数返回后，便可以根据 events 数组中所保存的所有 epoll_event 结构体的 events 字段与 data 字段识别事件的类型与来源。

Epoll 的使用步骤总结如下：

通过 epoll_create() 函数创建一个 epoll 对象的描述符；
构建 epoll_event 结构体，并为每一个需要监控的描述符填充该结构体，以描述监控事件；
调用 epoll_ctl() 函数将 INotify 对象注册到 Epoll 中监听其文件描述符是否有新的可读事件到来；
使用 epoll_wait() 函数等待事件发生，并根据 epoll_wait() 函数返回的 epoll_event 结构体数组判断事件的类型与来源并进行处理；
继续使用 epoll_wait() 函数等待新事件发生。

3、小结

本节主要是跟输入子系统相关的知识，这些是 Reader 子系统运行的基石，有助于我们后续对 Reader 子系统的流程分析，那么接下来就正式开始分析 Reader 子系统的工作流程。

二、InputReader 的总体流程

在深入Android S (12.0) 探索Framework之输入系统IMS的构成与启动一文中分析过，InputReader 启动后创建 InputThreadImpl 线程并启动线程循环，InputThreadImpl 继承自 C++ 的 Thread 类，C++ 的 Thread 类提供了一个纯虚函数 threadLoop()，当线程开始运行后，将会在内建的线程循环中不断地调用该函数，在 threadLoop() 函数内又会调用一次 mThreadLoop() 函数，而 mThreadLoop() 函数是由 InputReader 在启动时封装好传入的可调用函数对象 (是一个 Lambda 表达式)，就是 InputReader::loopOnce() 函数，那跟进该函数看一下 InputReader 在一次线程循环中具体做了什么？

1、InputReader::loopOnce()

xref: /frameworks/native/services/inputflinger/reader/InputReader.cpp

void InputReader::loopOnce() {
    int32_t oldGeneration;
    int32_t timeoutMillis;
    bool inputDevicesChanged = false;
    std::vector < InputDeviceInfo > inputDevices;
    ......
    // 通过 EventHub 获取事件列表，读取事件后存储在参数 mEventBuffer 中，返回值表示事件的个数
    // 当 EventHub 中无新事件可读取，此函数的调用将会阻塞直到新事件到来或超时
    size_t count = mEventHub -> getEvents(timeoutMillis, mEventBuffer, EVENT_BUFFER_SIZE);

    { // acquire lock 获取锁
        std::scoped_lock _l(mLock);
        mReaderIsAliveCondition.notify_all();
        if (count) { // 如果获取到事件，则调用 processEventsLocked() 函数对事件进行加工处理
            processEventsLocked(mEventBuffer, count);
        }
        if (mNextTimeout != LLONG_MAX) {
            nsecs_t now = systemTime(SYSTEM_TIME_MONOTONIC);
            if (now >= mNextTimeout) {
                mNextTimeout = LLONG_MAX;
                timeoutExpiredLocked(now);
            }
        }
        if (oldGeneration != mGeneration) {
            inputDevicesChanged = true;
            inputDevices = getInputDevicesLocked();
        }
    } // release lock

    // 发送消息，通知输入设备已更改
    if (inputDevicesChanged) {
        mPolicy -> notifyInputDevicesChanged(inputDevices);
    }
	// processEventsLocked() 函数加工处理后的事件，存储在 mQueuedListener 中，每次的循环结束时
	// 调用其 flush() 函数将所有事件交付给 InputDispatcher
    mQueuedListener -> flush();
}

InputReader 的一次线程循环的流程如下：

调用 EventHub::getEvents() 函数获取事件列表，这些事件分为两类：一种是从设备节点中读取的原始输入事件，另一种则是输入设备可用性变化事件，简称设备事件；
调用 InputReader::processEventsLocked() 函数对获取事件进行处理，对于设备节点事件，将根据设备的可用性来加载或移除设备对应的配置信息。对于原始输入事件，则进行转译、封装与加工后将结果暂存到 mQueuedListener 中；
最后调用 QueuedInputListener::flush() 函数将所有暂存且已加工处理过的输入事件交付给 InputDispatcher 来进行分发。

接下来将深入探索这几步的具体流程，首先是通过 EventHub::getEvents() 函数获取事件。