【Android】事件处理系统

时间:2023-02-08 16:40:29

linux输入子系统

  Android是linux内核的,所以它的事件处理系统也在linux的基础上完成的。

  Linux内核提供了一个Input子系统来实现的,Input子系统会在/dev/input/路径下创建我们硬件输入设备的节点,一般情况下在我们的手机中这些节点是以eventX来命名的,如event0,event1等等,但是如果是虚拟机的话,我们可以看到一个mice,这个mice代表鼠标设备,这是由于PC需要使用鼠标来模拟触屏。

  由于这些设备节点是硬件相关的,所以每款设备都是不尽相同的。

  看到了这些输入的设备节点,我们可能比较困惑这些eventX到底代表什么含义呢,也就是说到底是什么样的设备创建了这个节点呢?

  我们可以从/proc/bus/input/devices中读出eventX相关的硬件设备,具体的就不多说了,我们知道android读取事件信息就是从/dev/input/目录下的设备节点中读取出来的,算是android事件处理的起源。

Android事件传递

  Android事件传递的流程,按键,触屏等事件是经由WindowManagerService获取,并通过共享内存和管道的方式传递给ViewRoot,ViewRoot再dispatch给Application的View。当有事件从硬件设备输入时,system_server端在检测到事件发生时,通过管道(pipe)通知ViewRoot事件发生,此时ViewRoot再去的内存中读取这个事件信息。

至于android在事件处理上为什么使用共享内存而不是直接使用Binder机制,猜测应该是google为了保证事件响应的实时性,因此在选择进程间传递事件的方式中,选择了高的共享内存的方式,由于共享内存在数据管理过程中基本不涉及到内存的数据拷贝,只是在进程读写时涉及到2次数据拷贝,这个是不可避免的数据拷贝,因此这种方式能够很好的保证系统对事件的响应,但是仅仅是共享内存是不够的,因为共享内存的通信方式并不能够通知对方有数据更新,因此android在事件处理过程中加入了另一种进程间通信方式管道(pipe),管道的效率不如共享内存高,会不会影响事件处理的实时性?没关系,每次system_serve通知ViewRoot只是向其传递一个字符,即轻巧又简单。

了解了一些基本知识后,现在从底层往上层来分析事件的传递过程。

  首先列出整个事件处理的结构图

  【Android】事件处理系统

事件处理系统的初始化过程

  Android事件传递系统是以共享内存和管道的进程间通信方式来实现传递的,为了便于理解它的传递机制,事件传递系统的初始化工作的理解则会显得非常的重要。

创建管道连接

  件传递系统中的管道的主要作用是在有事件被存储到共享内存中时,system_server端通知ViewRoot去读取事件的通信机制。

  既然是ViewRoot和system_server之间建立管道通信,那么ViewRoot和WindowManagerService(负责事件传递,运行在system_server进程中)各需维护管道的一个文件描述符,其实ViewRoot和WindowManagerService不是各维护了一个管道的文件描述符,而是两个,当然了这两个描述符不属于同一管道,实际上也就是ViewRoot和WindowManagerService之间实现了全双工的管道通信。

  1. WindowManagerService--->ViewRoot方向的管道通信,表示WMS通知ViewRoot有新事件被写入到共享内存;
  2. ViewRoot-->WindowManagerService方向的管道通信,表示ViewRoot已经消化完共享内存中的新事件,特此通知WMS。

  ViewRoot和WindowManagerService的管道的文件描述符都是被存储在一个名为InputChannel的类中,这个InputChannel类是管道通信的载体。

  ViewRoot端的管道的建立

//setView()@ViewRoot.java

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

  在ViewRoot和WMS(WindowManagerService)建立起连接之前首先会创建一个InputChannel对象,同样的WMS端也会创建一个InputChannel对象,不过WMS的创建过程是在ViewRoot调用add()方法时调用的。InputChannel的构造不做任何操作,所以在ViewRoot中创建InputChannel时尚未初始化,它的初始化过程是在调用WMS方法add()时进行的,看到上面代码中将mInputChannel作为参数传递给WMS,目的就是为了初始化。

  下面转到WMS代码看看InputChannel的初始化过程

//addWindow()@WindowManagerService.java

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为ViewRoot传递来的InputChannel对象,上述代码主要工作其实就是创建一对InputChannel,这一对InputChannel中实现了一组全双工管道。

  在创建InputChannel对的同时,会申请共享内存,并向2个InputChannel对象中各自保存一个共享内存的文件描述符。

  InputChannel创建完成后,会将其中一个的native InputChannel 赋值给outInputChannel,也就是对ViewRoot端InputChannel对象的初始化,这样随着ViewRoot和WMS两端的InputChannel对象的创建,事件传输系统的管道通信也就建立了起来。

创建InputChannel pair的过程以及管道建立,共享内存申请的过程就不再列出它的代码了,请参考openInputChannelPair()@InputTransport.cpp。

  下图为ViewRoot和WMS两端创建InputChannel pair之后的结构

  【Android】事件处理系统

InputChannel的注册过程

  上面介绍了InputChannel对象的创建过程,这个过程将管道通信建立了起来,但是我们需要清楚的一点是,一个管道通信只是对应一个Activity的事件处理,也就是当前系统中有多少个Activity就会有多少个全双工管道,那么系统需要一个管理者来管理以及调度每一个管道通信,因此我们在创建完InputChannel对象后,需要将其注册到这个管理者中去。

  明白了InputChannel对象需要注册的原因之后,再看ViewRoot和WMS端的InputChannel对象各自需要注册到哪里?

  其实也很好理解,两个InputChannel对象WMS端的是管道通信的sender, ViewRoot端的是Receiver(尽管创建的全双工,但是目前只使用到了它的一向的通信,另一方向的通信尚未使用),那么着两个InputChannel对象肯定需要被两个不同的管理者来管理。

  ViewRoot端的一般情况下会注册到一个NativeInputQueue对象中;WMS端注册在InputManager对象中。其实从NativeInputQueue和InputManager的名字中也就能知道各自的功能了。

注册到NativeInputQueue

  ViewRoot端InputChannel对象在向NativeInputQueue注册时,需要注册3个参数:

  1. 将InputChannel对象对应的Native InputChannel传递给NativeInputQueue
  2. 将ViewRoot的成员变量InputHandler传递给NativeInputQueue,这个InputHandler则是事件的处理函数,传递它的作用主要是明确当前ViewRoot的事件处理函数;
  3. 还有一个很重要的参数需要传递给NativeInputQueue,那就是当前Application的主进程的MessageQueue

  Android在实现事件传输时,很大程度上借用了线程Looper和MessageQueue的轮询(poll)机制,通过它的轮询机制来检测管道上是否有消息通知事件发生,借用Looper机制能够很大限度的保证事件能够第一时间被Application知晓。

  在注册过程中,android会将InputChannel对象中保存的管道的文件描述符交给MessageQueue的native looper去监听,同时向native looper指示一个回调函数,一旦有事件发生,native looper就会检测到管道上的数据,同时会去调用指示的回调函数。这个回调函数为handleReceiveCallback()@android_view_InputQueue.cpp.

  当然了,NativeInputQueue对象,整个系统中只有一个,它为了负责管理这么多的Application的事件传递,android在NativeInputQueue类中定义了一个子类Connection,每个InputChannel对象在注册时都会创建一个自己的Connection对象。

  【Android】事件处理系统

  这一块的代码在registerInputChannel()@android_view_InputQueue.cpp

注册到InputManager

  由于WMS端的对linux Input 系统的检测和ViewRoot对管道接收端的检测机制不同,ViewRoot端很好的复用了Application 主线程的Looper轮询机制来实现对事件响应的实时性,而WMS尽管也有自己的Looper,WMS却没像ViewRoot一样复用自己的Looper机制,至于原因android的code上没有明确说明,猜测应该是WMS是整个系统的,不像ViewRoot一样每个Activity都有一套,为了不影响系统的整体性能,尽量不要去影响WMS。

  不采用Looper来轮询是否有事件发生,InputManager启动了2个进程来管理事件发生与传递,InputReaderThread和InputDispatcherThread,InputReaderThread进程负责轮询事件发生; InputDispatcherThread负责dispatch事件。

  为什么需要2个进程来管理,用一个会出现什么问题?很明显,如果用一个话,在轮询input系统event的时间间隔会变长,有可能丢失事件。

  虽然没有使用Looper来轮询事件的发生,但是InputDispatcher使用了native looper来轮询检查管道通信,这个管道通信表示InputQueue是否消化完成dispatch过去的事件。

  注意的是这个native looper并不是WMS线程的,而是线程InputDispatcher自定定义的,因此所有的轮询过程,需要InputDispatcher主动去调用,如

mLooper->pollOnce(timeoutMillis);或者mLooper->wake();。而不像NativeInputQueue一样,完全不用操心对looper的操作。

  WMS在初始化时会创建这么一个InputManager实例,当然了,它也是系统唯一的

  JAVA层的InputManager实例并没有实现太多的业务,真正实现Input Manager业务是Native的NativeInputManager实例,它在被创建时,建立起了整个WMS端事件传递系统的静态逻辑。

  整个WMS端事件传递系统的静态逻辑:

  【Android】事件处理系统

  NativeInputManager的整个业务的核心其实是InputReader和InputDispatcher两个模块,下面简单介绍一下这两个模块。

InputReader

  InputReader从名称就可以看出主要任务是读事件,基本上它所有的业务都包含在了process()的函数中

void InputReader::process(const RawEvent* rawEvent) {
switch (rawEvent->type) {
case EventHubInterface::DEVICE_ADDED:
addDevice(rawEvent->deviceId);
break; case EventHubInterface::DEVICE_REMOVED:
removeDevice(rawEvent->deviceId);
break; case EventHubInterface::FINISHED_DEVICE_SCAN:
handleConfigurationChanged(rawEvent->when);
break; default:
consumeEvent(rawEvent);
break;
}
}

  process()函数的输入参数时EventHub模块提供的,

  1. 当EventHub尚未打开input系统eventX设备时,InputReader去向EventHub获取事件时,EventHub会首先去打开所有的设备,并将每个设备信息以RawEvent的形式返给InputReader,也就是process()中处理的EventHubInterface::DEVICE_ADDED类型,该过程会根据每个设备的deviceId去创建InputDevice,并根据设备的classes来创建对应的InputMapper。如上图所示。
  2. 当所有的设备均被打开之后,InputReader去向EventHub获取事件时,EventHub回去轮询event节点,如果有事件,InputReader则会消化该事件consumeEvent(rawEvent);

InputDispatcher

  数据传输管理的核心业务是在InputDispatcher中完成的,因此最终WMS端InputChannel对象会注册到InputDispatcher中,同样的由于整个系统中InputDispatcher实例只有一个,而WMS端InputChannel对象是和ViewRoot一一对应的。因此InputDispatcher类中也定义了一个内部类Connect来管理各自的InputChannel对象。不同于NativeInputQueue类中的Connect类,InputDispatcher中的Connect类的核心业务是由InputPublisher对象来实现的,该对象负责将发生的事件信息写入到共享内存。
  相关代码在registerInputChannel()@InputDispatcher.cpp


事件传递

  经过分析事件处理系统的初始化过程之后,我们已经对事件处理系统的整体架构有了一定程度的理解,那么下面看看事件传递过程

InputReaderThread线程操作

  当input系统有事件发生时,会被InputReaderThread线程轮询到,InputReader会根据事件的device id来选择的InputDevice,然后再根据事件的类型来选择InputDevice中的InputMapper,InputMapper会将事件信息通知给InputDispatcher;

  目前adroid在InputReader中实现了5种设备类型的InputMapper,分别为滑盖/翻盖SwitchInputMapper、键盘KeyboardInputMapper、轨迹球TrackballInputMapper、多点触屏MultiTouchInputMapper以及单点触屏SingleTouchInputMapper。

设备类型

InputManager

EventType

Notify InputDispatcher

滑盖/翻盖

SwitchInputMapper

EV_SW

notifySwitch()

键盘

KeyboardInputMapper

EV_KEY

notifyKey()

轨迹球

TrackballInputMapper

EV_KEY, EV_REL,

EV_SYN

notifyMotion()

单点触屏

SingleTouchInputMapper

EV_KEY, EV_ABS,

EV_SYN

notifyMotion()

多点触屏

MultiTouchInputMapper

EV_ABS,

EV_SYN

notifyMotion()

  其中事件类型代表:

  1. EV_REL为事件相对坐标
  2. EV_ABS为绝对坐标
  3. EV_SYN表示Motion的一系列动作结束。

  Notify InputDispatcher表示不同的事件通知InputDispatcher的函数调用,这几个函数虽然是被InputReaderThread调用的,单却是在InputDispatcher定义的。

  【Android】事件处理系统

InputDispatcherThread线程操作

  InputDispatcherThread线程的轮询过程dispatchOnce()-->dispatchOnceInnerLocked()。

  InputDispatcherThread线程不停的执行该操作,以达到轮询的目的,重点也就是这2个函数处理了。

InputDispatcherThread基本流程

  InputDispatcherThread的主要操作是分两块同时进行的,

  一部分是对InputReader传递过来的事件进行dispatch前处理,比如确定focus window,特殊按键处理如HOME/ENDCALL等,在预处理完成 后,InputDispatcher会将事件存储到对应的focus window的outBoundQueue,这个outBoundQueue队列是InputDispatcher::Connection的成员函数,因此它是和ViewRoot相关的。

  一部分是对looper的轮询,这个轮询过程是检查NativeInputQueue是否处理完成上一个事件,如果NativeInputQueue处理完成事件,它就会向通过管道向InputDispatcher发送消息指示consume完成,只有NativeInputQueue consume完成一个事件,InputDispatcher才会向共享内存写入另一个事件。

  【Android】事件处理系统

总结输入事件的处理流程

  首先从Kernel传递上来的键值由EventHub进行转码,之后由InputReader将其解释成各个事件,再由InputDispatcher分发。

  InputManager是InputReader和InputDispatcher线程的创建者,它只有一个职责,就是被WindowManagerService使用,从Native层获取按键事件。

  WindowManagerService则负责与窗口对接,分发按键消息。


源码位置

  事件分发给最前面的窗口:

  /frameworks/base/services/java/com/android/server/WindowManagerService.java

  拦截消息的处理类:
      /frameworks/base/policy/src/com/android/internal/policy/impl/PhoneWindowManager.java

  按键事件定义:
      /frameworks/base/core/java/android/view/KeyEvent.java

  Java层输入管理:
      /frameworks/base/services/java/com/android/server/InputManager.Java

  native层输入管理:
      /frameworks/base/libs/ui/InputManager.cpp

  事件读取线程:
      /frameworks/base/libs/ui/InputReader.cpp

  事件分发线程:
      /frameworks/base/libs/ui/InputDispatcher.cpp

  键码与键值转换:
      /frameworks/base/libs/ui/EventHub.cpp