Android Framework -- InputManagerService

分发流程

　我们知道system_server会启动各种服务，其中包括InputManagerService，IMS的native层对应者一个NativeInputManager。事件分发的起源就在这里，NativeInputManager中有三个对象（EventHub，InputReader，InputDispatcher）各自都有一个工作线程。
　首先我们输入设备的设备驱动文件都在dev/input/event0~n这里，所有输入事件都将写入这些驱动中，EventHub负责从驱动中捞取输入事件，InputReader则负责将输入原始值转换成虚拟值，InputDispatcher则负责为输入事件寻找合适的Window并分发下去。
　

原始值 =》 虚拟值 =》 根据不同类似的事件封装成不同的Mapper（了解即可）

此外这里还有两个点要说明
　第一个NativeInputManager有一个InputWindowHandle对象，它与WMS会有一个同步关系，保证NativeInputManager里可以获得当前所有的window，并通过WMS与window通信，把输入事件分发下去
　第二个NativeInputManager与Window的通信并不是常见的Binder，而是SockerPair（详情自查），大致的工作原理就是这种通信方式有一对的InputChannel，window会持有一个InputChannel，IMS这边持有配对的InputChannel，这样只要找到合适的window就可以发过去了。

Window这边的接收方是在ViewRootImpl的内部类WindowEventReceiver中进行接收处理。
这边介绍下Activity、Window、DecorView和ViewRootImpl的关系，正常Activity持有一个Window即PhoneWindow，PhoneWindow最外层是一个DecorView（继承自FrameLayout）；而每个Activity都会有一个ViewRootImpl用来管理所有的View以及View的事件分发，绘制也是从这边开始的。此外WindowManagerGlobal会持有所有Window（可以模糊的理解成Activity）的ViewRootImpl、DecroView以及DecorView的LayoutParams。

回到事件传递，这边先说下事件消费的相关知识，一般的一个点击事件分DOWN，MOVE，UP几个阶段，DOWN阶段就会判断这个事件由谁来消费后续的MOVE，UP等都会分发到这个对象；事件由外向内层层分发。下面看下大致的分发流程：

PS：
dispatchTouchEvent：返回true表示本层要拦截这个事件，false则表示不拦截
onInterceptEvent：返回true表示把事件往子层分发，false则表示不往子层分发（即子层的dispatchTouchEvent不会被调用）
onTouchEvent：返回true则表示本层消费该事件，false则表示本层不消费该事件
Activity 和 View 拥有：dispatchTouchEvent onTouchEvent 方法
ViewGroup 拥有：dispatchTouchEvent onInterceptEvent onTouchEvent 方法

最后上图所述基本都属于ACTION_DOWN的阶段,这个阶段决定了谁消费这整个事件。
PS：其实还有其他的事件类型只不过比较少见；
ACTION_CANCEL： 收到前驱事件后，后续事件被父控件拦截的情况下产生
ACTION_OUTSIDE：比如拖动某个View，拖出它的父控件范围则会调用

Android触摸屏事件派发机制详解与源码分析一(View篇)
Android触摸屏事件派发机制详解与源码分析二(ViewGroup篇)
Android触摸屏事件派发机制详解与源码分析三(Activity篇)