Android Input System分析(一)--基本架构

说明:本文中诸多图片均来源于网络,如有冒犯,请谅解。


开始之前,我们先从整个android大的架构来俯视一遍input体系,先一览众山小,再对局部刨根问底,如下图:

Android Input System分析(一)--基本架构Android Input System分析(一)--基本架构

Android Input System分析(一)--基本架构Android Input System分析(一)--基本架构

从这张图来看,我们可以看出总共分了三部分,一个是客户端进程,一个是系统进程,正常情况下android的客户端和系统进程通信使用的是binder,但这里在消息分发的时候并不是,而是使用的是管道,具体原因在后面再分析。第三部分是kernel部分,系统进程和kernel的通信稍微复杂一些,显示WMS通过JNI的方式调用对应的native服务,native再通过设备文件和kernel进行数据通讯。

通过上面的架构图,我们基本知道了,设备的input信息的起源在于内核,客观的来说,input的触发来源于硬件中断,下面我就从内核部分开始讲起。

把内核部分流程放大,如下图:

Android Input System分析(一)--基本架构Android Input System分析(一)--基本架构Android Input System分析(一)--基本架构

先对各个层做个基本介绍:

驱动层:将底层的硬件输入转化为统一事件形式,向输入核心(Input Core)汇报。
输入子系统核心:承上启下,为驱动层提供输入设备注册与操作接口,如:input_register_device;通知事件处理层对事件进行处理;在/Proc下产生相应的设备信息
事件处理层:主要是和用户空间交互,(Linux中在用户空间将所有的设备都当作文件来处理,由于在一般的驱动程序中都有提供fops接口,以及在/dev下生成相应的设备文件nod,这些操作在输入子系统中由事件处理层完成)

整个过程是在这样的,用户的在硬件设备上的点击或者触摸会产生设备中断电信号,由此来触发CPU调度来调用对应的设备中断响应,中断响应在设备驱动层完成。

再来看核心层,无论是什么样的输入设备,最终都要进过核心层的API处理之后才会往后继续走,可以说,核心层是独木桥,是真核心,必须经过他的处理,事件才能继续分发。

其实上述的逻辑都是可以通过系统的代码结构一一对应上的,请看下图:

Android Input System分析(一)--基本架构Android Input System分析(一)--基本架构Android Input System分析(一)--基本架构

如果把上面的两张逻辑图合二为一,大家看的也更直观一点:

Android Input System分析(一)--基本架构Android Input System分析(一)--基本架构Android Input System分析(一)--基本架构

到此我们基本把输入系统内核部门的子架构梳理了一遍,我们稍息片刻,看看有哪些信息点需要补一补,特别是对linux系统不太熟悉的兄弟,估计听着有点晕。

先从中断开始吧,咱们输入系统要是没有他,其实也不知道该干嘛。

下面是专业术语解释:

中断(Interrupt)中断本质是一种特殊的电信号,由硬件设备发向处理器。处理器接受到中断后,会马上向操作系统反映此信号的到来,然后就由os负责处理这些新到来的数据。

轮询(Polling)一种CPU决策如何提供周边设备服务的方式,又称“程控输出入”(Programmed I/O)。轮询法的概念是,由CPU定时发出询问,依序询问每一个周边设备是否需要其服务,有即给予服务,服务结束后再问下一个周边,接着不断周而复始。

事实上,现代化的操作系统,中断和轮询都有在使用,甚至可以互相替换,但大多数使用的都是中断的方式,因为中断更及时,响应更快,这样的设计模式也更合理。


至此,基本框架部分就先介绍到这里,下面会从底层往上一步步解析android的输入系统是如何工作的。