ANDROID核心问题,Android核心分析

1 输入路径的一般原理

按键，鼠标消息从收集到最终将发送到焦点窗口，要经历怎样的路径，是Android GWES设计方案中需要详细考虑的问题。按键，鼠标等用户消息消息的处理可分为不同的情况进行判定：

(1)用户输入根据系统状况是否应该派送。如在ScreenOff的情况下，在按键属于特殊按键的情况下等

(2)是否有拦截Listener

(3)对按键事件来讲，是否存在输入法

(4)是否是焦点终点

(5)是否为焦点切换按相关键

这些情况都是设计输入路径需要考虑的基本条件。

1.1一般的输入路径设计

该输入路径实际上是指的按键消息(MSG_KEYDOWN，MSG_KEYUP， MSG_LongPress)的输入路径，即从活动主窗口到焦点窗口所经历的路程。

将信息输入路径分为两步：

Step 1)窗口管理器将信息发送到活动窗口

Step 2)活动窗口通过缺省处理函数将该消息一层层的传递到焦点。

这样应用程序可以在活动View的处理函数中来预先处理用户输入信息，从而增强应用对用户信息的控制力。

传递路径是通过View的缺省处理函数Onxxx来完成。通过ActiveView

->focus->focus->focus的链条关系，一级一级的将按键消息MSG_KEYDOWN，MSG_KEYUP，

MSG_CHAR等传递到focus窗口。

此时用户按键输入先发送到输入法窗口，经过输入法管理器处理，过滤后将输入法产生的结果放置到焦点View。

1.3输入系统整体流程

下面示意图是Android输入系统的数据流途径，通过WM的输入系统线程收集消息，分发到Focus Activity消息队列，然后通过消息系统派发。

2 Android输入路径详细描述

2.1 第一步:用户数据收集及其初步判定

KeyInputQ在WindowMangerService中建立一个独立的线程InputDeviceReader，使用Native函数readEvent来读取Linux

Driver的数据构建RawEvent，放入到KeyQ消息队列中。

preProcessEvent()@KeyInptQ@KeyInputQueue.java这个是在输入系统中的第一个拦截函数原型。KeyQ重载了preProcessEvent()@WindowManagerService.java。在该成员函数中进行如下动作：

(1) 根据PowerManager获取的Screen on,Screen

off状态来判定用户输入的是否WakeUPScreen。

(2) 如果按键式应用程序切换按键，则切换应用程序。

(3) 根据WindowManagerPolicy觉得该用户输入是否投递。

2.2 第二步 消息分发第一层面

InputDispatcherThread从KeyQ中读取Events，找到Window Manager中的Focus

Window，通过Focus Window记录的mClient接口，将Events专递到Client端。

如何将KeyEvent对象传到Client端：

在前面的章节(窗口管理ViewRoot，Window Manager Proxy)我们已经知道：在客户端建立Window

Manager Proxy后，添加窗口到Window Manager service时，带了一个跟客户ViewRoot相关的IWindow接口实例过去，记录在WindowState中的mClient成员变量中。通过IWindow这个AIDL接口实例，Service可以访问客户端的信息，IWindow是Service连接View桥梁。

看看在Client ViewRootKeyEvent的分发过程

IWindow：dispatchKey(event)

dispatchKey(event)@W@ViewRoot@ViewRoot.java

ViewRoot.dispatchKey(event)@ViewRoot.java

message>

sendMessageAtTime(msg)@Handler@Handler.java

至此我们通过前面的Looper，Handler详解章节的分析结论，我们可以知道Key

Message已经放入到应用程序的消息队列。

2.3第三步：应用消息队列分发

消息的分发,在Looper，Handler详解章节我们分析了Looper.loop()在最后后面调用了handleMesage.

…

ActivityThread.main()

Looper.loop()

ViewRoot$RootHandler().dispatch()

handleMessage

....

注意到在分发的调用msg.target.dispatch()，而这个target在第二层将消息sendMessageAtTime到消息队列时填入了mag.target=this即为msg.target=ViewRoot实例。所有此时handleMessage就是ViewRoot重载的handleMessage函数。

handlerMessage@ViewRoot@ViewRoot.java

deliverkeyEvent

如果输入法存在，dispatchKey到输入法服务。

否则deliverKeyEventToViewHierarchy@ViewRoot.java

在这里需要强调的是，输入法的KeyEvent的拦截并没有放入到Window

Manager Service中，而是放入到了客户端的RootView中来处理。

2.4第四步：向焦点进发，完成焦点路径的遍历。

分发函数调用栈

deliverKeyEventToViewHierarchy@ViewRoot.java

mView.dispatchKeyEvent：mView是与ViewRoot相对应的Top-Level

View.如果mView是一个ViewGroup则分发消息到他的mFocus。

mView.dispatchKeyEvent @ViewGroup (ViewRoot@root)

Event.dispatch

mFocus.dispatchKeyEevnet

如果此时的mFocu还是一个ViewGroup，这回将事件专递到下一层的焦点，直到mFocus为一个View。通过这轮调用，就遍历了焦点Path，至此，用户事件传递完成一个段落。

2.5第五步 缺省处理

如果事件在上述Focus View没有处理掉，并且为方向键之类的焦点转换相关按键，则转移焦点到下一个View。

首先抛开Android的一切概念来研究一下电话系统的最基本的描述。我们的手机首先用来打电话的，随后是需要一个电话本，随后是PIM，随后是网络应用，随后是云计算，随后是想我们的手机无所不能，替代PC。但是作为一个电话的基本功能如下：

0)拨叫电话,接听电话，挂断电话,发送短信，网络连接,PIM管理

1)由于电话运营商为我们提供了呼叫等待，电话会议等补充业务，所以我们的手机需要管理多路通话，如何管理?

2)来电时，我们要播出来电铃声，接通时我们需要切换语音通道，这个又跟多媒体系统打上了交道，例如有耳机插上了，有蓝牙耳机连上了，系统该做如何的管理和切换？

3)上网的网络通路建立(例如GSM GPRS)，如何PPP连接并连接到LinuxSocket通道上的？系统如何管理数据连接？

4)AP跟Modem通讯时通过AT指令的，如何将AT指令变成一个个具体的操作函数，如何管理Modem发给我们的回应，AT命令通道，数据通道如何管理？

5)sim卡的电话本如何管理？

上面的关于手机的基本问题，Android电话系统设计者必须要解答的问题。该设计如何的管理框架，提出什么概念来表达？所以要分析Android的电话部分，还是需要理解电话实现的背景知识，通讯协议，大体框架。

我们回到电话系统基本构成上，先从整体上去把握一下电话模块的大体框架，先从空中俯瞰。我给出的图是一般的智能手机的框架图，该框架基本能够概括所有手机电话模块的构成，当然也包括Android的电话系统构成。

智能机架构一般是应用处理器+Modem。应用处理器与Modem的连接使用串口或者USB。在一个硬件串口通路上实现为了要同时实现数据传输并同时实现控制Modem,就需要实现多路复用协议(GSM

TS07.10)，在底层我们在多路复用的基础上虚拟了两个串口，一个用于CMD通道，一个用于DATA通道。电话的所有控制通路都是在这连个通道上。

RIL,Radio Interface Layer。本层为一个协议转换层，手机框架需要适应多类型的Modem接入到系统中，而对于不同的Modem有不同的特性，AT指令的格式或者回应有所不同，但是这种特性在设计应用时不可能完全考虑和兼容。所以设计者在设计电话系统时，建立了一个虚拟电话系统，为该虚拟电话系统规定了标准的功能，上层的电话管理都是建立在这些标准的功能基础之上。而RIL则是将虚拟电话系统的标准功能转换成实际的所使用的Modem的AT指令。

Android设计者将电话系统设计成了三部分。

Andoird的Phone Service其实是PhoneApp。GSMPhone(CDMAPhone)是Phone

Service核心的对象，他包含了如下的相关对象。

我们的分析任务就是要把这些对象的相互关系，及其对象间数据传递关系弄清楚。首先我们给出以下的Android电话系统的框架，以便对Android电话系统有个概要的认识，然后从数据流的角度，以及对象的引用关系来分析系统。下面是android电话系统整体框架图。