原文出处——>[Android应用程序与SurfaceFlinger服务的连接过程分析](http://blog.csdn.net/luoshengyang/article/details/7857163)
前文在描述Android应用程序和SurfaceFlinger服务的关系时提到,每一个有UI的Android应用程序都需要与SurfaceFlinger服务建立一个连接,以便可以通过这个连接来请求SurfaceFlinger服务为它创建和渲染Surface。在本文中,我们将以Android系统的开机动画应用程序为例,详细描述Android应用程序是如何与SurfaceFlinger服务建立连接的。
Android系统的开机动画是由应用程序bootanimation来实现的,它位于/system/bin目录下,它的具体实现可以参考Android系统的开机画面显示过程分析一文。为什么要选择Android系统的开机动画来分析Android应用程序与SurfaceFlinger服务的连接过程呢?首先,负责实现开机动画的应用程序bootanimation也是一个Android应用程序,只不过它是使用C++语言来开发的;其次,应用程序bootanimation是与UI相关的,即它与使用Java语言来开发的标准Android应用程序一样,都需要使用SurfaceFlinger服务来创建和渲染自己的Surface,即开机动画;第三,由于应用程序bootanimation不涉及用户输入,即不需要与用户进行交互(触摸屏、键盘等),因此它能够以最简洁的方式来体现Android应用程序与SurfaceFlinger服务的关系。
从前面Android系统的开机画面显示过程分析一文可以知道,Android系统的开机动画是主要一个BootAnimation对象来实现,这个BootAnimation对象在构造的时候,会在内部创建一个SurfaceComposerClient对象来负责创建一个到SurfaceFlinger服务的连接。
BootAnimation类的构造函数实现在文件frameworks/base/cmds/bootanimation/BootAnimation.cpp中,如下所示:
~~~
BootAnimation::BootAnimation() : Thread(false)
{
mSession = new SurfaceComposerClient();
}
~~~
mSession是BootAnimation类的成员变量,它是一个类型为SurfaceComposerClient的强指针,即`sp<SurfaceComposerClient>`。Android系统的智能指针的相关知识,可以参考Android系统的智能指针(轻量级指针、强指针和弱指针)的实现原理分析一文。
在SurfaceComposerClient类内部,有一个类型为`sp<ISurfaceComposerClient>`的成员变量mClient,如图1所示:
![](https://box.kancloud.cn/01723d1bc7a43c87128da4ec697c2e0b_412x190.jpg)
图1 SurfaceComposerClient的结构示意图
SurfaceComposerClient类的成员变量mClient指向的实际上是一个类型为BpSurfaceComposerClient的Binder代理对象,而这个类型为BpSurfaceComposerClient的Binder代理对象引用的是一个类型为Client的Binder本地对象。在前面Android应用程序与SurfaceFlinger服务的关系概述和学习计划一文中提到,类型为Client的Binder本地对象是由SurfaceFlinger服务来负责创建的,并且运行在SurfaceFlinger服务中,用来代表使用SurfaceFlinger服务的一个客户端,即一个与UI相关的Android应用程序。
由于Client类和BpSurfaceComposerClient类分别是一个Binder本地对象类和一个Binder代理对象类,它们都是根据Android系统在应用程序框架层提供的Binder进程间通信库来实现的,它们的实现结构图分别如图2和图3所示:
![](https://box.kancloud.cn/a35aee032b9eca59bf6769716811358e_673x499.jpg)
图2 Client类的实现结构图
![](https://box.kancloud.cn/ea7b48811994031116a9542bb70fff05_680x494.jpg)
图3 BpSurfaceComposerClient类的实现结构图
在图2和图3中,涉及到了比较多的Binder进程间通信库的类,需要读者对Android系统的Binder进程间通信机制有一定的理解和认识。在前面的Android进程间通信(IPC)机制Binder简要介绍和学习计划一系列文章,我们已经学习过Android系统的Binder进程间通信机制了,这里不再详述。
图2和图3给我们最重要的信息是Client类和BpSurfaceComposerClient类均实现了类型为ISurfaceComposerClient的Binder接口。ISurfaceComposerClient接口有两个重要的成员函数getControlBlock和createSurface,它们定义在文件frameworks/base/include/surfaceflinger/ISurfaceComposerClient.h中,如下所示:
~~~
class ISurfaceComposerClient : public IInterface
{
public:
......
virtual sp<IMemoryHeap> getControlBlock() const = 0;
......
/*
* Requires ACCESS_SURFACE_FLINGER permission
*/
virtual sp<ISurface> createSurface( surface_data_t* data,
int pid,
const String8& name,
DisplayID display,
uint32_t w,
uint32_t h,
PixelFormat format,
uint32_t flags) = 0;
......
};
~~~
其中,成员函数getControlBlock用来获得由SurfaceFlinger服务创建的一块用来传递UI元数据的匿名共享内存,而成员函数createSurface用来请求SurfaceFlinger服务创建一个Surface。从前面Android应用程序与SurfaceFlinger服务的关系概述和学习计划一文可以知道,用来传递UI元数据的匿名共享内存最终会被结构化为一个SharedClient对象,这个SharedClient对象在每个应用程序进程中至多存在一个。在接下来的两篇文章中,我们再详细分析ISurfaceComposerClient接口的成员函数getControlBlock和createSurface的实现。
理解了SurfaceComposerClient、Client以及BpSurfaceComposerClient这三个类的关系之后,接下来我们就可以分析Android系统的开机动画应用程序bootanimation是如何与SurfaceFlinger服务建立连接的。
从图1可以知道,SurfaceComposerClient类继承了RefBase类,因此,当BootAnimation类在构造函数创建了一个SurfaceComposerClient对象,并且将这个对象赋值给类型为sp<SurfaceComposerClient>的智能指针mSession时,就会导致SurfaceComposerClient类的成员函数onFirstRef被调用,而SurfaceComposerClient类的成员函数onFirstRef在调用的过程中,就会在应用程序bootanimation与SurfaceFlinger服务建立一个连接,这个过程如图4所示:
![](https://box.kancloud.cn/8b955c5d25c1ac5882447de59de41866_648x401.jpg)
图4 Android应用程序与SurfaceFlinger服务的连接过程
接下来,我们就详细分析每一个步骤。
Step 1. SurfaceComposerClient::onFirstRef
~~~
void SurfaceComposerClient::onFirstRef()
{
sp<ISurfaceComposer> sm(getComposerService());
if (sm != 0) {
sp<ISurfaceComposerClient> conn = sm->createConnection();
if (conn != 0) {
mClient = conn;
......
mStatus = NO_ERROR;
}
}
}
~~~
SurfaceComposerClient类的成员函数onFirstRef实现在文件frameworks/base/libs/surfaceflinger_client/SurfaceComposerClient.cpp文件中。
SurfaceComposerClient类的成员函数getComposerService用来获得SurfaceFlinger服务的一个代理接口,它的实现如下所示:
~~~
sp<ISurfaceComposer> ComposerService::getComposerService() {
return ComposerService::getInstance().mComposerService;
}
~~~
ComposerService类是单例模式,当我们第一次调用它的静态函数getInstance的时候,它就会在构造函数中获得SurfaceFlinger服务的一个代理接口,并且保存在它的成员变量mComposerService中,如下所示:
~~~
ComposerService::ComposerService()
: Singleton<ComposerService>() {
const String16 name("SurfaceFlinger");
while (getService(name, &mComposerService) != NO_ERROR) {
usleep(250000);
}
mServerCblkMemory = mComposerService->getCblk();
mServerCblk = static_cast<surface_flinger_cblk_t volatile *>(
mServerCblkMemory->getBase());
}
~~~
在ComposerService类的构造函数中,除了会获得SurfaceFlinger服务的代理接口之外,还会通过这个代理接口的成员函数getCblk来获得一块匿名共享内存mServerCblkMemory。这块匿名共享内存是由SurfaceFlinger服务创建的,用来描述系统显示屏的信息,例如,显示屏的个数、大小、方向、密度等等信息。由于这些信息可以通过一个surface_flinger_cblk_t对象来描述,因此,ComposerService类的构造函数最后就将前面从SurfaceFlinger服务获得的一块匿名共享内存结构化为一个surface_flinger_cblk_t对象,并且保存在ComposerService类的成员变量mServerCblk中。
回到SurfaceComposerClient类的成员函数onFirstRef中,由于SurfaceFlinger服务实现了ISurfaceComposer接口,因此,我们可以将前面获得的SurfaceFlinger服务的代理接口赋值给一个类型为ISurfaceComposer的强指针sm,并且调用它的成员函数createConnection来请求SurfaceFlinger服务创建一个连接,即创建一个类型为Client的Binder对象,并且将这个Binder对象的一个代理接口conn返回来。SurfaceComposerClient类获得了SurfaceFlinger服务返回来的Client代理接口conn之后,就将它保存自己的成员变量mClient中,这样开机动画应用程序bootanimation后续就可以通过它来请求SurfaceFlinger创建和渲染Surface了。
接下来,我们就继续分析SurfaceFlinger服务的成员函数createConnection的实现,以便可以了解它是如何为Android应用程序创建一个连接的。
Step 2. SurfaceFlinger::createConnection
~~~
sp<ISurfaceComposerClient> SurfaceFlinger::createConnection()
{
sp<ISurfaceComposerClient> bclient;
sp<Client> client(new Client(this));
status_t err = client->initCheck();
if (err == NO_ERROR) {
bclient = client;
}
return bclient;
}
~~~
SurfaceFlinger类的成员函数createConnection实现在文件frameworks/base/services/surfaceflinger/SurfaceFlinger.cpp中,它的实现很简单,只是创建了一个类型为Client的Binder对象client,并且获得它的一个ISurfaceComposerClient接口,最后将这个ISurfaceComposerClient接口,即一个Client代理对象,返回给开机动画应用程序bootanimation。
接下来,我们再继续分析Client对象的创建过程,,即Client类的构造函数的实现。
Step 3. new Client
~~~
Client::Client(const sp<SurfaceFlinger>& flinger)
: mFlinger(flinger), mNameGenerator(1)
{
}
~~~
Client类有两个成员变量mFlinger和mNameGenerator,它们的类型分别为sp<SurfaceFlinger>和int32_t,前者指向了SurfaceFlinger服务,而后者用来生成SurfaceFlinger服务为Android应用程序所创建的每一个Surface的名称。例如,假设一个Android应用程序请求SurfaceFlinger创建了两个Surface,那么第一个Surface的名称就由数字1来描述,而第二个Surface就由数字2来描述,依次类推。从前面Android应用程序与SurfaceFlinger服务的关系概述和学习计划这篇文章可以知道,一个Android应用程序最多可以创建31个Surface。
回到SurfaceFlinger类的成员函数createConnection中,它将一个指向了一个Client对象的ISurfaceComposerClient接口返回到开机动画应用程序bootanimation之后,开机动画应用程序bootanimation就可以将它封装成一个类型为BpSurfaceComposerClient的Binder代理对象。
Step 4. return BpSurfaceComposerClient
类型为BpSurfaceComposerClient的Binder代理对象的封装过程实现在SurfaceFlinger服务的Binder代理对象类BpSurfaceComposer的成员函数createConnection中,如下所示:
~~~
class BpSurfaceComposer : public BpInterface<ISurfaceComposer>
{
public:
......
virtual sp<ISurfaceComposerClient> createConnection()
{
uint32_t n;
Parcel data, reply;
data.writeInterfaceToken(ISurfaceComposer::getInterfaceDescriptor());
remote()->transact(BnSurfaceComposer::CREATE_CONNECTION, data, &reply);
return interface_cast<ISurfaceComposerClient>(reply.readStrongBinder());
}
......
}
~~~
interface_cast是一个模板函数,它定义在framework/base/include/binder/IInterface.h文件中:
~~~
template<typename INTERFACE>
inline sp<INTERFACE> interface_cast(const sp<IBinder>& obj)
{
return INTERFACE::asInterface(obj);
}
~~~
从这里就可以看出,当模板参数为ISurfaceComposerClient的时候,模板函数interface_cast实际就是通过调用ISurfaceComposerClient类的静态成员函数asInterface来将参数obj所描述的一个Binder代理对象,即一个BpBinder对象,封装成一个BpSurfaceComposerClient对象。
ISurfaceComposerClient类的静态成员函数asInterface是由frameworks/base/libs/surfaceflinger_client/ISurfaceComposerClient.cpp文件中的IMPLEMENT_META_INTERFACE宏来定义的,如下所示:
~~~
IMPLEMENT_META_INTERFACE(SurfaceComposerClient, "android.ui.ISurfaceComposerClient");
~~~
IMPLEMENT_META_INTERFACE宏展开后,得到ISurfaceComposerClient类的静态成员函数asInterface的实现如下所示:
~~~
android::sp<ISurfaceComposerClient> ISurfaceComposerClient::asInterface(const android::sp<android::IBinder>& obj) {
android::sp<ISurfaceComposerClient> intr;
if (obj != NULL) {
intr = static_cast<ISurfaceComposerClient*>(
obj->queryLocalInterface(ISurfaceComposerClient::descriptor).get());
if (intr == NULL) {
intr = new BpSurfaceComposerClient(obj);
}
}
return intr;
}
~~~
参数obj是从BpSurfaceComposer类的成员函数createConnection传进来的,它指向的实际上是一个BpBinder对象。当我们调用一个BpBinder对象的成员函数queryLocalInterface时,获得的是一个NULL指针,因此,ISurfaceComposerClient类的静态成员函数asInterface最后就会将参数obj所指向的一个BpBinder对象封装成一个BpSurfaceComposerClient对象,并且返回给调用者。
BpSurfaceComposerClient对象的更具体封装过程可以参考前面浅谈Android系统进程间通信(IPC)机制Binder中的Server和Client获得Service Manager接口之路一文中所描述的BpServiceManager对象的封装过程。
至此,开机动画应用程序bootanimation就通过SurfaceComposerClient类来与SurfaceFlinger服务建立一个连接了。
在前面Android应用程序与SurfaceFlinger服务的关系概述和学习计划一文中提到,一个Android应用程序除了需要与SurfaceFlinger服务建立连接之外,还需要有一块用来传递UI元数据的匿名共享内存,即一个SharedClient对象,因此,在接下来的一篇文章中,我们就继续分析这块匿名共享内存的创建过程,敬请期待!
- 前言
- Android组件设计思想
- Android源代码开发和调试环境搭建
- Android源代码下载和编译
- Android源代码情景分析法
- Android源代码调试分析法
- 手把手教你为手机编译ROM
- 在Ubuntu上下载、编译和安装Android最新源代码
- 在Ubuntu上下载、编译和安装Android最新内核源代码(Linux Kernel)
- 如何单独编译Android源代码中的模块
- 在Ubuntu上为Android系统编写Linux内核驱动程序
- 在Ubuntu上为Android系统内置C可执行程序测试Linux内核驱动程序
- 在Ubuntu上为Android增加硬件抽象层(HAL)模块访问Linux内核驱动程序
- 在Ubuntu为Android硬件抽象层(HAL)模块编写JNI方法提供Java访问硬件服务接口
- 在Ubuntu上为Android系统的Application Frameworks层增加硬件访问服务
- 在Ubuntu上为Android系统内置Java应用程序测试Application Frameworks层的硬件服务
- Android源代码仓库及其管理工具Repo分析
- Android编译系统简要介绍和学习计划
- Android编译系统环境初始化过程分析
- Android源代码编译命令m/mm/mmm/make分析
- Android系统镜像文件的打包过程分析
- 从CM刷机过程和原理分析Android系统结构
- Android系统架构概述
- Android系统整体架构
- android专用驱动
- Android硬件抽象层HAL
- Android应用程序组件
- Android应用程序框架
- Android用户界面架构
- Android虚拟机之Dalvik虚拟机
- Android硬件抽象层
- Android硬件抽象层(HAL)概要介绍和学习计划
- Android专用驱动
- Android Logger驱动系统
- Android日志系统驱动程序Logger源代码分析
- Android应用程序框架层和系统运行库层日志系统源代码分析
- Android日志系统Logcat源代码简要分析
- Android Binder驱动系统
- Android进程间通信(IPC)机制Binder简要介绍和学习计划
- 浅谈Service Manager成为Android进程间通信(IPC)机制Binder守护进程之路
- 浅谈Android系统进程间通信(IPC)机制Binder中的Server和Client获得Service Manager接口之路
- Android系统进程间通信(IPC)机制Binder中的Server启动过程源代码分析
- Android系统进程间通信(IPC)机制Binder中的Client获得Server远程接口过程源代码分析
- Android系统进程间通信Binder机制在应用程序框架层的Java接口源代码分析
- Android Ashmem驱动系统
- Android系统匿名共享内存Ashmem(Anonymous Shared Memory)简要介绍和学习计划
- Android系统匿名共享内存Ashmem(Anonymous Shared Memory)驱动程序源代码分析
- Android系统匿名共享内存Ashmem(Anonymous Shared Memory)在进程间共享的原理分析
- Android系统匿名共享内存(Anonymous Shared Memory)C++调用接口分析
- Android应用程序进程管理
- Android应用程序进程启动过程的源代码分析
- Android系统进程Zygote启动过程的源代码分析
- Android系统默认Home应用程序(Launcher)的启动过程源代码分析
- Android应用程序消息机制
- Android应用程序消息处理机制(Looper、Handler)分析
- Android应用程序线程消息循环模型分析
- Android应用程序输入事件分发和处理机制
- Android应用程序键盘(Keyboard)消息处理机制分析
- Android应用程序UI架构
- Android系统的开机画面显示过程分析
- Android帧缓冲区(Frame Buffer)硬件抽象层(HAL)模块Gralloc的实现原理分析
- SurfaceFlinger
- Android系统Surface机制的SurfaceFlinger服务
- SurfaceFlinger服务简要介绍和学习计划
- 启动过程分析
- 对帧缓冲区(Frame Buffer)的管理分析
- 线程模型分析
- 渲染应用程序UI的过程分析
- Android应用程序与SurfaceFlinger服务的关系
- 概述和学习计划
- 连接过程分析
- 共享UI元数据(SharedClient)的创建过程分析
- 创建Surface的过程分析
- 渲染Surface的过程分析
- Android应用程序窗口(Activity)
- 实现框架简要介绍和学习计划
- 运行上下文环境(Context)的创建过程分析
- 窗口对象(Window)的创建过程分析
- 视图对象(View)的创建过程分析
- 与WindowManagerService服务的连接过程分析
- 绘图表面(Surface)的创建过程分析
- 测量(Measure)、布局(Layout)和绘制(Draw)过程分析
- WindowManagerService
- WindowManagerService的简要介绍和学习计划
- 计算Activity窗口大小的过程分析
- 对窗口的组织方式分析
- 对输入法窗口(Input Method Window)的管理分析
- 对壁纸窗口(Wallpaper Window)的管理分析
- 计算窗口Z轴位置的过程分析
- 显示Activity组件的启动窗口(Starting Window)的过程分析
- 切换Activity窗口(App Transition)的过程分析
- 显示窗口动画的原理分析
- Android控件TextView的实现原理分析
- Android视图SurfaceView的实现原理分析
- Android应用程序UI硬件加速渲染
- 简要介绍和学习计划
- 环境初始化过程分析
- 预加载资源地图集服务(Asset Atlas Service)分析
- Display List构建过程分析
- Display List渲染过程分析
- 动画执行过程分析
- Android应用程序资源管理框架
- Android资源管理框架(Asset Manager)
- Asset Manager 简要介绍和学习计划
- 编译和打包过程分析
- Asset Manager的创建过程分析
- 查找过程分析
- Dalvik虚拟机和ART虚拟机
- Dalvik虚拟机
- Dalvik虚拟机简要介绍和学习计划
- Dalvik虚拟机的启动过程分析
- Dalvik虚拟机的运行过程分析
- Dalvik虚拟机JNI方法的注册过程分析
- Dalvik虚拟机进程和线程的创建过程分析
- Dalvik虚拟机垃圾收集机制简要介绍和学习计划
- Dalvik虚拟机Java堆创建过程分析
- Dalvik虚拟机为新创建对象分配内存的过程分析
- Dalvik虚拟机垃圾收集(GC)过程分析
- ART虚拟机
- Android ART运行时无缝替换Dalvik虚拟机的过程分析
- Android运行时ART简要介绍和学习计划
- Android运行时ART加载OAT文件的过程分析
- Android运行时ART加载类和方法的过程分析
- Android运行时ART执行类方法的过程分析
- ART运行时垃圾收集机制简要介绍和学习计划
- ART运行时Java堆创建过程分析
- ART运行时为新创建对象分配内存的过程分析
- ART运行时垃圾收集(GC)过程分析
- ART运行时Compacting GC简要介绍和学习计划
- ART运行时Compacting GC堆创建过程分析
- ART运行时Compacting GC为新创建对象分配内存的过程分析
- ART运行时Semi-Space(SS)和Generational Semi-Space(GSS)GC执行过程分析
- ART运行时Mark-Compact( MC)GC执行过程分析
- ART运行时Foreground GC和Background GC切换过程分析
- Android安全机制
- SEAndroid安全机制简要介绍和学习计划
- SEAndroid安全机制框架分析
- SEAndroid安全机制中的文件安全上下文关联分析
- SEAndroid安全机制中的进程安全上下文关联分析
- SEAndroid安全机制对Android属性访问的保护分析
- SEAndroid安全机制对Binder IPC的保护分析
- 从NDK在非Root手机上的调试原理探讨Android的安全机制
- APK防反编译
- Android视频硬解稳定性问题探讨和处理
- Android系统的智能指针(轻量级指针、强指针和弱指针)的实现原理分析
- Android应用程序安装过程源代码分析
- Android应用程序启动过程源代码分析
- 四大组件源代码分析
- Activity
- Android应用程序的Activity启动过程简要介绍和学习计划
- Android应用程序内部启动Activity过程(startActivity)的源代码分析
- 解开Android应用程序组件Activity的"singleTask"之谜
- Android应用程序在新的进程中启动新的Activity的方法和过程分析
- Service
- Android应用程序绑定服务(bindService)的过程源代码分析
- ContentProvider
- Android应用程序组件Content Provider简要介绍和学习计划
- Android应用程序组件Content Provider应用实例
- Android应用程序组件Content Provider的启动过程源代码分析
- Android应用程序组件Content Provider在应用程序之间共享数据的原理分析
- Android应用程序组件Content Provider的共享数据更新通知机制分析
- BroadcastReceiver
- Android系统中的广播(Broadcast)机制简要介绍和学习计划
- Android应用程序注册广播接收器(registerReceiver)的过程分析
- Android应用程序发送广播(sendBroadcast)的过程分析