`
zzu_007
  • 浏览: 23891 次
  • 性别: Icon_minigender_1
  • 来自: 北京
社区版块
存档分类
最新评论

应用程序进程与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<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建立了连接。

分享到:
评论

相关推荐

    surfaceflinger说明文档

    - **描述**:在应用程序与SurfaceFlinger建立连接后,每个应用程序的界面都会被映射成一个Layer对象。Layer对象包含了所有关于该Surface的控制信息,例如大小、位置、透明度等。 - **作用**:Layer对象在...

    surfaceflinger android 概述

    这些库提供了图形渲染所需的API,允许应用程序进行3D图形编程,并与Surface Flinger紧密协作,将应用程序的图形层合成到最终的显示帧上。 总之,Surface Flinger在Android系统中是图形渲染的中枢,它负责合成多个...

    android权限大全

    - 连接到已配对的蓝牙设备和发现配对新蓝牙设备的权限(BLUETOOTH、BLUETOOTH_ADMIN):允许应用程序访问蓝牙硬件,实现与其他蓝牙设备的交互。 在开发Android应用程序时,了解这些权限是至关重要的。开发者必须在...

    android peimission 权限说明 android

    此权限允许应用程序使用SurfaceFlinger的低级别特性。 **应用场景:** 这是一项较为特殊的权限,主要用于那些需要直接访问显示硬件的应用程序,例如屏幕截图工具或者一些底层渲染引擎。 #### 七、`ACCESS_WIFI_...

    android的核心分析

    - **Zygote**:Android的初始进程,负责创建应用程序进程。 #### ZygoteService Zygote是Android系统中的一个关键进程,负责为每个应用程序创建一个独立的虚拟机实例。通过这种方式,Zygote提高了应用程序的启动...

    Android-framework详细分析[1]

    Zygote是Android系统中一个特殊的进程,用于启动所有的Java应用程序进程。Zygote Service负责管理Zygote进程的生命周期,并根据请求启动新的应用程序实例。 - **Zygote初始化**:加载Dalvik/ART虚拟机。 - **应用...

    Android核心分析(pdf)

    - **空间划分的重要性:** 为了提高系统的稳定性和安全性,Android系统将不同的应用程序和服务分配到独立的进程中运行。 - **进程与线程管理:** 深入讨论Android是如何管理和调度进程与线程的,特别是在处理并发...

    Android核心剖析之Framework概述

    Android的Framework层作为操作系统的核心组成部分,扮演着连接硬件抽象层(HAL)与应用程序之间的桥梁角色,它不仅提供了丰富的API供开发者调用,还负责管理和调度应用程序的生命周期。本章节深入探讨Android ...

    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主要机制深入分析.pdf

    Android输入系统是一个复杂的过程,它从设备驱动层开始,经过中间层的处理,最终达到应用程序层。 7. 电话系统分析:研究Android电话系统,包括RIL(Radio Interface Layer)以及与电话功能相关的各种组件。RIL是...

    Android核心分析

    应用程序框架是开发者创建应用程序的基础,提供了丰富的API和服务支持。 **应用程序框架分析:** - **无边界设计意图**:强调应用程序之间的互操作性和灵活性。 - **AndroidApplication**:应用程序的入口点,负责...

    《深入浅出Google Android》源码

    Android系统是基于Linux内核的开源移动操作系统,主要由应用程序层、应用程序框架层、系统运行库层和Linux内核层构成。源码中包含了这四个层次的代码,涵盖了系统启动、进程管理、内存分配、硬件抽象等多个方面。 ...

    Android权限大全

    2. `android.permission.ACCESS_COARSE_LOCATION`: 应用程序可以通过此权限获取粗略的地理位置信息,如通过Cell-ID(手机信号塔)或WiFi网络定位。这对于需要基本位置信息但不关心精确度的应用很有用,例如天气预报...

    Android-framework详解

    - **无边界设计意图**:指在设计应用程序时考虑到与其他组件的交互,确保应用程序能够在各种环境中顺畅运行。 - **AndroidApplication**:基类,提供了应用程序的基本框架和生命周期管理。 - **Activity**:表示...

    Android核心分析系列教程

    Zygote是Android系统中的初始进程,负责初始化虚拟机环境并启动其他应用程序进程。通过对ZygoteService的分析,可以了解到它是如何支持多进程管理和资源分配的。 #### 十、AndroidGWES之基本原理篇 GWES即Graphics...

    android Binder 分析

    总结来说,Android Binder机制是Android系统中不可或缺的部分,它支撑了系统的组件间通信和应用程序的正常运行。理解Binder的工作原理、服务端和客户端的交互过程,以及如何通过AIDL定义接口,对于Android开发者至关...

    Android 核心分析

    #### 应用程序框架与图形显示 - **无边界设计意图**:Android的应用程序框架设计体现了“无边界”的理念,即应用可以在任何场景下无缝切换,提供一致的用户体验。这得益于其强大的组件化和插件化能力。 - **...

Global site tag (gtag.js) - Google Analytics