Android应用程序窗口(Activity)实现框架简要介绍和学习计划-阿里云开发者社区

开发者社区> 开发与运维> 正文
登录阅读全文

Android应用程序窗口(Activity)实现框架简要介绍和学习计划

简介:

 前面我们学习了SurfaceFlinger服务的实现原理。有了这个基础之后,从本文开始,我们就可以分析Android系统在Java层的UI实现了。我们知道,在Android应用程序的四大组件中,只有Activity组件与UI相关,它描述的是应用程序窗口,因此,我们就通过它的UI实现来分析Android系统在Java层的UI实现。本文主要是对Activity组件的UI实现作简要介绍以及制定学习计划。

       Activity组件的UI实现需要与WindowManagerService服务和SurfaceFlinger服务进行交互。从前面Android应用程序键盘(Keyboard)消息处理机制分析一文可以知道,Activity组件在启动完成后,会通过一个类型为Session的Binder对象来请求WindowManagerService为它创建一个类型为WindowState的对象,用来描述它的窗口状态。此外,从Android应用程序与SurfaceFlinger服务的关系概述和学习计划这一系列的文章又可以知道,Android应用程序会通过一个类型为Client的Binder对象来请求SurfaceFlinger服务为它创建一个类型为Layer的对象,用来描述它的窗口数据。

       从Android应用程序请求SurfaceFlinger服务创建Surface的过程分析一文又可以知道,SurfaceFlinger服务为Android应用程序创建一个类型为Layer的对象之后,会返回一个类型为SurfaceLayer的Binder对象给Android应用程序,这样Android应用程序就可以通过这个Binder对象来请求SurfaceFlinger服务来分配图形缓冲区。

       综合上述信息,我们就可以得到Activity组件与WindowManagerService服务和SurfaceFlinger服务的交互模型,如图1所示:

1352650023_9398.jpg

图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所示:

1352647846_3903.jpg

图2 Activity组件的类关系图

       Activity类是从ContextThemeWrapper类继承下来的,而ContextThemeWrapper类又是从ContextWrapper类继承下来的,最后ContextWrapper类又继承了Context类。

       从前面Android应用程序启动过程源代码分析一文可以知道,Activity组件在启动的过程中,系统会为它创建一个ContextImpl对象,用来描述它的运行上下文环境。这个ContextImpl对象首先是通过调用Acitivity类的成员函数attach传递到Acticity组件内部,接着再依次通过调用父类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所示:

1354201827_9391.jpg

图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所示:

1352737483_1274.jpg

图4 PolicyManager类的实现

       PolicyManager类有一个类型为IPolicy的静态成员变量sPolicy,它实际指向的是一个Policy对象。Policy类实现了IPolicy接口的成员函数makeNewWindow,而PolicyManager类就是通过这个成员函数来为一个Activity组件创建一个PhoneWindow对象的。

      PhoneWindow类继承了Window类,因此,它的对象可以保存Activity类的成员变量mWindow中。PhoneWindow类的实现如图5所示:

1352736693_6736.jpg

图5 PhoneWindow类的实现

       PhoneWindow类有两个重要的成员变量mDecor和mContentParent,它们的类型分别DecorView和ViewGroup。其中,成员变量mDecor是用描述自己的窗口视图,而成员变量mContentParent用来描述视图内容的父窗口。

       DecorView类继承了FrameLayout类,而FrameLayout类又继承了ViewGroup类,最后ViewGroup类又继承了View类。View类有一个成员函数draw,它是用来绘制应用程序窗口的UI的。DecorView类、FrameLayout类和ViewGroup类都重写了父类的成员函数draw,这样,它们就都可以定制自己的UI。

       DecorView类所描述的应用程序窗口视图是否需要重新绘制是由另外一个类ViewRoot来控制的。系统在启动一个Activity组件的过程中,会为这个Activity组件创建一个ViewRoot对象,同时还会将前面为这个Activity组件所创建的一个PhoneWindow对象的成员变量mDecor所描述的一个视图(DecorView)保存在这个ViewRoot对象的成员变量mView中。这样,这个ViewRoot对象就可以通过调用它的成员变量mView的所描述的一个DecorView的成员函数draw来绘制一个Acitivity组件的UI了。ViewRoot类的作用是非常大的,它除了用来控制一个Acitivity组件的UI绘制之外,还负责接收Acitivity组件的IO输入事件,例如,键盘事件,这一点可以参考前面Android应用程序键盘(Keyboard)消息处理机制分析一文。

       ViewRoot类的实现如图6所示:

1353087703_2343.jpg

图6 ViewRoot类的实现

       ViewRoot类是从Handler类继承下来的。从前面Android应用程序消息处理机制(Looper、Handler)分析一文可以知道,从Handler类继承下来的子类可以调用父类的成员函数sendMessage来向指定的线程的消息队列发送消息,以及在自己重写的成员函数handleMessage中处理该消息。 ViewRoot类在两种情况需要经常应用程序进程的主线程的消息队列发送消息。

       第一种情况是当ViewRoot类从系统输入管理器InputManager接收到键盘、触摸屏等输入事件时,它就会把这些输入事件封装成一个消息,并且发送到应用程序进程的主线程的消息队列中去进一步处理,这样就可以保证键盘、触摸屏等输入事件可以在应用程序进程的主线程中进行处理。这一点可以参考前面Android应用程序键盘(Keyboard)消息处理机制分析一文。

       第二种情况是当ViewRoot类需要重新绘制与它所关联的一个Activity组件的UI时,它就会将这个绘制UI的操作封装成一个消息,并且发送到应用程序进程的主线程的消息队列中去进一步处理,这样同样可以保证绘制UI的操作可以在应用程序进程的主线程中执行。

       每一个ViewRoot对象都有一个类型为View的成员变量mView,它指向了一个DecorView对象。这个DecorView对象是从哪里来的呢?前面提到,每一个Activity组件都有一个对应的ViewRoot对象以及一个对应的PhoneWindow对象,这个DecorView对象就是来自于这个对应的PhoneWindow对象的成员变量mDecor。也就是说,与同一个Activity组件对应的ViewRoot对象和PhoneWindow对象分别通过各自的成员变量mView和mDecor引用了共一个DecorView对象。

       每一个ViewRoot对象都有一个类型为WindowManager.LayoutParams的成员变量mWindowAttributes,它指向了一个ViewGroup.LayoutParams对象,用来描述与该ViewRoot对象对应的一个Activity组件的UI布局信息。

       从上面的描述就可以知道,每一个Activity组件都有一个对应的ViewRoot对象、View对象以及WindowManager.LayoutParams对象。这三个对象的对应关系是由WindowManagerImpl类来维护的。具体来说,就是由WindowManagerImpl类的成员变量mRoots、mViews和mParams所描述的三个数组来维护的。例如,假设一个应用程序进程运行有两个Activity组件,那么WindowManagerImpl类的成员变量mRoots、mViews和mParams所描述的三个数组的大小就等于2,其中,mRoots[0]、mViews[0]和mParams[0]对应于第一个启动的Activity组件,而mRoots[1]、mViews[1]和mParams[1]对应于第二个启动的Activity组件。

       每一个ViewRoot对象都有一个类型为Surface的成员变量mSurface,它指向了一个Java层的Surface对象。这个Java层的Surface对象通过它的成员变量mNativeSurface与一个C++层的Surface对象。这个C++层的Surface对象就是我们在Android应用程序与SurfaceFlinger服务的关系概述和学习计划这一系列文章中所分析的Surface类的实例了。这个Surface类是用来在Android应用程序进程这一侧描述应用程序窗口的。从前面Android应用程序请求SurfaceFlinger服务创建Surface的过程分析一文可以知道,在C++层中,每一个Surface对象都有一个对应的SurfaceControl对象。这个对应的SurfaceControl对象是用来设置应用程序窗口的属性,例如,设置大小、位置等属性。

       但是,与ViewRoot类的成员变量mSurface所对应的在C++层的Surface对象并没有一个对应的SurfaceControl对象,这是因为ViewRoot类并不需要设置应用程序窗口的属性,它需要做的只是往应用程序窗口的图形缓冲区填充UI数据,即它需要设置的只是应用程序窗口的纹理。应用程序窗口的纹理保存在Java层的Surface类的成员变量mCanvas所描述一个画布(Canvas)中,即通过这个画布可以访问到应用程序窗口的图形缓冲区。当ViewRoot类需要重新绘制与它对应的Activity组件的UI时,它就会调用它的成员函数draw来执行这个绘制的操作。ViewRoot类的成员函数draw首先通过获得保存它的成员变量mSurface内部的一块画布,然后再将这个画布传递给它的成员变量mView所描述的一个View对象的成员函数draw。View类的成员函数draw得到了这块画布之后,就可以随心所欲地上面绘制应用程序窗口的纹理了。这些纹理的绘制工作是通过Skia图形库API来进行的。

       那么,应用程序窗口的属性是由谁来管理的呢?这是由WindowManagerService服务来管理的。前面提到,在Android应用程序这一侧的Activity组件是由WindowManagerService服务来为它请求SurfaceFlinger服务创建一个Layer对象以及一个SurfaceLayer对象的。这个SurfaceLayer对象创建完成之后,WindowManagerService服务就会将它封装在一个Java层的Surface对象中,以后就可以通过这个Java层的Surface对象来请求SurfaceFlinger服务设置一个对应的应用程序窗口的属性。

       由于Java层的Surface对象实现了Parcelable接口,因此,WindowManagerService服务在为一个Activity组件请求SurfaceFlinger服务创建一个Layer对象以及一个SurfaceLayer对象之后,就可以将得到的Java层的Surface对象跨进程地返回给该Activity组件。Activity组件得到这个Surface对象之后,再使用保存在里面的SurfaceLayer对象来初始化与它所对应的一个ViewRoot对象的成员变量mSurface所描述的一个Java层的Surface对象。

       那么,WindowManagerService服务又是什么时候会为一个Activity组件请求SurfaceFlinger服务创建一个Layer对象以及一个SurfaceLayer对象呢?ViewRoot类有一个类型为IWindowSession的静态成员变量sWindowSession,它指向的实际上是一个实现了IWindowSession接口的Binder对象。这个Binder对象的类型为Session,运行在WindowManagerService服务这一侧。当一个Activity组件的UI第一次要被绘制之前,它所运行在的应用程序进程就会通过ViewRoot类的静态成员变量sWindowSession来向WindowManagerService服务发送一个请求。WindowManagerService服务接收到这个请求之后,再请求SurfaceFlinger服务为这个Activity组件创建一个Layer对象以及一个SurfaceLayer对象。这样,这个Activity组件的UI才能真正地绘制在屏幕中。

       至此,我们就简要分析完成了在Android应用程序这一侧的Activity组件与UI相关的类的实现,接下来我们继续分析在WindowManagerService服务这一侧的WindowState类的实现。

       WindowState类的实现如图7所示:

1353087795_6634.jpg

图7 WindowState类的实现

       在Android应用程序这一侧,每一个Activity组件在WindowManagerService服务这一侧都有一个对应的WindowState对象,用来描述Activity组件的窗口状态。WindowState类有两个重要的成员变量mSession和mSurface,它们的类型分别为SurfaceSession和Surface。接下来,我们就描述这两个成员变量的作用。

       前面提到,Activity组件是在启动完成之后,请求WindowManagerService服务为它创建一个WindowState对象的。创建完成这个WindowState对象之后,WindowManagerService服务再调用它的成员函数attach来为它附加一个SurfaceSession对象。WindowState类的成员函数attach又是通过调用它的成员变量mSession所描述的一个Session对象的成员函数windowAddedLocked来附加一个SurfaceSession对象的。

       Session类有一个类型为SurfaceSession的成员变量mSurfaceSession。当WindowState类的成员函数attach调用Session类的成员函数windowAddedLocked来为一个WindowState对象附加一个SurfaceSession对象的时候,后者首先会检查它的成员变量mSurfaceSession是否已经指向了一个SurfaceSession对象。如果如果指向了的话,那么Session类的成员函数windowAddedLocked就什么也不用做,否则的话,Session类的成员函数windowAddedLocked就会创建一个SurfaceSession对象,并且保存在它的成员变量mSurfaceSession中。

       SurfaceSession类有一个类型为int的成员变量mClient,它保存的是一个C++层的SurfaceComposerClient对象的地址,即每一个Java层的SurfaceSession对象在C++层都有一个对应的SurfaceComposerClient对象。当一个SurfaceSession对象创建的时候,与它所关联的SurfaceComposerClient对象也会同时被创建。从前面Android应用程序与SurfaceFlinger服务的连接过程分析一文可以知道,SurfaceComposerClient类用来描述Android应用程序进程与SurfaceFlinger服务之间的一个连接,即每一个与UI相关的Android应用程序进程都有一个SurfaceComposerClient对象。

       读者可能会觉得奇怪,既然SurfaceComposerClient是用来描述Android应用程序进程与SurfaceFlinger服务的连接的,那么为什么WindowManagerService服务会在内部创建SurfaceComposerClient对象呢?由于WindowManagerService需要请求SurfaceFlinger服务来设置Android应用程序窗口的属性,例如,设置应用程序窗口的位置、大小等,因此,它就需要为每一个Android应用程序进程创建一个SurfaceComposerClient对象连接到SurfaceFlinger服务中去,以便可以和SurfaceFlinger服务进行通信。

       从上面的描述我们就可以知道,在WindowManagerService服务中,每一个Android应用程序进程都对应有一个SurfaceComposerClient对象。由于每一个SurfaceComposerClient对象都关联有一个SurfaceSession对象,因此,我们又可以推断出每一个Android应用程序进程在WindowManagerService服务中都对应有一个SurfaceSession对象。由于每一个SurfaceSession对象所属的Session对象是一个Binder本地对象,并且它的Binder代理对象是保存在Android应用程序进程这一侧的ViewRoot类的静态成员变量sWindowSession中,因此,我们又可以推断出每一个Android应用程序进程在WindowManagerService服务都有一个对应的Session对象。综合起来就是,每一个Android应用程序进程在WindowManagerService服务这一侧对应有一个Session对象、一个SurfaceSession对象以及一个SurfaceComposerClient对象。由于每一个Android应用程序进程都可以运行若干个Activity组件,因此,我们又可以说,Activity组件与WindowServiceManager服务这一侧的Session对象、SurfaceSession对象以及SurfaceComposerClient对象是多对一的关系。

       介绍了WindowState类的成员变量mSession之后,我们接着介绍另外一个成员变量mSurface,它的类型为Surface,前面我们已经介绍过Surface类在Android应用程序进程这一侧的作用了,接下来我们就介绍它在WindowManagerService这一侧的作用。

      前面提到,WindowManagerService服务会在内部为每一个应用程序窗口,即每一个Activity组件,创建一个SurfaceLayer对象,这个SurfaceLayer对象是封装成一个Java层的Surface对象中的。在Java层的Surface类中,有一个类型为int的成员变量mSurfaceControl,它保存的是在C++层的一个SurfaceControl对象的地址值,即在WindowManagerService服务这一侧,每一个Java层的Surface对象在 C++层都有一个对应的SurfaceControl对象。这里我们强调是在WindowManagerService服务这一侧,是因为在前面提到,在Android应用程序这一侧,每一个Activity组件所对应的Java层的Surface对象在C++层是没有一个对应的SurfaceControl对象,而只是对应有一个C++层的Surface对象。通过C++层的SurfaceControl对象可以设置应用程序窗口的属性,而通过C++层的Surface对象则可以设置应用程序窗口的图形缓冲区,即设置应用程序窗口的纹理,因此,我们就可以知道应用程序窗口的属性是由WindowManagerService服务来设置的,而应用程序窗口的纹理是由它所在的进程负责设置的。

      至此,我们就简要地介绍了Android应用程序窗口的实现框架了。上面所介绍的类及其交互关系可能会比较模糊,不易理解。不要紧,接下来我们会通过一系列的文章来弄清楚它们的来龙去脉:


      学习了这些文章,我们就可以掌握Android应用程序窗口的实现框架了。掌握了Android应用程序窗口的实现框架之后,我们就可以再进一步去详细地学习Android应用程序窗口的渲染过程。敬请关注!





本文转自 Luoshengyang 51CTO博客,原文链接:http://blog.51cto.com/shyluo/1242736,如需转载请自行联系原作者

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享: