- 浏览: 23891 次
- 性别:
- 来自: 北京
最新评论
我们从SurfaceComposerClient对象的创建开始分析应用程序与SurfaceFlinger的连接过程.每一个需要SurfaceFlinger渲染的应用程序都会创建一个SurfaceComposerClient对象,是这样么,我不确定,需要验证.
SurfaceComposerClient类的声明(在SurfaceComposerClient.h文件中)如下:
class SurfaceComposerClient : public RefBase
SurfaceComposerClient类的构造函数定义如下:
SurfaceComposerClient::SurfaceComposerClient()
: mStatus(NO_INIT), mComposer(Composer::getInstance())
{
}
关于SurfaceComposerClient类的构造函数的详细分析可以参考page2文件.
因为SurfaceComposerClient继承自RefBase,那么当只能指针第一次被引用时,就会调用onFirstRef函数, 我们就来看一下SurfaceComposerClient的onFirstRef函数的实现:
1void SurfaceComposerClient::onFirstRef() {
2 sp<ISurfaceComposer> sm(ComposerService::getComposerService());
3 if (sm != 0) {
4 sp<ISurfaceComposerClient> conn = sm->createConnection();
5 if (conn != 0) {
6 mClient = conn;
7 mStatus = NO_ERROR;
8 }
9 }
10}
关于SurfaceComposerClient的onFirstRef函数的实现的分析,可以参考page3文件.
当调用完onFirstRef函数之后, SurfaceComposerClient对象的成员变量mClient就被初始化指向一个ISurfaceComposerClient的Binder代理对象,这样SurfaceComposerClient对象就能通过这个ISurfaceComposerClient接口来请求SurfaceFlinger的服务了.
以上就是应用程序与SurfaceFlinger服务的连接过程的分析, 通过以上的分析, 我们可以得出以下结论:
No.1 每一个需要渲染UI的应用程序都会创建一个SurfaceComposerClient对象. 这是正确的么?
No.2 每一个需要SurfaceFlinger服务的应用程序都会在SurfaceFlinger这一侧创建一个Client对象, 并在应用程序这一侧拿到一个ISurfaceComposerClient类型的Binder代理对象.
SurfaceComposerClient类的构造函数定义如下:
SurfaceComposerClient::SurfaceComposerClient()
: mStatus(NO_INIT), mComposer(Composer::getInstance())
{
}
在SurfaceComposerClient类中一个成员变量mComposer, 类型为Composer类的一个引用, 定义如下:
Composer& mComposer;
那么这个mComposer的作用是什么呢?且慢, 我们一点点的来分析.
我们先来看一下Composer类的定义,
Composer类的声明如下:
class Composer : public Singleton<Composer>
由此可见Composer是一个单例的.
Composer的构造函数定义如下:
Composer() : Singleton<Composer>(),
mForceSynchronous(0), mTransactionNestCount(0),
mAnimation(false)
{
}
我们还是不知道mComposer是干什么的啊?那日后在分析吧.^-^
SurfaceComposerClient的onFirstRef函数的实现如下
1void SurfaceComposerClient::onFirstRef() {
2 sp<ISurfaceComposer> sm(ComposerService::getComposerService());
3 if (sm != 0) {
4 sp<ISurfaceComposerClient> conn = sm->createConnection();
5 if (conn != 0) {
6 mClient = conn;
7 mStatus = NO_ERROR;
8 }
9 }
10}
第一行(SurfaceComposerClient::onFirstRef)首先调用ComposerService::getComposerService()来获得一个ISurfaceComposer的Binder代理对象.
我们首先看一下ComposerService类的声明,位于frameworks/native/include/private/gui/ComposerService.h文件中:
class ComposerService : public Singleton<ComposerService>
由此可见, ComposerService是一个单例的.
分析完ComposerService类的声明, 我们看一下ComposerService的getComposerService函数的实现, 位于frameworks/native/libs/gui/SurfaceComposerClient.cpp文件中, 定义如下:
1sp<ISurfaceComposer> ComposerService::getComposerService() {
2 ComposerService& instance = ComposerService::getInstance();
3 Mutex::Autolock _l(instance.mLock);
4 if (instance.mComposerService == NULL) {
5 ComposerService::getInstance().connectLocked();
6 assert(instance.mComposerService != NULL);
7 ALOGD("ComposerService reconnected");
8 }
9 return instance.mComposerService;
10}
ComposerService的getComposerService函数的主要逻辑是得到ComposerService实例,并判断ComposerService实例的mComposerService是否为null, 如果是则表示还没有得到SurfaceFlinger服务,那么就会调用ComposerService实例的connectLocked函数来得到SurfaceFlinger服务, 如果不为null, 表示已经获得了SurfaceFlinger服务,那么直接返回SurfaceFlinger.
所以我们接下来看一下ComposerService的connectLocked函数的实现, 位于frameworks/native/libs/gui/SurfaceComposerClient.cpp文件中, 定义如下:
void ComposerService::connectLocked() {
const String16 name("SurfaceFlinger");
while (getService(name, &mComposerService) != NO_ERROR) {
usleep(250000);
}
assert(mComposerService != NULL);
// Create the death listener.
class DeathObserver : public IBinder::DeathRecipient {
ComposerService& mComposerService;
virtual void binderDied(const wp<IBinder>& who) {
ALOGW("ComposerService remote (surfaceflinger) died [%p]",
who.unsafe_get());
mComposerService.composerServiceDied();
}
public:
DeathObserver(ComposerService& mgr) : mComposerService(mgr) { }
};
mDeathObserver = new DeathObserver(*const_cast<ComposerService*>(this));
IInterface::asBinder(mComposerService)->linkToDeath(mDeathObserver);
}
在ComposerService的connectLocked函数中, 主要完成了两件事: 第一,不断地从ServiceManager中获取SurfaceFlinger服务. 第二, 注册一个Binder死亡通知.
我们回到SurfaceComposerClient::onFirstRef函数的分析中, 当得到SurfaceFlinger服务之后, 第4-8行(SurfaceComposerClient::onFirstRef)会调用SurfaceFlinger的createConnection函数,createConnection函数的定义如下:
1sp<ISurfaceComposerClient> SurfaceFlinger::createConnection()
2{
3 sp<ISurfaceComposerClient> bclient;
4 sp<Client> client(new Client(this));
5 status_t err = client->initCheck();
6 if (err == NO_ERROR) {
7 bclient = client;
8 }
9 return bclient;
10}
createConnection函数的详细分析可以参考page4文件。
第6行(SurfaceComposerClient::onFirstRef)就把createConnection函数返回的ISurfaceComposerClient的Binder接口保存起来,这样以后就能通过这个接口来请求SurfaceFlinger服务了。
SurfaceFlinger的createConnection函数的实现如下:
1sp<ISurfaceComposerClient> SurfaceFlinger::createConnection()
2{
3 sp<ISurfaceComposerClient> bclient;
4 sp<Client> client(new Client(this));
5 status_t err = client->initCheck();
6 if (err == NO_ERROR) {
7 bclient = client;
8 }
9 return bclient;
10}
第4行(SurfaceFlinger::createConnection)首先创建了一个Client类型的对象,传入的参数就是SurfaceFlinger对象。
Client类的声明如下,位于frameworks/native/services/surfaceflinger/Client.h文件中:
class Client : public BnSurfaceComposerClient
由此可见Client是一个Binder的本地对象。
Client类的构造函数定义如下, 位于frameworks/native/services/surfaceflinger/Client.cpp:
1Client::Client(const sp<SurfaceFlinger>& flinger)
2: mFlinger(flinger), mNameGenerator(1)
3{
4}
Client的构造函数只是将Client的成员变量mFlinger指向SurfaceFlinger服务。
当构造完Client对象之后, 会在第5行(SurfaceFlinger::createConnection)调用Client的initCheck函数,initCheck的函数的定义如下:
status_t Client::initCheck() const {
return NO_ERROR;
}
可以看到initCheck函数只是简单的返回了NO_ERROR。
最后会返回这个Client对象。
由此可见, 每一个与SurfaceFlinger连接的应用程序在SurfaceFlinger这一侧都会有一个Client对象,也就是ISurfaceComposerClient的Binder本地对象。
最后将这个ISurfaceComposerClient的Binder接口返回给应用程序,这样应用程序就可以用这个Binder接口来请求SurfaceFlinger为其服务了,这样应用程序就和SurfaceFlinger建立了连接。
SurfaceComposerClient类的声明(在SurfaceComposerClient.h文件中)如下:
class SurfaceComposerClient : public RefBase
SurfaceComposerClient类的构造函数定义如下:
SurfaceComposerClient::SurfaceComposerClient()
: mStatus(NO_INIT), mComposer(Composer::getInstance())
{
}
关于SurfaceComposerClient类的构造函数的详细分析可以参考page2文件.
因为SurfaceComposerClient继承自RefBase,那么当只能指针第一次被引用时,就会调用onFirstRef函数, 我们就来看一下SurfaceComposerClient的onFirstRef函数的实现:
1void SurfaceComposerClient::onFirstRef() {
2 sp<ISurfaceComposer> sm(ComposerService::getComposerService());
3 if (sm != 0) {
4 sp<ISurfaceComposerClient> conn = sm->createConnection();
5 if (conn != 0) {
6 mClient = conn;
7 mStatus = NO_ERROR;
8 }
9 }
10}
关于SurfaceComposerClient的onFirstRef函数的实现的分析,可以参考page3文件.
当调用完onFirstRef函数之后, SurfaceComposerClient对象的成员变量mClient就被初始化指向一个ISurfaceComposerClient的Binder代理对象,这样SurfaceComposerClient对象就能通过这个ISurfaceComposerClient接口来请求SurfaceFlinger的服务了.
以上就是应用程序与SurfaceFlinger服务的连接过程的分析, 通过以上的分析, 我们可以得出以下结论:
No.1 每一个需要渲染UI的应用程序都会创建一个SurfaceComposerClient对象. 这是正确的么?
No.2 每一个需要SurfaceFlinger服务的应用程序都会在SurfaceFlinger这一侧创建一个Client对象, 并在应用程序这一侧拿到一个ISurfaceComposerClient类型的Binder代理对象.
SurfaceComposerClient类的构造函数定义如下:
SurfaceComposerClient::SurfaceComposerClient()
: mStatus(NO_INIT), mComposer(Composer::getInstance())
{
}
在SurfaceComposerClient类中一个成员变量mComposer, 类型为Composer类的一个引用, 定义如下:
Composer& mComposer;
那么这个mComposer的作用是什么呢?且慢, 我们一点点的来分析.
我们先来看一下Composer类的定义,
Composer类的声明如下:
class Composer : public Singleton<Composer>
由此可见Composer是一个单例的.
Composer的构造函数定义如下:
Composer() : Singleton<Composer>(),
mForceSynchronous(0), mTransactionNestCount(0),
mAnimation(false)
{
}
我们还是不知道mComposer是干什么的啊?那日后在分析吧.^-^
SurfaceComposerClient的onFirstRef函数的实现如下
1void SurfaceComposerClient::onFirstRef() {
2 sp<ISurfaceComposer> sm(ComposerService::getComposerService());
3 if (sm != 0) {
4 sp<ISurfaceComposerClient> conn = sm->createConnection();
5 if (conn != 0) {
6 mClient = conn;
7 mStatus = NO_ERROR;
8 }
9 }
10}
第一行(SurfaceComposerClient::onFirstRef)首先调用ComposerService::getComposerService()来获得一个ISurfaceComposer的Binder代理对象.
我们首先看一下ComposerService类的声明,位于frameworks/native/include/private/gui/ComposerService.h文件中:
class ComposerService : public Singleton<ComposerService>
由此可见, ComposerService是一个单例的.
分析完ComposerService类的声明, 我们看一下ComposerService的getComposerService函数的实现, 位于frameworks/native/libs/gui/SurfaceComposerClient.cpp文件中, 定义如下:
1sp<ISurfaceComposer> ComposerService::getComposerService() {
2 ComposerService& instance = ComposerService::getInstance();
3 Mutex::Autolock _l(instance.mLock);
4 if (instance.mComposerService == NULL) {
5 ComposerService::getInstance().connectLocked();
6 assert(instance.mComposerService != NULL);
7 ALOGD("ComposerService reconnected");
8 }
9 return instance.mComposerService;
10}
ComposerService的getComposerService函数的主要逻辑是得到ComposerService实例,并判断ComposerService实例的mComposerService是否为null, 如果是则表示还没有得到SurfaceFlinger服务,那么就会调用ComposerService实例的connectLocked函数来得到SurfaceFlinger服务, 如果不为null, 表示已经获得了SurfaceFlinger服务,那么直接返回SurfaceFlinger.
所以我们接下来看一下ComposerService的connectLocked函数的实现, 位于frameworks/native/libs/gui/SurfaceComposerClient.cpp文件中, 定义如下:
void ComposerService::connectLocked() {
const String16 name("SurfaceFlinger");
while (getService(name, &mComposerService) != NO_ERROR) {
usleep(250000);
}
assert(mComposerService != NULL);
// Create the death listener.
class DeathObserver : public IBinder::DeathRecipient {
ComposerService& mComposerService;
virtual void binderDied(const wp<IBinder>& who) {
ALOGW("ComposerService remote (surfaceflinger) died [%p]",
who.unsafe_get());
mComposerService.composerServiceDied();
}
public:
DeathObserver(ComposerService& mgr) : mComposerService(mgr) { }
};
mDeathObserver = new DeathObserver(*const_cast<ComposerService*>(this));
IInterface::asBinder(mComposerService)->linkToDeath(mDeathObserver);
}
在ComposerService的connectLocked函数中, 主要完成了两件事: 第一,不断地从ServiceManager中获取SurfaceFlinger服务. 第二, 注册一个Binder死亡通知.
我们回到SurfaceComposerClient::onFirstRef函数的分析中, 当得到SurfaceFlinger服务之后, 第4-8行(SurfaceComposerClient::onFirstRef)会调用SurfaceFlinger的createConnection函数,createConnection函数的定义如下:
1sp<ISurfaceComposerClient> SurfaceFlinger::createConnection()
2{
3 sp<ISurfaceComposerClient> bclient;
4 sp<Client> client(new Client(this));
5 status_t err = client->initCheck();
6 if (err == NO_ERROR) {
7 bclient = client;
8 }
9 return bclient;
10}
createConnection函数的详细分析可以参考page4文件。
第6行(SurfaceComposerClient::onFirstRef)就把createConnection函数返回的ISurfaceComposerClient的Binder接口保存起来,这样以后就能通过这个接口来请求SurfaceFlinger服务了。
SurfaceFlinger的createConnection函数的实现如下:
1sp<ISurfaceComposerClient> SurfaceFlinger::createConnection()
2{
3 sp<ISurfaceComposerClient> bclient;
4 sp<Client> client(new Client(this));
5 status_t err = client->initCheck();
6 if (err == NO_ERROR) {
7 bclient = client;
8 }
9 return bclient;
10}
第4行(SurfaceFlinger::createConnection)首先创建了一个Client类型的对象,传入的参数就是SurfaceFlinger对象。
Client类的声明如下,位于frameworks/native/services/surfaceflinger/Client.h文件中:
class Client : public BnSurfaceComposerClient
由此可见Client是一个Binder的本地对象。
Client类的构造函数定义如下, 位于frameworks/native/services/surfaceflinger/Client.cpp:
1Client::Client(const sp<SurfaceFlinger>& flinger)
2: mFlinger(flinger), mNameGenerator(1)
3{
4}
Client的构造函数只是将Client的成员变量mFlinger指向SurfaceFlinger服务。
当构造完Client对象之后, 会在第5行(SurfaceFlinger::createConnection)调用Client的initCheck函数,initCheck的函数的定义如下:
status_t Client::initCheck() const {
return NO_ERROR;
}
可以看到initCheck函数只是简单的返回了NO_ERROR。
最后会返回这个Client对象。
由此可见, 每一个与SurfaceFlinger连接的应用程序在SurfaceFlinger这一侧都会有一个Client对象,也就是ISurfaceComposerClient的Binder本地对象。
最后将这个ISurfaceComposerClient的Binder接口返回给应用程序,这样应用程序就可以用这个Binder接口来请求SurfaceFlinger为其服务了,这样应用程序就和SurfaceFlinger建立了连接。
发表评论
-
Activity与WindowManagerService连接的过程(三)
2018-04-16 16:27 622page11 WindowManagerService ... -
Activity与WindowManagerService连接的过程(二)
2018-04-16 16:36 770page6 WindowManagerGlobal的getW ... -
Activity与WindowManagerService连接的过程(一)
2018-04-16 16:21 987page1 Activity组件在 ... -
Activity的ViewRoot的创建过程(三)
2017-11-06 14:25 742page7 在这篇文章里, 我们分析一下W类的构造过程. W ... -
Activity的ViewRoot的创建过程(二)
2017-11-06 14:29 941page4 我们看一下ViewRootImpl对象的创 ... -
Activity的ViewRoot的创建过程(一)
2017-11-06 14:27 1079page1 当一个Activity第一次激活的时候会为该Ac ... -
Activity的Window和WindowManager的创建过程(三)
2017-07-05 11:49 1334page9 在这里我们分析一下DisplayManager的 ... -
Activity的Window和WindowManager的创建过程(二)
2017-07-05 11:31 548page5 在这篇文章中, 我们分析一下ContextImp ... -
Activity的Window和WindowManager的创建过程(一)
2017-07-05 11:27 607page1 我们开始分析一下Activity的Window和 ... -
Acitivy创建Context的过程(二)
2017-06-21 14:11 514page4 在这里我们分析一下ContextImpl的ini ... -
Acitivy创建Context的过程(一)
2017-06-21 14:15 639page1 从本篇文章开始,我们分析一下Activity创建 ... -
Android源码之SurfaceFlinger的启动(三)
2017-04-20 11:09 1046page11 我们来看一下SurfaceFlinger ... -
Android源码之SurfaceFlinger的启动(二)
2017-04-18 15:15 883page6 我们看一下Thread的run函数的实现: ... -
Android源码之SurfaceFlinger的启动(一)
2017-04-17 10:07 1000page1 在Android系统中, 显示系统在底层是通过S ... -
Android源码之Zygote
2015-12-15 11:45 519当ActivityManagerService启动一个应用程序 ... -
Android源码之Binder(五)
2015-12-04 09:19 1515Service组件在启动时,需要将自己注册到Service M ... -
Android源码之Binder(四)
2015-12-04 09:18 1951case BINDER_SET_MAX_THREADS: ... -
Android源码之Binder(三)
2015-12-04 09:17 910{ int ret; struct binder_pr ... -
Android源码之Binder(二)
2015-12-04 09:15 550分析完Binder驱动程序的打开和内存分配的过程之后,我们看一 ... -
Android源码之Binder(一)
2015-12-04 09:12 996在Android系统中,进程间通信使用的是Binder机制。B ...
相关推荐
- **描述**:在应用程序与SurfaceFlinger建立连接后,每个应用程序的界面都会被映射成一个Layer对象。Layer对象包含了所有关于该Surface的控制信息,例如大小、位置、透明度等。 - **作用**:Layer对象在...
这些库提供了图形渲染所需的API,允许应用程序进行3D图形编程,并与Surface Flinger紧密协作,将应用程序的图形层合成到最终的显示帧上。 总之,Surface Flinger在Android系统中是图形渲染的中枢,它负责合成多个...
- 连接到已配对的蓝牙设备和发现配对新蓝牙设备的权限(BLUETOOTH、BLUETOOTH_ADMIN):允许应用程序访问蓝牙硬件,实现与其他蓝牙设备的交互。 在开发Android应用程序时,了解这些权限是至关重要的。开发者必须在...
此权限允许应用程序使用SurfaceFlinger的低级别特性。 **应用场景:** 这是一项较为特殊的权限,主要用于那些需要直接访问显示硬件的应用程序,例如屏幕截图工具或者一些底层渲染引擎。 #### 七、`ACCESS_WIFI_...
- **Zygote**:Android的初始进程,负责创建应用程序进程。 #### ZygoteService Zygote是Android系统中的一个关键进程,负责为每个应用程序创建一个独立的虚拟机实例。通过这种方式,Zygote提高了应用程序的启动...
Zygote是Android系统中一个特殊的进程,用于启动所有的Java应用程序进程。Zygote Service负责管理Zygote进程的生命周期,并根据请求启动新的应用程序实例。 - **Zygote初始化**:加载Dalvik/ART虚拟机。 - **应用...
- **空间划分的重要性:** 为了提高系统的稳定性和安全性,Android系统将不同的应用程序和服务分配到独立的进程中运行。 - **进程与线程管理:** 深入讨论Android是如何管理和调度进程与线程的,特别是在处理并发...
Android的Framework层作为操作系统的核心组成部分,扮演着连接硬件抽象层(HAL)与应用程序之间的桥梁角色,它不仅提供了丰富的API供开发者调用,还负责管理和调度应用程序的生命周期。本章节深入探讨Android ...
13.2.3 使用am工具启动android应用程序 306 13.3 android应用程序示例 308 13.3.1 helloactivity程序 308 13.3.2 helloactivity的源代码结构 308 13.3.3 helloactivity的编译结构(源代码开发) 312 13.3.4 ...
Android输入系统是一个复杂的过程,它从设备驱动层开始,经过中间层的处理,最终达到应用程序层。 7. 电话系统分析:研究Android电话系统,包括RIL(Radio Interface Layer)以及与电话功能相关的各种组件。RIL是...
应用程序框架是开发者创建应用程序的基础,提供了丰富的API和服务支持。 **应用程序框架分析:** - **无边界设计意图**:强调应用程序之间的互操作性和灵活性。 - **AndroidApplication**:应用程序的入口点,负责...
Android系统是基于Linux内核的开源移动操作系统,主要由应用程序层、应用程序框架层、系统运行库层和Linux内核层构成。源码中包含了这四个层次的代码,涵盖了系统启动、进程管理、内存分配、硬件抽象等多个方面。 ...
2. `android.permission.ACCESS_COARSE_LOCATION`: 应用程序可以通过此权限获取粗略的地理位置信息,如通过Cell-ID(手机信号塔)或WiFi网络定位。这对于需要基本位置信息但不关心精确度的应用很有用,例如天气预报...
- **无边界设计意图**:指在设计应用程序时考虑到与其他组件的交互,确保应用程序能够在各种环境中顺畅运行。 - **AndroidApplication**:基类,提供了应用程序的基本框架和生命周期管理。 - **Activity**:表示...
Zygote是Android系统中的初始进程,负责初始化虚拟机环境并启动其他应用程序进程。通过对ZygoteService的分析,可以了解到它是如何支持多进程管理和资源分配的。 #### 十、AndroidGWES之基本原理篇 GWES即Graphics...
总结来说,Android Binder机制是Android系统中不可或缺的部分,它支撑了系统的组件间通信和应用程序的正常运行。理解Binder的工作原理、服务端和客户端的交互过程,以及如何通过AIDL定义接口,对于Android开发者至关...
#### 应用程序框架与图形显示 - **无边界设计意图**:Android的应用程序框架设计体现了“无边界”的理念,即应用可以在任何场景下无缝切换,提供一致的用户体验。这得益于其强大的组件化和插件化能力。 - **...