学习笔记-说说 InputManagerService 相关内容

本博客在 https://wkmcyz.notion.site/InputManagerService-616004c0a3fa4324b952f7e8563a010f 可以获得更好的阅读体验。

学习笔记-说说 InputManagerService 相关内容

Android 的触摸事件，可以分为三部分。

第一部分是硬件部分，检测触摸事件，这一步需要传感器之类的组件来完成。这部分主要是硬件相关的知识。

第二部分是操作系统部分， 将触摸事件传递给应该接受它的目标应用。本篇后面会说的 InputManagerService 的相关内容就是解释这部分的流程的。

第三部分是控件级别（即各个 View 类）的处理，来消化该触摸事件。这是 Android 应用的 view 触摸事件处理，不在此讨论

InputManagerService 的简单介绍

InputManagerService 是 Android 的一个系统服务，运行在 system_server 进程中，和 WMS 一起配合维护着 Android 的输入事件的管理，也就是上面提到的 “操作系统处理” 的部分。

想象一下，这样一个传递触摸事件的管理者需要进行哪些操作。主要应该分为三步，第一是从硬件部分接收事件；第二是进行一些自己的处理；第三是将这部分事件传递给其对应的进程以及对应的控件。我们也主要对这三步进行说明。

第一步：从设备读取原始的输入事件

Android 设备在发生输入事件的时候，会将触摸事件写入一个文件，InputManagerService 依赖 epoll 机制从该文件读取触摸事件的信息，读取到的便是原始的输入事件。这就是最初 InputManagerService 的输入。

💡 Epoll 的简介

epoll 是 linux 系统的机制，是由操作系统来实现的一个关于文件的监听者系统。进程可以使用这个机制将自己注册到操作系统上，在某些事件发生的时候收到回调。配合 INotify 机制可以用来监听文件内容的变化和文件状态的变化，例如文件可读、文件内容有修改等。

epoll 分为三个 api 方法：epoll_create ， epoll_ctl，epoll_wait ，分别是 epoll_create 用来获得一个 epoll 使用的令牌对象；epoll_ctl 用来将部分要监听的操作注册到操作系统上；epoll_wait 会使线程进入等待状态，等待相应操作发生的时候，被操作系统唤起。

💡 IMS 如何读取原始事件？ IMS 中有专门的类负责从 **/dev/input** 读取输入信息，并且包装成 IMS 内部的触摸事件封装对象。该类叫做 EventHub 。 EventHub 会使用 INotify 和 Epoll 机制来监听操作系统提供的输入事件，这些事件通常在文件里，包括输入设备以及设备的输入内容。输入设备指的是触屏、连接键盘等设备，这些设备的输入会映射成操作系统的按键事件，加入到设备输入文件里（/dev/input）。并且在有输入设备新挂载或者被移除掉的时候，维护 IMS 里的输入设备信息。

第二步：IMS 对输入事件进行处理

IMS 会执行一个中间者的职责，将原始输入信息转化成应用希望得到的方便好用的信息——也就是 Android 系统提供的输入事件类型。上面提到 IMS 接受设备给出的原始输入信息，其中设备会有很多不同的种类，例如外接的键盘、外接的鼠标、手柄以及触摸屏幕等。

这些不同的输入设备会将不同的操作映射为自己独特的事件 id，例如按下键盘的某个按键会被记录为一次 id 为 1 的事件，或者鼠标左键回应设为 id 为 1 的事件等。IMS 接收到以后，该怎么样不同的 id 映射为指定的事件呢？这是根据输入设备的类型来决定的。所以这里 IMS 会先根据输入设备的类型获得一个对应表，也就是一个 Map。其负责将将读入的原始输入信息进行映射处理，这可以认为是一次“解码”。

💡 IMS 是如何给输入设备分配对应表的？ IMS 给输入设备分配对应的表的方法，有一个很好的设计。这些表是<设备输入事件扫描码，Android 规定的虚拟按键> 的映射关系表。并且1）设计成了多个表，有键盘的输入表、鼠标的输入表、手柄的输入表等。2）对于一个设备，可能有多种输入功能（例如带触摸板功能的键盘），这时候 IMS 会给其分配多个不同的表，用来将该设备的原始输入映射成Android 可以理解的输入。 这些功能表都叫做 InputMapper，按照功能不同有多种实际的实现类，例如用来处理键盘输入的 KeyboardInputMapper 、用来处理光标输入的 CursorInputMapper 、用来处理触摸输入的 SingleTouchInputMapper 以及 MultiTouchInputMapper 等。

💡 InputMapper 的特点 InputMapper 有多种，比如用于键盘输入处理的、用于鼠标输入处理的、用于触摸输入处理的。其中同样的 InputMapper 对于不同的设备也可能有不同的处理。InputMapper 会根据输入设备的实际信息（例如键盘种类、生产商家；或者是触摸板的分辨率；或者是手柄的型号）加载不同的配置文件，依据此信息进行输入事件的处理。 而且 InputManager 在将原始输入事件转成实际的 Android 事件的时候，也不一定是一对一的，可能会将一个原始输入事件对应成多个连续的 Android 事件，比如鼠标点击会对应成 ACTION_DOWN 和 ACTION_UP；也可能将多个连续的原始输入事件对应成一个 Android 的事件。 这些特点共同完成了一个高扩展性的输入-解码系统。

💡 屏幕触摸事件的处理 Android 系统中最重要的事件处理就是屏幕触摸事件了。屏幕触摸事件在 IMS 里是交由 SingleTouchInputMapper 和 MultiTouchInputMapper 合力完成的。其接受的原始输入事件是一个当前触摸点信息的数组，其中每个触摸点的坐标、压力信息等。相应的处理触摸事件的 InputMapper 会根据每次获取到的原始数据信息进行处理，生成 ACTION_MOVE 、ACTION_DOWN 等事件。例如通过比对新的和之前的触摸点信息，可以判断出是否有触摸点是新出现的，是否有触摸点离开了屏幕，以及是否有触摸点发生了移动。 并且这部分的 InputMapper 还需要处理其接受到的原始信息才行，这部分处理包括根据设备的分辨率转换成屏幕的分辨率（设备的分辨率即触摸板的触摸分辨率）、根据当前屏幕的方向进行映射转换，等。

第三步：IMS 进行输入事件的分发

第二步的处理会将原始输入事件转变成 Android 框架提供的事件类型进行分发，这些事件类型包括 1） Key 事件 ，2）Motion 事件。分发的过程涉及到了当前输入事件的接受者的寻找，因此这部分是需要和 WMS 互相配合以实现该判断的。

WMS 会在管理的窗口布局发生变化的时候，将新的窗口信息都通知给 IMS，这包括每个窗口的位置、宽高、zOrder 、窗口的 flag 等信息，还有焦点窗口等信息，以供 IMS 为输入事件选择目标。

IMS 的分发相关的处理，简单描述如下：

其中分发步骤会有很多处理，会根据 IMS 服务所处的状态决定处理逻辑，这包括在系统休眠的时候或者设备正在旋转的时候，这时候的输入事件会被缓存下来或者丢弃掉。
IMS 会根据当前系统的窗口布局情况以及输入事件的属性选择适合的窗口来处理输入事件。比如有一些特定属性的输入事件不会交给用户进程处理；也可能会因为一些原因将输入事件丢弃。
IMS 在为输入事件选择好目标对象——也就是接受输入事件的窗口——的时候，会判断目标是否可以接收输入事件，如果可以的话，将事件发送给目标。如果目标无法接收的话，会先将输入事件缓存起来，在其可以接受的时候重新发送，或者是在 5s 之后上报 ANR。

💡 IMS 里的一个生产者-消费者的优化 上面第二步里提到的处理原始事件，会将处理后的事件交给 IMS 的 InputDispatcher 进行分发。InputDispatcher 是实际负责分发功能的实现类，其运行在一个独立的线程，默认出于等待状态，等到接收到分发的申请的时候就会进行分发工作。这里其实是一个生产者-消费者的模型。 处理各个 InputMapper 处理过的待分发的事件并不会直接交给 InputDispatcher 来处理，而是会先放入一个缓冲池，在特定的时机统一交给 InputDispatcher，这种缓存然后统一处理，可以大大减少 InputDispatcher 工作线程被唤起的次数，同时对实际效果几乎没有影响，因此是很好的一个优化措施。

💡 IMS 在分发事件的时候模拟重复按键 Android 的输入设备中，有一些设备输入的事件是可重复的，例如按下一个键不放的时候，会不断产生 KEY_DOWN 事件。但是有一些设备是不支持重复发送的，即按住不放的时候，也只会在按键按下的那次发送 KEY_DOWN 事件，后续并不会有事件被发送出，只会在按键抬起的时候发送一个 KEY_UP 事件。所以 IMS 提供了模拟重复发送的功能，如果某个 KEY_DOWN 输入事件是允许 IMS 进行重复发送的话，IMS 会对该事件进行重复发送，即在一定时间后 IMS 自动模拟接收到新的该 KEY_DOWN 事件并且进行分发。

💡 IMS 对输入事件的分发策略 IMS 在将原始输入事件处理成输入事件之后、分发输入事件到执行目标之前，会提供专门的接口能力对输入事件进行处理和过滤，这里的处理包括了缓存下来本次事件并且在一定时间范围内等待后面的输入事件、询问一些应用是否需要消化本次事件，等。

💡 IMS 发送事件给目标窗口的方式 IMS 运行在 system_server 进程，目标窗口通常运行在应用进程，这里的输入事件通知是跨进程的通信。IMS 这里使用的是名为 InputChannel 的方式，其是对于 socket 的封装，提供了本机上两个进程之间的收发信息的能力。 InputChannel ， 这个跨进程的通信通道是在 window 被添加到 WMS 的时候，由 WMS 生成的，其中的一端发送给 window 进程里的 window，另一端保存到 WMS，并且会告知给 IMS 。IMS 获取之后便会将其封装为适合自己使用的信息通道对象。 IMS 发送事件的时候，将事件发送出去后会将事件放入一个 waiting 的队列中，在通过InputChannel 获得目标窗口的回应之后，会将对应的事件从 waiting 队列里移除，这边表示本事件的分派结束。

相关类的对应关系

IMS 从操作系统读取原始输入事件 ：

• EventHub

IMS 将原始输入事件转成 Android 系统的输入事件 ：

• InputReader
• InputMapper
• mapper 包 ， 其中包含了很多种类的 mapper，例如键盘输入事件的 mapper、鼠标输入事件的 mapper。

IMS 将输入事件分派给指定窗口 ：

• InputDispatcher
• NativeInputManager

IMS 将输入事件传输给指定窗口 ：

• InputChannel ，类似 Binder 用来做跨进程通信的类，基于 socket 实现。
• Connection , IMS 服务内部对 InputChannel 的封装，包括对该通道的待发布事件的缓存等。
• InputMessage，IMS 发送的事件的数据封装。
• InputPublisher，Connection 内部对 InputChannel 的封装。

窗口接收输入事件：

• InputEventReceiver，接受输入事件的入口，并且负责给 IMS 接受消息的确认。