Android的用户输入处理

Android的用户输入系统获取用户按键(或模拟按键)输入,分发给特定的模块(Framework或应用程序)进行处理,它涉及到以下一些模块:

  • Input Reader: 负责从硬件获取输入,转换成事件(Event), 并分发给Input Dispatcher.
  • Input Dispatcher: 将Input Reader传送过来的Events 分发给合适的窗口,并监控ANR。
  • Input Manager Service: 负责Input Reader 和 Input Dispatchor的创建,并提供Policy 用于Events的预处理。
  • Window Manager Service:管理Input Manager 与 View(Window) 以及 ActivityManager 之间的通信。
  • View and Activity:接收按键并处理。
  • ActivityManager Service:ANR 处理。

它们之间的关系如下图所示(黑色箭头代表控制信号传递方向,而红色箭头代表用户输入数据的传递方向)。

这块代码很多,但相对来说不难理解,按照惯例,我们先用一张大图(点击看大图)鸟瞰一下全貌先。

四种不同颜色代表了四个不同的线程, InputReader Thread,InputDispatch Thread 和 Server Thread 存在于SystemServer进程里。UI Thread则存在于Activity所在进程。颜色较深部分是比较重要,需要重点分析的模块。

初始化

整个输入系统的初始化可以划分为Java 和 Native两个部分,可以用两张时序图分别描述,首先看Java端,

  1. 在SystemServer的初始化过程中,InputManagerService 被创建出来,它做的第一件事情就是初始化Native层,包括EventHub, InputReader 和 InputDispatcher,这一部分我们将在后面详细介绍。
  2. 当InputManager Service 以及其他的System Service 初始化完成之后,应用程序就开始启动。如果一个应用程序有Activity(只有Activit能够接受用户输入),它要将自己的Window(ViewRoot)通过setView()注册到Window Manager Service 中。(详见图解Android - Android GUI 系统 (2) - 窗口管理 (View, Canvas, Window Manager))。
  3. 用户输入的捕捉和处理发生在不同的进程里(生产者:Input Reader 和 Input Dispatcher 在System Server 进程里,而消耗者,应用程序运行在自己的进程里),因此用户输入事件(Event)的传递需要跨进程。在这里,Android使用了Socket 而不是 Binder来完成。OpenInputChannelPair 生成了两个Socket的FD, 代表一个双向通道的两端,向一端写入数据,另外一端便可以读出,反之依然,如果一端没有写入数据,另外一端去读,则陷入阻塞等待。OpenInputChannelPair() 发生在WindowManager Service 内部。为什么不用binder? 个人的分析是,Socket可以实现异步的通知,且只需要两个线程参与(Pipe两端各一个),假设系统有N个应用程序,跟输入处理相关的线程数目是 n+1 (1是发送(Input Dispatcher)线程)。然而,如果用Binder实现的话,为了实现异步接收,每个应用程序需要两个线程,一个Binder线程,一个后台处理线程,(不能在Binder线程里处理输入,因为这样太耗时,将会堵塞住发送端的调用线程)。在发送端,同样需要两个线程,一个发送线程,一个接收线程来接收应用的完成通知,所以,N个应用程序需要 2(N+1)个线程。相比之下,Socket还是高效多了。
  4. 通过RegisterInputChannel, Window Manager Service 将刚刚创建的一个Socket FD,封装在InputWindowHandle(代表一个WindowState) 里传给InputManagerService。
  5. InputManagerService 通过JNI(NativeInputManager)最终调用到了InputDispatchor 的 RegisterInputChannel()方法,这里,一个Connection 对象被创建出来,代表与远端某个窗口(InputWindowHandle)的一条用户输入数据通道。一个Dispatcher可能有多个Connection(多个Window)同时存在。为了监听来自于Window的消息,InputDispator 通过AddFd 将这些个FD 加入到Looper中,这样,只要某个Window在Socket的另一端写入数据,Looper就会马上从睡眠中醒来,进行处理。
  6. 到这里,ViewRootImpl 的 AddWindow 返回,WMS 将SocketPair的另外一个FD 放在返回参数 OutputChannel 里。
  7. 接着ViewRootImpl 创建了WindowInputEventReceiver 用于接受InputDispatchor 传过来的事件,后者同样通过AddFd() 将读端的Socket FD 加入到Looper中,这样一旦InputDispatchor发送Event,Looper就会立即醒来处理。

 接下来看刚才没有讲完的NativeInit。

  1. NativeInit 是 NativeInputManager类的一个方法,在InputManagerService的构造函数中被调用。代码在 frameworks/base/services/jni/com_android_server_input_inputManagerService.cpp.
  2. 首先创建一个EventHub, 用来监听所有的event输入。
  3. 创建一个InputDispatchor对象。
  4. 创建一个InputReader对象,他的输入是EventHub, 输出是InputDispatchor。
  5. 然后分别为InputReader 和 InputDispatchor 创建各自的线程。注意,当前运行在System Server 的 WMThread线程里。
  6. 接着,InputManagerService 调用NativeStart 通知InputReader 和 InputDispatchor 开始工作。
  7. InputDispatchor是InputReader的消费者,它的线程首先启动,进入Looper等待状态。
  8. 接着 InputReader 线程启动,等待用户输入的发生。

至此,一切准备工作就绪,万事具备,之欠用户一击了。

Eventhub 和 Input Reader

Android设备可以同时连接多个输入设备,比如说触摸屏,键盘,鼠标等等。用户在任何一个设备上的输入就会产生一个中断,经由Linux内核的中断处理以及设备驱动转换成一个Event,并传递给用户空间的应用程序进行处理。每个输入设备都有自己的驱动程序,数据接口也不尽相同,如何在一个线程里(上面说过只有一个InputReader Thread)把所有的用户输入都给捕捉到? 这首先要归功于Linux 内核的输入子系统(Input Subsystem), 它在各种各样的设备驱动程序上加了一个抽象层,只要底层的设备驱动程序按照这层抽象接口来实现,上层应用就可以通过统一的接口来访问所有的输入设备。这个抽象层有三个重要的概念,input handler, input handle 和 input_dev,它们的关系如下图所示:

    

 

  • input_dev 代表底层的设备,比如图中的“USB keyboard" 或 "Power Button" (PC的电源键),所有设备的input_dev 对象保存在一个全局的input_dev 队列里。
  • input_handler 代表某类输入设备的处理方法,比如说 evdev就是专门处理输入设备产成的Event(事件),而“sysrq" 是专门处理键盘上“sysrq"与其他按键组合产生的系统请求,比如“ALT+SysRq+p"(先Ctrl+ALT+F1切换到虚拟终端)可以打印当前CPU的寄存器值。所有的input_handler 存放在 input_handler队列里。
  • 一个input_dev 可以有多个input_handler, 比如下图中“USB Mouse" 设备可以由”evdev" 和 “mousedev" 来分别处理它产生的输入。
  • 同样,一个input_handler 可以用于多种输入设备,比如“USB Keyboard", "Power Button" 都可以产成Event,所以,这些Event都可以交由evdev进行处理。
  • Input handle 用来关联某个input_dev 和 某个 input_handler, 它对应于下图中的紫色的原点。每个input handle 都会生成一个文件节点,比如图中4个 evdev的handle就对应与 /dev/input/下的四个文件"event0~3". 通过input handle, 可以找到对应的input_handler 和 input_dev.

简单说来,input_dev对应于底层驱动,而input_handler是个上层驱动,而input_handle 提供给应用程序标准的文件访问接口来打通这条上下通道。通过Linux input system获取用户输入的流程简单如下:

  1. 设备通过input_register_dev 将自己的驱动注册到Input 系统。
  2. 各种Handler 通过 input_register_handler将自己注册到Input系统中。
  3. 每一个注册进来的input_dev 或 Input_handler 都会通过input_connect() 寻找对方,生成对应的 input_handle,并在/dev/input/下产成一个设备节点文件. 
  4. 应用程序通过打开(Open)Input_handle对应的文件节点,打开其对应的input_dev 和 input_handler的驱动。这样,当用户按键时,底层驱动就能捕捉到,并交给对应的上次驱动(handler)进行处理,然后返回给应用程序,流程如下图中红色箭头所示。

上图中的深色点就是 Input Handle, 左边垂直方向是Input Handler, 而水平方向是Input Dev。 下面是更为详细的一个流程图,感兴趣的同学可以点击大图看看。

 

所以,只要打开 /dev/input/ 下的所有 event* 设备文件,我们就可以有办法获取所有输入设备的输入事件,不管它是触摸屏,还是一个USB 设备,还是一个红外遥控器。Android中完成这个工作的就是EventHub。

EventHub实现在 framework/base/services/input/EventHub.cpp, 它和InputReader 的工作流程如下图所示:

 

  1.  NativeInputManager的构造函数里第一件事情就是创建一个EventHub对象,它的构造函数里主要生成并初始化几个控制的FD:
    1. mINotifyFd: 用来监控""/dev/input"目录下是否有文件生成,有的话说明有新的输入设备接入,EventHub将从epool_wait中唤醒,来打开新加入的设备。
    2. mWakeReaderFD, mWakeWriterFD: 一个Pipe的两端,当往mWakeWriteFD 写入数据的时候,等待在mWakeReaderFD的线程被唤醒,这里用来给上层应用提供唤醒等待线程,比如说,当上层应用改变输入属性需要EventHub进行相应更新时。
    3. mEpollFD,用于epoll_wait()的阻塞等待,这里通过epoll_ctrl(EPOLL_ADD_FD, fd) 可以等待多个fd的事件,包括上面提到的mINotifyFD, mWakeReaderFD, 以及输入设备的FD。
  2. 紧接着,InputManagerService启动InputReader 线程,进入无限的循环,每次循环调用loopOnce(). 第一次循环,会主动扫描 "/dev/input/" 目录,并打开下面的所有文件,通过ioctl()从底层驱动获取设备信息,并判断它的设备类型。这里处理的设备类型有:INPUT_DEVICE_CLASS_KEYBOARD, INPUT_DEVICE_CLASS_TOUCH, INPUT_DEVICE_CLASS_DPAD,INPUT_DEVICE_CLASS_JOYSTICK 等。
  3. 找到每个设备对应的键值映射文件,读取并生产一个KeyMap 对象。一般来说,设备对应的键值映射文件是 "/system/usr/keylayout/Vendor_%04x_Product_%04x".
  4. 将刚才扫描到的/dev/input 下所有文件的FD 加到epool等待队列中,调用epool_wait() 开始等待事件的发生。
  5. 某个时间发生,可能是用户按键输入,也可能是某个设备插入,亦或用户调整了设备属性,epoll_wait() 返回,将发生的Event 存放在mPendingEventItems 里。如果这是一个用户输入,系统调用Read() 从驱动读到这个按键的信息,存放在rawEvents里。
  6. getEvents() 返回,进入InputReader的processEventLocked函数。
  7. 通过rawEvent 找到产生时间的Device,再找到这个Device对应的InputMapper对象,最终生成一个NotifyArgs对象,将其放到NotifyArgs的队列中。
  8. 第一次循环,或者后面发生设备变化的时候(比如说设备拔插),调用 NativeInputManager 提供的回调,通过JNI通知Java 层的Input Manager Service 做设备变化的相应处理,比如弹出一个提示框提示新设备插入。这部分细节会在后面介绍。
  9. 调用NotifyArgs里面的Notify()方法,最终调用到InputDispatchor 对应的Notify接口(比如NotifyKey) 将接下来的处理交给InputDispatchor,EventHub 和 InputReader 工作结束,但马上又开始新的一轮等待,重复6~9的循环。

  

Input Dispatcher

接下来看看目前为止最长一张时序图,通过下面18个步骤,事件将发送到应用程序进行处理。

  1. 接上节的最后一步,NotifyKey() 的实现在Input Dispatcher 内部,他首先做简单的校验,对于按键事件,只有Action 是 AKEY_EVENT_ACTION_DOWN 和 AKEY_EVENT_ACTION_UP,即按下和弹起这两个Event别接受。
  2. Input Reader 传给Input Dispather的数据类型是 NotifyKeyArgs, 后者在这里将其转换为 KeyEvent, 然后交由 Policy 来进行第一步的解析和过滤,interceptKeyBeforeQueuing, 对于手机产品,这个工作是在PhoneWindowManager 里完成,(不同类型的产品可以定义不同的WindowManager, 比如GoogleTV 里用到的是TVWindowManager)。KeyEvent 在这里将会被分为三类:
    1. System Key: 比如说 音量键,Power键,电话键,以及一些特殊的组合键,如用于截屏的音量+Power,等等。部分System Key 会在这里立即处理,比如说电话键,但有一些会放到后面去做处理,比如说音量键,但不管怎样,这些键不会传给应用程序,所以称为系统键。
    2. Global Key:最终产品中可能会有一些特殊的按键,它不属于某个特定的应用,在所有应用中的行为都是一样,但也不包含在Andrioid的系统键中,比如说GoogleTV 里会有一个“TV” 按键,按它会直接呼起“TV”应用然后收看电视直播,这类按键在Android定义为Global Key.
    3. User Key:除此之外的按键就是User Key, 它最终会传递到当前的应用窗口。
  3. phoneWindowManager的interceptKeyBeforeQueuing() 最后返回了wmActiions,里面包含若干个flags,NativeInputManager在handleInterceptActions(), 假如用户按了Power键,这里会通知Android睡眠或唤醒。最后,返回一个 policyFlags,结束第一次的intercept 过程。
  4. 接下来,按键马上进入第二轮处理。如果用户在Setting->Accessibility 中选择打开某些功能,比如说手势识别,Android的AccessbilityManagerService(辅助功能服务) 会创建一个 InputFilter 对象,它会检查输入的事件,根据需要可能会转换成新的Event,比如说两根手指头捏动的手势最终会变成ZOOM的event. 目前,InputManagerService 只支持一个InputFilter, 新注册的InputFilter会把老的覆盖。InputFilter 运行在SystemServer 的 ServerThread 线程里(除了绘制,窗口管理和Binder调用外,大部分的System Service 都运行在这个线程里)。而filterInput() 的调用是发生在Input Reader线程里,通过InputManagerService 里的 InputFilterHost 对象通知另外一个线程里的InputFilter 开始真正的解析工作。所以,InputReader 线程从这里结束一轮的工作,重新进入epoll_wait() 等待新的用户输入。InputFilter 的工作也分为两个步骤,首先由InputEventConsistencyVerifier 对象(InputEventConsistencyVerifier.java)对输入事件的完整性做一个检查,检查事件的ACTION_DOWN 和 ACTION_UP 是否一一配对。很多同学可能在Android Logcat 里看到过以下一些类似的打印:"ACTION_UP but key was not down." 就出自此处。接下来,进入到AccessibilityInputFilter 的 onInputEvent(),这里将把输入事件(主要是MotionEvent)进行处理,根据需要变成另外一个Event,然后通过sendInputEvent()将事件发回给InputDispatcher。最终调用到injectInputEvent() 将这个事件送入 mInBoundQueue.
  5. 这个时候,InputDispather 还在Looper中睡眠等待,injectInputEvent()通过wake() 将其唤醒。这是进入Input Dispatcher 线程。
  6. InputDispatcher 大部分的工作在 dispatcherOnce 里完成。首先从mInBoundQueue 中读出队列头部的事件 mPendingEvent, 然后调用 pokeUserActivity(). poke的英文意思是"搓一下, 捅一下“, 这个函数的目的也就是”捅一下“PowerManagerService 提醒它”别睡眠啊,我还活着呢“,最终调用到PowerManagerService 的 updatePowerStateLocked(),防止手机进入休眠状态。需要注意的是,上述动作不会马上执行,而是存储在命令队列,mCommandQueue里,这里面的命令会在后面依次被执行。
  7. 接下来是dispatchKeyLocked(), 第一次进去这个函数的时候,先检查Event是否已经过处理(interceptBeforeDispatching), 如果没有,则生成一个命令,同样放入mCommandQueue里。
  8. runCommandsLockedInterruptible() 依次执行mCommandQueue 里的命令,前面说过,pokeUserActivity 会调用PowerManagerService 的 updatePowerStateLocked(), 而 interceptKeyBeforeDispatching() 则最终调用到PhoneWindowManager的同名函数。我们在interceptBeforeQueuing 里面提到的一些系统按键在这个被执行,比如 HOME/MENU/SEARCH 等。
  9. 接下来,处理前面提过GlobalKey,GlobalKeyManager 通过broadcast将这些全局的Event发送给感兴趣的应用。最终,interceptKeyBeforeDispatching 将返回一个Int值,-1 代表Skip,这个Event将不会发送给应用程序。0 代表 Continue, 将进入下一步的处理。1 则表明还需要后续的Event才能做出决定。
  10. 命令运行完之后,退出 dispatchOnce, 然后调用pollOnce 进入下一轮等待。但这里不会被阻塞,因为timeout值被设成了0.
  11. 第二次进入dispatchKeyLocked(), 这是Event的状态已经设为”已处理“,这时候才真正进入了发射阶段。
  12. 接下来调用 findFocusedWindowTargetLocked() 获取当前的焦点窗口,这里面会做一件非常重要的事情,就是检测目标应用是否有ANR发生,如果下诉条件满足,则说明可能发生了ANR:
    1. 目标应用不会空,而目标窗口为空。说明应用程序在启动过程中出现了问题。
    2. 目标 Activity 的状态是Pause,即不再是Focused的应用。
    3. 目标窗口还在处理上一个事件。这个我们下面会说到。
  13. 如果目标窗口处于正常状态,调用dispatchEventLocked() 进入真正的发送程序。
  14. 这里,事件又换了一件马甲,从EventEntry 变成 DispatchEntry, 并送人mOutBoundQueue。然后调用startDispatchCycle() 开始发送。
  15. 最终的发送发生在InputPublish的sendMessage()。这里就用到了我们前面提到的SocketPair, 一旦sendMessage() 执行,目标窗口所在进程的Looper线程就会被唤醒,然后读取键值并进行处理,这个过程我们下面马上就会谈到。
  16. 乖乖,还没走完啊?是的,工作还差最后一步,Input Dispatcher给这个窗口发送下一个命令之前,必须等待该窗口的回复,如果超过5s没有收到,就会通过Input Manager Service 向Activity Manager 汇报,后者会弹出我们熟知的 "Application No Response" 窗口。所以,事件会放入mWaitQueue进行暂存。如果窗口一切正常,完成按键处理后它会调用InputConsumer的sendFinishedSignal() 往SocketPair 里写入完成信号,Input Dispatcher 从 Loop中醒来,并从Socket中读取该信号,然后从mWaitQueue 里清除该事件标志其处理完毕。
  17. 并非所有的事件应用程序都会处理,如果没有处理,窗口程序返回的完成消息里的 msg.body.finished.handled 会等于false,InputDispatcher 会调用dispatchKeyUnhandled() 将其交给PhoneWindowManager。Android 在这里提供了一个Fallback机制,如果在 /system/usr/keychars/ 下面的kcm文件里定义了 fallback关键字,Android就识别它为一个Fallback Keycode。当它的Parent Keycode没有被应用程序处理,InputDispatcher 会把 Fallback Keycode 当成一个新的Event,重新发给应用程序。下面是一个定义Fallback Key 的例子。如果按了小键盘的0且应用程序不受理它,InputDispatcher 会再发送一个'INSERT' event 给应用程序。

    复制代码
    #/system/usr/keychars/generic.kcm
    ...
    key NUMPAD_0 {
        label: '0'             //打印字符
        base: fallback INSERT  //behavior
        numlock: '0'        //在一个textView里输出的字符
    }
    复制代码
  18. 经历了重重关卡,一个按键发送的流程终于完成了,不管有没有Fallback Key存在,调用startDispatcherCycle() 开始下一轮征程。。。

史上最长的流程图终于介绍完了,有点迷糊了?好吧,再看看下面这张图总结一下:

  • InputDispatcher 是一个异步系统,里面用到3个Queue(队列)来保存中间任务和事件,分别是 mInBoundQueue, mOutBoundQueue,mWaitQueue不同队列的进出划分了按键的不同处理阶段。
  • InputReader 采集的输入实现首先经过InterceptBeforeQueuing处理,Android 系统会将这些按键分类(System/Global/User), 这个过程是在InputReader线程里完成。
  • 如果是Motion Event, filterEvent()可能会将其转换成其他的Event。然后通过InjectKeyEvent 将这个按键发给InputDispatcher。这个过程是在System Process的ServerThread里完成。
  • 在进入mOutBoundQueue 之前,首先要经过 interceptBeforeDispatching() 的处理,System 和 Global 事件会在这个处理,而不会发送给用户程序。
  • 通过之前生成的Socket Pair, InputPublish 将 Event发送给当前焦点窗口,然后InputDispatcher将Event放入mWaitQueue 等待窗口的回复。
  • 如果窗口回复,该对象被移出mWaitQueue, 一轮事件处理结束。如果窗口没有处理该事件,从kcm文件里搜寻Fallback 按键,如果有,则重新发送一个新的事件给用户。
  • 如果超过5s没有收到用户回复,则说明用户窗口出现阻塞,InputDispather 会通过Input Manager Service发送ANR给ActivityManager。

 

Key processing

前面我们说过,NativeInputEventReceiver() 通过addFd() 将SocketPair的一个FD 加入到UI线程的loop里,这样,当Input Dispatcher在Socket的另外一端写入Event数据,应用程序的UI线程就会从睡眠中醒来,开始事件的处理流程。时序图如下所示:

 

 

  1.  收到的时间首先会送到队列中,ViewRootImpl 通过 deliverInputEvent() 向InputStage传递消息。
  2. InputStage 是 Android 4.3 新推出的实现,它将输入事件的处理分成若干个阶段(Stage), 如果当前有输入法窗口,则事件处理从 NativePreIme 开始,否则的话,从EarlyPostIme 开始。事件会依次经过每个Stage,如果该事件没有被标识为 “Finished”, 该Stage就会处理它,然后返回处理结果,Forward 或 Finish, Forward 运行下一Stage继续处理,而Finished事件将会简单的Forward到下一级,直到最后一级 Synthetic InputStage。流程图和每个阶段完成的事情如下图所示。

  3. 最后 通过finishInputEvent() 回复InputDispatcher。

 

点赞(0)

评论列表 共有 0 条评论

暂无评论
立即
投稿
发表
评论
返回
顶部