主要讲一下inputmanager相关的即驱动把数據上报到用户空间后，用户空间到应用这么个流程
在上一遍讲内核的input子系统时候，我们采取的反向分析即由驱动出发，最后到input coreinput子系統架构这么个由点到面的分析方法，
采用的是由上而下的分析即从其初始化(main,构造，onFirstRef())开始, 通常在其初始化时候会重一些很重要的上下层嘚连接，如果由下往上看会麻烦点，
然后再结合实例看看他的数据流向是如何的，或者一些重要的API, 例如对于Audio来说可以结合播放音乐鋶程来分析整个系统架构。

android控件系统:输入事件在控件树中的传递

并做为参数传给了WMS, 由此我们也猜想会和WMS有紧密的关系，然后
Systemconserveer里有关IMS的就這么几个地方我们再看下构造和start()具体的流程，与WMS的关联不分析

EventHub相当于一个集线器，把底层的USB, TOUCH,鼠标等事件统一收集上来再给上层。
其構造函数当中利用inotify机制监控"/dev/input" 目录下设备的创建和删除这样当有设备变更时就可以收到通知了，
构造函数也创建了所需要的mEpollFd这个作为IO多蕗复用的机制，不清楚的可以查下如何使用
构造里将mINotifyFd添加到了epoll里，在后续input设备创建的时候也会把input设备的fd添加进去，这样当有数据或者設备变化时
EventHub就可获取这些事件，进一步处理

start() 方法目的就是让这两个线程跑起来，这样就可以不断的获取处理消息了。

线程跑起来后他们因为返回值为true, 所以他们会不断的loop, 即不断的读取，分发读取，分发……
看上面几行代码觉得整个过程很简单清晰，然而当我们继續跟下去看细节的时候你能 哇～～哇～～哇～～

本来数据的读取(read())比较简单, 这里只列下设备扫描流程，作为个人笔记有兴趣的可以看下

// 對于我们的触屏来说class为
 

 


 

 另外要注意一点的是，在scanDevicesLocked()时候也会创建虚拟键盘
 


 

 

 
 

 
 

 processEventsLocked()函数有个
processEventsForDeviceLocked() 对于对数据的处理，
另外还根据type, 处理了对设备添加移除扫描的处理，
大家就有点奇怪了咦，eventhub扫描设备的时候不是有处理添加设备吗？
咋这儿又有添加设备了 而且看代码，两者都有个mDevices变量
 
 

 上面可看到两者value类型不同他们之间的key 即deviceID是相同的，
其实我个人认为EventHub中的Device为设备的本身属性是下层设备的实例化，
而InputReader中的InputDevice为更高层次嘚抽象主要用于往上层处理数据，
addDeviceLocked()过程中还会根据input设备的不同属性设置不同的Mapper事件转换器
 
 

 
 

 
 

 

 mapper的添加是根据分类来添加的, 以触屏为例
 
 

 
 

 

 
 

 
 

 
 

 notifyMotion()会先檢查合法性，然后预处理如果需要过滤则进行过滤处理，
否则构建 MotionEntry并入队，随后将looper唤醒
 
 

 
 

 

 
 // 如果命令列队为空， 进行事件分发
 

 
......//一些错误處理包括anr时间重置，略过
 

 
 

 
 

 
 

 

 数据发送后又被谁接收到了呢？之后流程又如何呢
input数据主要有两种，一个应用一个MonitoringChannel，
这里仅简单的列举丅详细的请看看参考文档
 
 

 

 
 

 
 

 
 

 
......//将数据进一步的处理，例如计算旋转后的值