Android InputEvent(Motion/Key/Sleep....) 流程跟踪
ViewRootImpl的setView()函数中（这个函数被调用代表着Activity的界面基本建立）会建立一群InputStage并以职责链模式链接起来进行协同工作：
- syntheticInputStage
- viewPostImeStage
- nativePostImeStage
- earlyPostImeStage
- imeStage
- viewPreImeStage
- nativePreImeStage
- 上面的优先级是倒序的，mFirstInputStage = nativePreImeStage是地一个InputStage，而mFirstPostImeInputStage = earlyPostImeStage.
QueuedInputEvent: 代表着一个等待被处理的输入事件,可能是任何输入
- 一般来说，event都是被串行处理的，分法者每次会向application传递一个Event并且在其处理完成以后投递下一个.
- 因为application或者IME可以合成或者添加多个event在同一时间内，因此在application端就不再有这样一个队列。
mFirstPostImeInputStage和mFirstInputStage会在deliverInputEvent(…)中被使用: InputStage stage = q.shouldSkipIme() ? mFirstPostImeInputStage : mFirstInputStage;
ViewRootImpl中的ViewPreImeInputStage extends InputStage
- onProcess(QueuedInputEvent q)被Override,只有在q.mEvent instanceof KeyEvent时才会调用processKeyEvent(q)， 否则直接返回FORWARD将QueuedInputEvent传递下去.
- processKeyEvent(QueuedInputEvent q), 调用 mView(即为Activity的最外层View，基本就是DecorView).dispatchKeyEventPreIme(event)，并返回FINISH_HANDLED代表着处理了该Event，如果dispatchKeyEventPreIme返回false, 那么就返回FORWARD以在onProcess中将事件传递下去.
ViewRootHandler extends Handler 中的handleMessage对MSG_DISPATCH_INPUT_EVENT/MSG_DISPATCH_KEY_FROM_IME会进行enqueueInputEvent的处理,
PhoneWindow的injectInputEvent(…) 会调用到ViewRootImpl的dispatchInputEvent. 但是一般来说应该是WindowInputEventReceiver(构造时传入了UIThread 的Handler)接受到onInputEvent并将其enqueue
WindowInputEventReceiver extends InputEventReceiver, 其onInputEvent(…)会被dispatchInputEvent(…)(该方法没有被WindowInputEventReceiver Override)调用，而后者则会在native层被调用.
- NativeInputEventReceiver::consumeEvents(…)会调用Java层的dispatchInputEvent(…).
- consumeEvents(…)的调用者则是handleEvent(int receiveFd, int events, void* data)调用.
- native层的nativeInit(…)则是Java层的nativeInit(…)的native实现.
- nativeInit(…)在InputEventReceiver构造时就会被调用(传递的第一个参数是指向自己的弱引用， 第二个参数则是channel,第三个参数则是Looper的MessageQueue). native层会根据这些信息在native层也构造一个NativeInputEventReceiver.
- 输入的Channel会被存在mInputConsumer中.
- nativeInit中会调用initialize(), 这个函数做了关键的工作: 调用了setFdEvents(ALOOPER_EVENT_INPUT)
- setFdEvents获取给定的Channel的fd，并将这个fd和要set的Events根据events是否为非0来addFd(…)/removeFd(…). addFd(…)代表着将此fd加入到对某个event的监听中，并且会传入this作为回调的接口，这也是其继承LooperCallback的原因
- addFd()的实现在core/libutils/Looper.cpp中: 其内部实现就是使用了epoll(epoll_ctl这个系统调用将被监听的描述符添加到epoll句柄或从epool句柄中删除或者对监听事件进行修改)来监听相应的event并回调
- 再看一下fd怎么获得的: setFdEvents时会mInputConsumer.getChannel()->getFd():
InputConsumer在..frameworks/native/include/input/InputTransport.h中被定义， InputChannel也是，其返回的mFd是在构造时传入的.
InputConsumer的构造是在InputEventReceiver的nativeInit(…)中调用 sp inputChannel = android_view_InputChannel_getInputChannel(env, inputChannelObj)根据java层传入的InputChannel对象来决定的，其定义在android_view_InputChannel.cpp中.
- NativeInputChannel* nativeInputChannel = android_view_InputChannel_getNativeInputChannel(env, inputChannelObj)获得一个对象，然后返回其nativeInputChannel->getInputChannel()
- android_view_InputChannel_getNativeInputChannel的操作则是取得java层传入的InputChannel对象的IntField, GetIntField(inputChannelObj, gInputChannelClassInfo.mPtr)将其强转为NativeInputChannel*并返回(reinterpret_cast), 转化的就是Java层InputChannel对象的mPtr值
- 不过Java层的InputChannel的mPtr其实也是在自己构造时在native层生成并回传的. android_view_InputChannel.cpp中的android_view_InputChannel_setNativeInputChannel会设置mPtr的值.
- 在构造时调用android_view_InputChannel_setNativeInputChannel的函数是android_view_InputChannel_createInputChannel, 而后者则是被android_view_InputChannel_nativeOpenInputChannelPair调用, 再进一步被Java层的openInputChannelPair(String name)(注意是一个static的函数)调用.
- InputChannel的openInputChannelPair(…)调用点很多，其中一个是在InputManagerService中的monitorInput(String inputChannelName), 后者进一步在WindowManagerService的构造函数中被调用: mPointerEventDispatcher = new PointerEventDispatcher(mInputManager.monitorInput(TAG)), TAG值是”WindowManager”
- 得到InputChannelName以后回到android_view_InputChannel_**nativeOpenInputChannelPair**中调用openInputChannelPair来获取serverChannel和clientChannel
nativeOpenInputChannelPair的实现在InputTransport.cpp中:
- 创建两个socket, socketpair(…)申请一对socket pair并保留fd
- 设置socket的属性
- 然后根据两个socket fd创建两个InputChannel: 分别赋予不同的ChannelName: append(” (server)”)/(” (client)”)
- 上面的socketpair的两个fd就是channel的fd., 就是上面epoll所监听的fd
回到WindowManagerService, 在addWIndow时，ViewRootImpl会传入自己new的InputChannel, 这个Channel以RPC的形式传递给WindowManagerService, 在addWindow(…)中调用了InputChannel.openInputChannelPair得到一对建立了联接的InputChannel以后(inputChannels),会调用win(一WindowState对象).setInputChannel(inputChannels[0]); inputChannels[1].transferTo(outInputChannel(ViewRootImpl传递过来的));
- 后面接着调用了mInputManager.registerInputChannel(win.mInputChannel(之前传入的inputChannels[0]), win.mInputWindowHandle);
- mInputManager即是InputManagerService， 最终调用到native层的nativeRegisterInputChannel(…), 进一步到natiev层的NativeInputManager的registerInputChannel(…)
- 进一步的mInputManager->getDispatcher()->registerInputChannel(…)
- InputManager.cpp->InputDispatcher.cpp->registerInputChannel(…)->mLooper->addFd(fd, 0, ALOOPER_EVENT_INPUT, handleReceiveCallback, this);, 还会根据channel信息建立一个Connection并加入到mConnectionsByFd中
- addFd在之前已经分析过了，基本就是加入到epoll.
- InputDispatcher.cpp的dispatchEventLocked(..)会根据输入的inputTarget.inputChannel从mConnectionsByFd中找到合适的Connection来传递Event,<-dispatchMotionLocked(..) <- dispatchOnceInnerLocked() <- dispatchOnce() <- InputDispatcherThread::threadLoop()
- InputDispatcherThread会在InputManager::initialize()中被new出来，并且在构造时传入一个InputDispatcher对象, 在InputManager::initialize()中会将InputDispatcherThread run起来，其线程优先级是PRIORITY_URGENT_DISPLAY
- Thread基类是system/core/include/utils/Thread.h定义的，关键的虚函数threadLoop(),其使用，如果返回true, 那么继续loop，返回false则线程完成任务结束,而在InputDispatcherThread中的threadLoop()一直返回true代表永不结束
- 对于inputEvent的预处理的关键实现在dispatchOnceInnerLocked中, 主要是在处理mPendingEvent, 有可能是从mInboundQueue中取出的，而对mInboundQueue的操作则主要是两个函数:
- enqueueInboundEventLocked(EventEntry* entry), 放入, notifyKey(…)和notifyMotion(…)应该是外部调用来传递事件的主要接口
- drainInboundQueueLocked()，取出,
- 从上面的分析以及其名字可以看出来，InputDispatcherThread其实只是在dispatch event而不负责产生event，因此一定有一个负责产生event的其他类型对象，并且InputDispatcherThread应该是以listener的形式挂接在上面，从其集成的接口也可以看出来: class InputDispatcher : public InputDispatcherInterface， 而lass InputDispatcherInterface : public virtual RefBase, public InputListenerInterface， 注意InputListenerInterface， 其会在InputListener.cpp和InputReader.cpp中被作为Listener使用
- 对应的产生Event的类就是InputReader，其也有一个对应的InputReaderThread, 对于触摸类事件的相关函数是dispatchPointerSimple(…),InputReaderThread的threadLoop()实现是mReader->loopOnce(),返回是true，代表永不结束
- loopOnce()是主体循环函数, 会调用mEventHub->getEvents(timeoutMillis, mEventBuffer, EVENT_BUFFER_SIZE)来获取新的event存放在mEventBuffer中并返回event的个数. 然后调用processEventsLocked(mEventBuffer, count)来处理mEventBuffer中的事件.
- InputReader也是在InputManager的构造函数中被实例化的, 传入的eventHub直接使用了InputManager构造时传入的eventHub(注意因为是C++，因此都是sp)， InputReader也可以作为InputManager的构造参数传入.
- 进一步的, InputManager的构造是在NativeInputManager(frameworks/base/services**/jni**/com_android_server_input_InputManagerService.cpp)的构造函数中, 而eventHub的实例化也在这里： sp eventHub = new EventHub().
- EventHub的getEvents函数，其主体系统调用epoll_wait(mEpollFd, …..), 其中的mEpollFd是在构造时通过epoll_create(EPOLL_SIZE_HINT)创建的该 函数生成一个epoll专用的文件描述符。它其实是在内核申请一空间，用来存放你想关注的socket fd上是否发生以及发生了什么事件。size(EPOLL_SIZE_HINT)就是你在这个epoll fd上能关注的最大socket fd数. 构造时还会有epoll_ctl(mEpollFd, EPOLL_CTL_ADD, mINotifyFd, &eventItem), mINotifyFd = inotify_init(),inotify_add_watch(mINotifyFd, DEVICE_PATH, IN_DELETE | IN_CREATE) 监视DEVICE_PATH这个目录
- EventHub::openDeviceLocked(const char *devicePath)会打开对某个设备的监听，并且int fd = open(devicePath, O_RDWR | O_CLOEXEC) 打开这个设备并获得fd，然后将设置fd最后将其加入到epoll的监听中,epoll_ctl(mEpollFd, EPOLL_CTL_ADD(加入), fd, &eventItem(这里面是要监听这个fd的哪些事件))， 添加了以后，在getEvents中的epoll_wait(…)在有想要的事件发生时，就会返回，然后将此事件加入到InputDisptacher的队列中，等待InputDisptacher通过InputEventReceiver分发到对应的channel，进一步到最开始的ViewRootIpl中的WindowInputEventReceiver再到InputStage
- openDeviceLocked(…)会在scanDirLocked(const char *dirname)/readNotifyLocked()中被调用, 打开并开始监听相关的输入设备.scanDevicesLocked()会在getEvents中会进行一次scan，之后再调用getEvents就不会再进行(one-shot)
- inotify_add_watch的目录是/dev/input, scanDevicesLocked中调用也是scanDirLocked(/dev/input), 在adb shell中用getevet这个函数就可以看到当前所有的input device以及触发的相应事件，下面就是genymotion虚拟机上的例子:
add device 1: /dev/input/event7
name: “Genymotion Virtual Input”
could not get driver version for /dev/input/mouse3, Not a typewriter
add device 2: /dev/input/event6
name: “Genymotion via VirtualBox seamless mouse”
could not get driver version for /dev/input/mouse2, Not a typewriter
add device 3: /dev/input/event5
name: “Genymotion via VirtualBox PS/2 mouse”
could not get driver version for /dev/input/mouse1, Not a typewriter
add device 4: /dev/input/event4
name: “VirtualBox mouse integration”
add device 5: /dev/input/event1
name: “Sleep Button”
add device 6: /dev/input/event0
name: “Power Button”
could not get driver version for /dev/input/mouse0, Not a typewriter
add device 7: /dev/input/event3
name: “ImExPS/2 Generic Explorer Mouse”
add device 8: /dev/input/event2
name: “AT Translated Set 2 keyboard”
could not get driver version for /dev/input/mice, Not a typewriter
一次屏幕点击触发的事件
/dev/input/event7: 0001 014a 00000001
/dev/input/event7: 0003 003a 00000001
/dev/input/event7: 0003 0035 0000013c
/dev/input/event7: 0003 0036 0000019a
/dev/input/event7: 0000 0002 00000000
/dev/input/event7: 0000 0000 00000000
/dev/input/event7: 0001 014a 00000000
/dev/input/event7: 0003 003a 00000000
/dev/input/event7: 0003 0035 0000013c
/dev/input/event7: 0003 0036 0000019a
/dev/input/event7: 0000 0002 00000000
/dev/input/event7: 0000 0000 00000000