本文主要是对
图1 Activity组件与WindowManagerService服务和SurfaceFlinger服务的交互模型
事实上，用来关联Activity组件和Layer对象的SurfaceLayer对象并不是由Android应用程序请求SurfaceFlinger服务来创建的，而是由WindowManagerService服务请求SurfaceFlinger服务来创建的。WindowManagerService服务得到这个SurfaceLayer对象之后，再将它的一个代理对象返回给在Android应用程序这一侧的Activity组件。这样，Activity组件和WindowManagerService服务就可以通过同一个SurfaceLayer对象来操作在SurfaceFlinger服务这一侧的Layer对象，而操作Layer对象的目的就是为了修改Activity组件的UI。
在前面Android应用程序与SurfaceFlinger服务的关系概述和学习计划和Android系统Surface机制的SurfaceFlinger服务简要介绍和学习计划这两个系列的文章中，我们已经分析在SurfaceFlinger服务这一侧的Layer类和SurfaceLayer类的实现了。在现在的这一系列文章中，我们主要分析在Android应用程序这一侧的Activity组件与UI相关的类的实现，，以及在WindowManagerService服务这一侧的WindowState类的实现。
我们首先看Activity组件的实现，如图2所示：
图2 Activity组件的类关系图
Activity类是从ContextThemeWrapper类继承下来的，而ContextThemeWrapper类又是从ContextWrapper类继承下来的，最后ContextWrapper类又继承了Context类。
从前面Android应用程序启动过程源代码分析一文可以知道，Activity组件在启动的过程中，系统会为它创建一个ContextImpl对象，用来描述它的运行上下文环境。这个ContextImpl对象首先是通过调用Acitivity类的成员函数attach传递到Activity组件内部，接着再依次通过调用父类ContextThemeWrapper和ContextWrapper的成员函数attachBaseContext来分别保存在它们的成员变量mBase中。因此，ContextThemeWrapper和ContextWrapper类的成员变量mBase指向的实际上是一个ContextImpl对象。
从前面Android应用程序启动过程源代码分析一文还可以知道，系统为一个正在启动的Activity组件创建了一个ContextImpl对象之后，还会调用这个ContextImpl对象的成员函数setOuterContext来将正在启动的Activity组件保存在其成员变量mOuterContext中。这样，一个Activity组件就可以通过其父类ContextThemeWrapper或者ContextWrapper的成员变量mBase来访问用来描述它的运行上下文环境的一个ContextImpl对象，同时，一个ContextImpl对象也可以通过它的成员变量mOuterContext来访问它的宿主Activity组件。
Activity类还有另外一个类型为WindowManager的成员变量mWindowManager，它实际上指向的一个LocalWindowManager对象。LocalWindowManager类是用来管理应用程序窗口的，例如，用来维护应用程序窗口内部的视图（View）。LocalWindowManager类有一个类型为WindowManager的成员变量mWindowManager，它实际上指向的是一个WindowManagerImpl对象。系统通过调用WindowManagerImpl类的静态成员函数getDefault来获得一个WindowManagerImpl对象，然后保存在LocalWindowManager类的成员变量mWindowManager中。这样，LocalWindowManager类就可以通过WindowManagerImpl类来真正实现管理应用程序窗口的功能。
从上面的分析中，我们还看不出的一个Activity组件的窗口是如何描述的。为了弄清楚这个问题，我们继续分析Activity类的另外一个成员变量mWindow，如图3所示：
图3 Window类的实现
Activity类的成员变量mWindow的类型为Window，它用来描述一个应用程序窗口。这样，通过这个成员变量，每一个Activity组件就都会有一个对应的Window对象，即一个对应的应用程序窗口。
Window类有一个类型为Context的成员变量mContext。这个成员变量指向的是一个Activity对象。当系统为一个Activity组件创建一个对应的Window对象时，就会将这个Activity组件的Context接口保存在这个对应的Window对象的成员变量mContext中。这样，一个Window对象就可以通过它的成员变量mContext来访问它所描述的Activity组件的资源。
Window类还有一个类型为Window.Callback的成员变量mCallback。这个成员变量和成员变量mContext一样，都是指向同一个Activity对象，因为Activity类是实现了Window.Callback接口的。当系统为一个Activity组件创建一个对应的Window对象时，就会将这个Activity组件所实现的Window.Callback接口通过Window类的成员函数setCallback保存在对应的Window对象的成员变量mCallback。这样，一个Window对象就可以通过它的成员变量mCallback来将一些事件交给与它所对应的Activity组件来处理，例如，将接收的键盘事件交给对应的Activity组件来处理。
最后，Window类还有一个类型为WindowManager的成员变量mWindowManager。这个成员变量指向的是一个LocalWindowManager对象。前面提到，Activity组件的成员变量mWindowManager指向的也是一个LocalWindowManager对象。系统在启动一个Activity组件的过程中，会通过Window类的成员函数setWindowManager来将保存在它的成员变量mWindowManager中的一个LocalWindowManager对象也保存在对应的Window对象的成员变量mWindowManager。这样，一个Activity组件以及它所对应的Window对象就可以使用同一个LocalWindowManager对象来管理它们所描述的UI了。
事实上，Activity类的成员变量mWindow指向的并不是一个Window对象，而是一个PhoneWindow对象。也就是说，一个Activity组件的UI是使用一个PhoneWindow对象来描述的。
Activity类的成员变量mWindow所指向的一个PhoneWindow对象是通过调用PolicyManager类的静态成员函数makeNewWindow来创建的。PolicyManager类的实现如图4所示：
图4PolicyManager类的实现
充满了恐惧的声音，一种不确定的归宿的流动。
