一切从android的handler说起(五)之触摸事件模型

阅读本文大概需要 5 分钟。

 

 

在弄清楚了handler消息机制原理后，小张显得异常高兴，感觉这块儿终于像一碗清水似的看到底了。

 

我无意间说了一句：别高兴得太早，你只清楚了一半！

小张听了有点发懵：一半？啥意思，不都非常清晰了吗？

 

我笑了笑，说道：现在你只知道UI线程是事件驱动模型，有事就干，没事就睡觉，那有没有想过事件都从何而来？为何我手指触摸UI上任何一个button都能很快做出反应呢？这个触摸事件是如何转为message扔到UI queue里去的呢？

 

小张瞬间愣住了，原来之前一直在聊的都是UI线程如何被message唤醒触发，从未考虑过message的源头是如何来的。

 

小张紧接着又补了一句：那肯定不是UI线程自己一直在盯着，而是另外一个东西，不然UI线程又该卡成翔了。

我继续问道：是的。那究竟是谁在负责这个输入事件的源头的采集呢？

 

小张只得缴械，直说不知道。

我又问道：如果是你来设计这个模型，你能大概给个想法吗？

 

小张想了一会儿说道：

1). 首先应该有一个线程在不断的监听屏幕，一旦有触摸事件，就将事件捕获；

2). 其次，还应该存在某种手段可以找到目标窗口，因为可能有多个APP的多个界面为用户可见，必须确定这个事件究竟通知那个窗口；

3). 最后才是目标窗口如何消费事件，也就是在这一步事件被包装成message(包含具体的触摸点x，y坐标)扔进queue中唤醒UI线程来处理。

 

并且在纸上画出了模型图，大概如下：

 

我看了一下，说道：没错，你这个设计解耦很好，各负其职。其实Android系统也是这个设计。

第1)步里所说的负责监听触摸事件的是InputManagerService。

第2)步里所说的找到目标窗口的是WindowManagerService。它俩在Android操作系统启动时已经在System Server进程中被创建好，并被注册到了另一个ServiceManager进程当中。

 

小张不解的问道：ServiceManager？这个东东是干嘛的ÿ