Android的窗口机制分析(3)

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

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

    1.2.2 注册到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端事件传递系统的静态逻辑，如下图：

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

    A. 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模块提供的，