Android GWES 消息系统

Android GWES

基本框架篇

 

我这里的GWES这个术语实际上从Microsoft 的Window上移植过来的，用GWES来表示Android的窗口事件系统不是那么准确，在Android中Window是个弱化了的概念，更多的表现在View这个概念上。在很大程度上，Android的View的概念可以代替Microsoft Window这个概念，有点和Microsof暗中较劲的意味，你用过的概念我就偏不用，这个也是我以为的设计者意图。

 

 原始GUI基本框架

 

    首先我们从Android的SDK外特性空间开始，在编写Actvitiy时，我们都是面对的处理函数：OnXXXX（），例如有按键按下就是OnKeyDown等，在这个过程中系统做了怎样的处理？要详细的理解这个过程，我们就需要理解Andoid的View管理，窗口系统，消息系统和输入系统。我们还是从最本质的地方开始，Android作为一种嵌入式的图形用户界面系统，它的基本原理与一般GUI的原理是相同的，同时也是遵循GWES(图形窗口事件系统)的一般规律，总体上Android就是管理用户输入和系统屏幕输出的一个系统。其实GWES这个名称更能体现GUI的基本实质要素：图形、窗口、事件。

1． 一般GUI的基本组成

    GUI的实现就是对上面提到的三个基本要素的管理，根据这这三个要素的特性及其涉及的范围，GUI在总体上可以分为三部分：

•  事件管理器
•  窗口管理器
• GDI(绘制与GDI逻辑对象管理)

 

（1） 事件管理器

• 收集系统消息，转换并分发系统消息和用户消息给各个窗口对象。
• 消息队列管理

（2）窗口管理器：

• 管理窗口的创建，销毁
•  窗口的绘制
•  活动窗口，输入焦点的切换
•  窗口间关系的管理
•  控件，菜单实现

（3）GDI

• 上下文设备管理
• 上下文设备对象管理：字体，画笔等
•  图形绘制:点、线，填充等
•  图象操作:位传送、位图操作

2 系统体系构架及其数据流的大体走向

 

 

 

 

    

在本质上GUI就是管理用户输入和屏幕输出，我们从上面的体系结构可以看到GUI的这两大数据流的基本流向，这也决定了Android GWES设计的最基本的着眼点。

Android弱化了窗口的概念，着重使用View的概念。所以Android的基本组成可以从上面的图修改成如下的组成：

Android GWES之Android消息系统

Looper，Handler，View

 

      我们要理解Android的消息系统，Looper，Handle，View等概念还是需要从消息系统的基本原理及其构造这个源头开始。从这个源头，我们才能很清楚的看到Android设计者设计消息系统之意图及其设计的技术路线。

 

消息系统的基本原理

 

从一般的系统设计来讲，一个消息循环系统的建立需要有以下几个要素：

•  消息队列
•  发送消息
•  消息读取
• 消息分发
•  消息循环线程

 

首先来研究一下消息驱动的基本模型，我使用如下的图形来表示一个消息系统最基本构成：

 

上面的模型代表应用程序一直查询自己的消息队列,如果有有消息进来,应用消息处理函数中根据消息类型及其参数来作相应的处理。

 

消息系统要运作起来,必定有消息的产生和消费。我们可以从下图看到消息生产和消费的一个基本的链条，这是一个最基本的，最简单的消息系统。

 

生产线程将消息发送到消息队列，消息消费者线程从消息队列取出消息进行相应的处理。但是这样简单的模型对实际运行的系统来说是不够的，例如对系统资源的消耗等不能很好的处理，我们就需要一个有旗语的消息系统模型，在上面的消息系统模型中加入了一个旗语，让消息消费者线程在没有消息队列为空时，等待旗语，进入到挂起状态，而有消息到达时，才被唤醒继续运行。当然生产者同时也可以是消费者。

 

 

2 Android的消息模型

Android要建立一个消息系统使用了Looper，MessageQueue,Handler等概念，从上节的原理我们可以知道这些都是概念包装,本质的东西就是消息队列中消息的分发路径的和消息分发处理方式的设计。Android巧妙的利用了对象抽象技术抽象出了Looper和Handler的概念。在Looper和Handler两个概念的基础上,通过View的处理函数框架，Android十分完美的达到消息分发的目的。

 

参照基本消息系统描述模型，我给出了Android消息系统整体框架,表示如下：

 

Android消息系统消息分发框架   -->service只负责分发投递消息，每个activity thread负责handle.还有一个疑问，systemserver是负责所有android service消息处理loop，这样设计会不会有阻塞的问题？

 

 

 

 

 

3 Looper,Handler详解

 

Looper只是产生一个消息循环框架，首先Looper创建了消息队列并把它挂接在Linux的线程上下文中，进入到取消息，并分发消息的循环当中。Handler对象在同一个线程上下文中取得消息队列，对消息队列进行封装操作，最主要的就是SendMessage和担当起dispatchMessage这个实际工作。外部系统需要向某个Android线程发送消息，必须通过属于该AndroidThread的Handler这个对象进行。

 

Handler属于某个线程，取决Handlerd对象在哪个线程中建立。Handler在构建时做了如下的默认动作：

• l 从线程上下文取得Looper。
• l 通过Looper获取到消息队列并记录在自己的成员mQueue变量中

 

Handler使用消息队列进行对象封装，提供如下的成员函数：

• l 通过  post(Runnable r)发送。Runnable是消息处理的回调函数，通过该消息的发送，引起Runable 的回调运行，Ｐｏｓｔ消息放置消息队列的前面。Message.callback=Runable.
• l 通过 sendMessage发送。放置在所有的Post消息之后，sendMessage发送消息.
• l dispatchMessage分发消息。消息带有回调函数，则执行消息回调函数，如何没有则使用默认处理函数：handleMessage。而handleMessage往往被重载成某个继承Handler对象的新的特定的handleMessage。

几乎所有的Message发送时，都指定了target。Message.target=(this).

 

 

 

Looper运行在Activity何处？我们现在可以从代码堆栈中纵观一下Looper的位置。

 

NaiveStart.main()

ZygoteInit.main

ZygoteInit$MethodAndArgsCall.run

Method.Invoke

method.invokeNative

ActivityThread.main()

Looper.loop()

ViewRoot$RootHandler().dispatch()

handleMessage

....

 

这样我们就更清楚的了解到Looper的运行位置。