应用程序进程与SurfaceFlinger的连接过程

阅读更多
我们从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 sm(ComposerService::getComposerService());
3    if (sm != 0) {
4 sp 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() : Singleton(),
        mForceSynchronous(0), mTransactionNestCount(0),
        mAnimation(false)
    {

}

我们还是不知道mComposer是干什么的啊?那日后在分析吧.^-^

 
SurfaceComposerClient的onFirstRef函数的实现如下
1void SurfaceComposerClient::onFirstRef() {
2    sp sm(ComposerService::getComposerService());
3    if (sm != 0) {
4 sp 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的getComposerService函数的实现, 位于frameworks/native/libs/gui/SurfaceComposerClient.cpp文件中, 定义如下:
1sp 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& who) {
    ALOGW("ComposerService remote (surfaceflinger) died [%p]",
          who.unsafe_get());
    mComposerService.composerServiceDied();
}
     public:
DeathObserver(ComposerService& mgr) : mComposerService(mgr) { }
    };

    mDeathObserver = new DeathObserver(*const_cast(this));
    IInterface::asBinder(mComposerService)->linkToDeath(mDeathObserver);
}
在ComposerService的connectLocked函数中, 主要完成了两件事: 第一,不断地从ServiceManager中获取SurfaceFlinger服务. 第二, 注册一个Binder死亡通知.

我们回到SurfaceComposerClient::onFirstRef函数的分析中, 当得到SurfaceFlinger服务之后, 第4-8行(SurfaceComposerClient::onFirstRef)会调用SurfaceFlinger的createConnection函数,createConnection函数的定义如下:
1sp SurfaceFlinger::createConnection()
2{
3 sp bclient;
4 sp 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 SurfaceFlinger::createConnection()
2{
3 sp bclient;
4 sp 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& 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建立了连接。

你可能感兴趣的:(android,frameworks)