Android应用程序与SurfaceFlinger服务之间的共享UI元数据(SharedClient)的创建过程分析

简介:

 在前面一篇文章中,我们分析了Android应用程序与SurfaceFlinger服务的连接过程。Android应用程序成功连接上SurfaceFlinger服务之后,还需要一块匿名共享内存来和SurfaceFlinger服务共享它的UI元数据,以便使得SurfaceFlinger服务可以正确地为它创建以及渲染Surface。在本文中,我们将详细地分析这块用来保存UI元数据的匿名共享内存的创建过程。

       在Android应用程序与SurfaceFlinger服务的关系概述和学习计划一文中提到,用来保存Android应用程序的UI元数据的匿名共享内存最终是被结构化为一个SharedClient对象来访问的。每一个与UI有关的Android应用程序进程有且仅有一个SharedClient对象,而且这些SharedClient对象是由Android应用程序请求SurfaceFlinger服务创建的:Android应用程序首先获得SurfaceFlinger服务的一个Binder代理接口,然后再通过这个代理接口得到另外一个类型为UserClient的Binder代理接口,最后就可以通过后一个Binder代理接口来获得一个SharedClient对象。

       由于每一个与UI有关的Android应用程序进程有且仅有一个SharedClient对象,因此,Android系统就通过一个单例模式的类来专负责创建和管理这个SharedClient对象。这个类的名称为SurfaceClient,定义在frameworks/base/libs/surfaceflinger_client/Surface.cpp文件中,如下所示:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
class  SurfaceClient :  public  Singleton<SurfaceClient>
{
     // all these attributes are constants
     sp<ISurfaceComposer> mComposerService;
     sp<ISurfaceComposerClient> mClient;
     status_t mStatus;
     SharedClient* mControl;
     sp<IMemoryHeap> mControlMemory;
     SurfaceClient()
         : Singleton<SurfaceClient>(), mStatus(NO_INIT)
     {
         sp<ISurfaceComposer> sf(ComposerService::getComposerService());
         mComposerService = sf;
         mClient = sf->createClientConnection();
         if  (mClient != NULL) {
             mControlMemory = mClient->getControlBlock();
             if  (mControlMemory != NULL) {
                 mControl = static_cast<SharedClient *>(
                         mControlMemory->getBase());
                 if  (mControl) {
                     mStatus = NO_ERROR;
                 }
             }
         }
     }
     friend  class  Singleton<SurfaceClient>;
public :
     status_t initCheck()  const  {
         return  mStatus;
     }
     SharedClient* getSharedClient()  const  {
         return  mControl;
     }
     ssize_t getTokenForSurface( const  sp<ISurface>& sur)  const  {
         // TODO: we could cache a few tokens here to avoid an IPC
         return  mClient->getTokenForSurface(sur);
     }
     void  signalServer()  const  {
         mComposerService->signal();
     }
};

      当SurfaceClient类的静态成员函数getInstance第一次被调用的时候,系统就会在对应的应用程序进程中创建一个SurfaceClient对象,即会调用SurfaceClient类的构造函数。SurfaceClient类的构造函数首先会调用ComposerService类的静态成员函数getComposerService来获得一个SurfaceFlinger服务的代理接口,并且保存在SurfaceClient类的成员变量mComposerService中,以便以后可以使用。ComposerService类的静态成员函数getComposerService在前面Android应用程序与SurfaceFlinger服务的连接过程分析一文中已经分析过了,这里不再详述。有了SurfaceFlinger服务的代理接口sf之后,SurfaceClient类的构造函数接着就可以调用它的成员函数createClientConnection来获得一个类型为UserClient的Binder代理接口,这个Binder代理接口实现了ISurfaceComposerClient接口,因此,我们可以将它保存在SurfaceClient类的成员变量mClient中。最后,SurfaceClient类的构造函数就调用前面获得的类型为ISurfaceComposerClient的Binder代理接口mClient的成员函数getControlBlock来获得一块用来描述应用程序UI元数据的匿名共享内存mControlMemory ,并且将这些匿名共享内存强制转化为一个SharedClient对象mControl,以便后面可以方便地访问UI元数据。


       以上就是Android应用程序与SurfaceFlinger服务之间的共享UI元数据(SharedClient)的创建过程的总体描述,接下来我们再详细分析每一步的实现。现在,我们继续分析一下SurfaceClient类的其余成员函数的实现:

       1. 成员函数initCheck用来检查一个Android应用程序进程是否已经成功地请求SurfaceFlinger服务创建了一块用来描述UI元数据的SharedClient对象了。

       2. 成员函数getSharedClient用来返回用来描述UI元数据的SharedClient对象mControl。

       3. 成员函数getTokenForSurface用来返回由参数sur所描述的一个Surface的Token值。这个Token值由SurfaceFlinger服务来创建和管理,并且可以通过前面所获得的类型为UserClient的Binder代理接口mClient的成员函数getTokenSurface来获得。

       4. 成员函数signalServer用来通知SurfaceFlinger服务更新Android应用程序UI,这是通过调用SurfaceFlinger服务的代理接口mComposerService的成员函数signal来实现的,实际上就是向SurfaceFlinger服务发送一个信号,以便可以将它唤醒起来更新UI。

       介绍完成SurfaceClient类的实现之后,我们还需要了解一下两个类的实现,即UserClient类和SharedClient类的实现,以便可以帮助我们了解用来保存Android应用程序的UI元数据的匿名共享内存的创建过程,以及帮助后面两篇文章对Surface的创建和渲染过程的分析。

       接下来,我们就首先分析UserClient类的实现,接着再分析SharedClient类的实现。

       在Android应用程序与SurfaceFlinger服务的连接过程分析一文的图2中,我们介绍了用来连接Android应用程序和SurfaceFlinger服务的Client类,而UserClient类和Client类是类似的,它们都实现了相同的接口,只不过是侧重点有所不同。Android应用程序与SurfaceFlinger服务的连接过程分析一文的图2中的Client类替换成UserClient类,就可以得到UserClient类的实现结构图,如图1所示:


图1 UserClient类的实现结构图

      UserClient类与Client类最重要的区别是,前者实现了ISurfaceComposerClient接口的成员函数getControlBlock,而后者实现了ISurfaceComposerClient接口的成员函数createSurface。后面我们就会分析UserClient类是如何实现ISurfaceComposerClient接口的成员函数getControlBlock的。

      UserClient类的实现暂时就介绍到这里,接下来我们来看SharedClient类的实现。为了方便描述,我们把Android应用程序与SurfaceFlinger服务的关系概述和学习计划一文的图4和图5贴出来,如以下图2和图3所示:


图2 用来描述Android应用程序的UI元数据的SharedClient

图3 SharedBufferStack的结构示意图

       每一个SharedClient对象包含了至多31个SharedBufferStack,而每一个SharedBufferStack都对应一个Android应用程序进程中的一个Surface。

       SharedClient类定义在文件frameworks/base/include/private/surfaceflinger/SharedBufferStack.h 文件中,如下所示:

1
2
3
4
5
6
7
8
9
10
class  SharedClient
{
public :
     SharedClient();
     ~SharedClient();
     ......
private :
     ......
     SharedBufferStack surfaces[ SharedBufferStack::NUM_LAYERS_MAX ];
};

       它有一个大小为SharedBufferStack::NUM_LAYERS_MAX的SharedBufferStack数组。SharedBufferStack::NUM_LAYERS_MAX的值等于31,定义在SharedBufferStack类中。


       SharedBufferStack类同样是定义在文件frameworks/base/include/private/surfaceflinger/SharedBufferStack.h 文件中,如下所示:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
class  SharedBufferStack
{
     ......
public :
     // When changing these values, the COMPILE_TIME_ASSERT at the end of this
     // file need to be updated.
     static  const  unsigned  int  NUM_LAYERS_MAX  =  31 ;
     static  const  unsigned  int  NUM_BUFFER_MAX  =  16 ;
     static  const  unsigned  int  NUM_BUFFER_MIN  =  2 ;
     static  const  unsigned  int  NUM_DISPLAY_MAX =  4 ;
     ......
     struct SmallRect {
         uint16_t l, t, r, b;
     };
    struct FlatRegion {
         static  const  unsigned  int  NUM_RECT_MAX =  5 ;
         uint32_t    count;
         SmallRect   rects[NUM_RECT_MAX];
     };
     struct BufferData {
         FlatRegion dirtyRegion;
         SmallRect  crop;
         uint8_t transform;
         uint8_t reserved[ 3 ];
     };
     SharedBufferStack();
     ......
     status_t setDirtyRegion( int  buffer,  const  Region& reg);
     status_t setCrop( int  buffer,  const  Rect& reg);
     status_t setTransform( int  buffer, uint8_t transform);
     Region getDirtyRegion( int  buffer)  const ;
     Rect getCrop( int  buffer)  const ;
     uint32_t getTransform( int  buffer)  const ;
     // these attributes are part of the conditions/updates
     volatile  int32_t head;       // server's current front buffer
     volatile  int32_t available;  // number of dequeue-able buffers
     volatile  int32_t queued;     // number of buffers waiting for post
     ......
     // not part of the conditions
     ......
     volatile  int8_t index[NUM_BUFFER_MAX];
     ......
                               
     int8_t      headBuf;         // last retired buffer
     ......
     BufferData  buffers[NUM_BUFFER_MAX]; 
};

      下面我们简要地对SharedBufferStack类进行分析。


       首先,SharedBufferStack类在内部定义了四个常量:

NUM_LAYERS_MAX -- 表示一个Android应用程序最多可以有NUM_LAYERS_MAX个Layer,可以将一个Layer理解为一个Surface。

NUM_BUFFER_MAX -- 表示一个SharedBufferStack至多可以有NUM_BUFFER_MAX个UI元数据缓冲区。

NUM_BUFFER_MIN -- 表示一个SharedBufferStack至少要有UM_BUFFER_MIN个UI元数据缓冲区。

NUM_DISPLAY_MAX -- 表示Android系统至多可以支持NUM_DISPLAY_MAX个显示屏。

       从这些常量就可以看出:

       1. Android系统至多支持4个显示屏。

       2. 一个Android应用程序至多可以同时创建31个Surface。

       3. 一个Surface可以有2~16个UI元数据缓冲区,即可以使用2~16缓冲区技术来渲染Surface。

       其次,SharedBufferStack类在内部定义了三个结构体:

SmallRect -- 用来描述一个矩形区域,其中,成员变量l、t,、r和b分别表示左上和右下两个角的位置。

FlatRegion -- 用来描述一个SmallRect数组rects ,数组的大小为NUM_RECT_MAX,但是实际个数为count。

BufferData -- 用来描述一个UI元数据缓冲区,它有四个成员变量dirtyRegion、crop、transform和reserved,其中,dirtyRegion用来描述一个Surface需要更新的区域,即裁剪区域,crop用来描述一个Surface的纹理坐标,transform用来描述一个Surface的旋转方向,例如,旋转90度或者上下翻转等等,而reserved是保留给以后使用的。通过这个UI元数据缓冲区,SurfaceFlinger服务就可以正确地把一个Surface的图形缓冲区所描述的图形渲染到屏幕来。

       SharedBufferStack类有一个BufferData数组buffers,它的大小为NUM_BUFFER_MAX,即16,就是用来一组UI元数据缓冲区的,这些UI元数据缓冲区的内容可以分别通过setDirtyRegion、setCrop、setTransform、getDirtyRegion、getCropgetTransform这六个成员函数来访问。这六个成员函数的第一个参数均为一个int值,用来描述要访问的是哪一个BufferData的数据。

       SharedBufferStack类还有另外一个类型为int8_t的数组index,它的大小也为NUM_BUFFER_MAX。这个index数组才是一个真正的Stack,它按照一定的规则来访问。index数组的每一个元素的值均是一个索引值,用来映射到数组buffers中去的。例如,假设index[0]的值等于2,那么它就对应数组buffers中的第2个元素,即buffers[2]

       SharedBufferStack类的其余重要成员变量的含义如下所示:

head -- 用来描述一个SharedBufferStack的头部,它是一个索引值,是映射到数组index中去的。

available -- 用来描述一个SharedBufferStack中的空闲UI元数据缓冲区的个数。

queued -- 用来描述一个SharedBufferStack中的已经补使用了的UI元数据缓冲区的个数,即那些在排队等待SurfaceFlinger服务使用的UI元数据缓冲区。

headBuf -- 用来描述一个SharedBufferStack的头部所对应的UI元数据缓冲区的编号,这个编号是映射到数组buffers中去。

       关于SharedBufferStack类的实现,我们就暂时介绍到这里,在下一篇文章分析Android应用程序的Surface创建过程时,我们再通过SharedBufferServer类和SharedBufferClient类的实现来进一步理解SharedBufferStack类的实现。

       现在,我们就开始详细分析Android应用程序与SurfaceFlinger服务之间的共享UI元数据的创建过程,如图4所示:


图 4 Android应用程序的共享UI元数据的创建过程

       接下来我们就详细分析每一个步骤。

       Step 1. SurfaceFlinger::createClientConnection

1
2
3
4
5
6
7
8
9
10
sp<ISurfaceComposerClient> SurfaceFlinger::createClientConnection()
{
     sp<ISurfaceComposerClient> bclient;
     sp<UserClient> client( new  UserClient( this ));
     status_t err = client->initCheck();
     if  (err == NO_ERROR) {
         bclient = client;
     }
     return  bclient;
}

       SurfaceFlinger类的成员函数createClientConnection实现在文件frameworks/base/services/surfaceflinger/SurfaceFlinger.cpp中,它的实现很简单,只是创建了一个类型为UserClient的Binder对象client,并且获得它的一个ISurfaceComposerClient接口,最后将这个ISurfaceComposerClient接口,即一个UserClient代理对象,返回给Android应用程序进程。


       接下来,我们再继续分析UserClient对象的创建过程,,即UserClient类的构造函数的实现。

        Step 2. new UserClient

1
2
3
4
5
6
7
8
9
10
11
12
UserClient::UserClient( const  sp<SurfaceFlinger>& flinger)
     : ctrlblk( 0 ), mBitmap( 0 ), mFlinger(flinger)
{
     const  int  pgsize = getpagesize();
     const  int  cblksize = ((sizeof(SharedClient)+(pgsize- 1 ))&~(pgsize- 1 ));
     mCblkHeap =  new  MemoryHeapBase(cblksize,  0 ,
             "SurfaceFlinger Client control-block" );
     ctrlblk = static_cast<SharedClient *>(mCblkHeap->getBase());
     if  (ctrlblk) {  // construct the shared structure in-place.
         new (ctrlblk) SharedClient;
     }
}

       UserClient类的成员变量mFlinger是一个类型为SurfaceFlinger的强指针,它指向了SurfaceFlinger服务, UserClient类的另外一个成员变量mBitmap是一个int32_t值,它是用来为Android应用程序的Surface分配Token值的,即如果它的第n位等于1,那么就表示值等于n的Token已经被分配出去使用了。


       UserClient类的构造函数首先得到一个SharedClient对象的大小,接着再将这个大小对齐到页面边界,于是就得到了接下来要创建的匿名共享块的大小cblksize。这块匿名共享内存是一个MemoryHeapBase对象描述的,并且保存在UserClient类的成员变量mCblkHeap。MemoryHeapBase类是用来创建匿名共享内存的一个C++接口,它的实现原理可以参考Android系统匿名共享内存(Anonymous Shared Memory)C++调用接口分析一文。

       UserClient类的构造函数得到了一块匿名共享内存之后,紧接着就在这块匿名共享内存上创建了一个SharedClient对象,并且保存在UserClient类的成员变量ctrlblk中,以便后面可以通过它来访问Android应用程序的UI元数据。

       回到SurfaceFlinger类的成员函数createClientConnection中,它将一个指向了一个UserClient对象的ISurfaceComposerClient接口返回到Android应用程序进程之后,Android应用程序进程就可以将它封装成一个类型为BpSurfaceComposerClient的Binder代理对象。

       Step 3. return BpSurfaceComposerClient

       将一个Binder代理对象封装成一个BpSurfaceComposerClient的过程可以参考前面Android应用程序与SurfaceFlinger服务的连接过程分析一文中的Step 4。

       Step 4. UserClient::getControlBlock

1
2
3
sp<IMemoryHeap> UserClient::getControlBlock()  const  {
     return  mCblkHeap;
}

       从前面的Step 2可以知道,UserClient类的成员变量mCblkHeap指向了一块匿名共享内存,UserClient类将这块匿名共享内存返回给Android应用程序之后,Android应用程序就会将它结构化成一个SharedClient对象来访问,并且保存在SurfaceClient类的成员变量mControl中,这个结构化过程就可以参考前面所描述的SurfaceClient类的构造函数了。


       至此,用来描述Android应用程序的UI元数据的一个SharedClient对象的创建过程就分析完了。以后当Android应用程序请求SurfaceFlinger服务创建一个Surface的时候,SurfaceFlinger服务就会从这个SharedClient对象中取出一个SharedBufferStack出来,以便可以用作这个Surface的UI元数据缓冲区。在接下来的一篇文章中,我们将详细描述Android应用程序请求SurfaceFlinger服务创建Surface的过程,敬请期待!





本文转自 Luoshengyang 51CTO博客,原文链接:http://blog.51cto.com/shyluo/1242305,如需转载请自行联系原作者
目录
相关文章
|
14天前
|
搜索推荐 Android开发 开发者
探索安卓开发中的自定义视图:打造个性化UI组件
【10月更文挑战第39天】在安卓开发的世界中,自定义视图是实现独特界面设计的关键。本文将引导你理解自定义视图的概念、创建流程,以及如何通过它们增强应用的用户体验。我们将从基础出发,逐步深入,最终让你能够自信地设计和实现专属的UI组件。
|
23天前
|
JSON Java Android开发
探索安卓开发之旅:打造你的第一个天气应用
【10月更文挑战第30天】在这个数字时代,掌握移动应用开发技能无疑是进入IT行业的敲门砖。本文将引导你开启安卓开发的奇妙之旅,通过构建一个简易的天气应用来实践你的编程技能。无论你是初学者还是有一定经验的开发者,这篇文章都将成为你宝贵的学习资源。我们将一步步地深入到安卓开发的世界中,从搭建开发环境到实现核心功能,每个环节都充满了发现和创造的乐趣。让我们开始吧,一起在代码的海洋中航行!
|
23天前
|
存储 搜索推荐 Java
打造个性化安卓应用:从设计到实现
【10月更文挑战第30天】在数字化时代,拥有一个个性化的安卓应用不仅能够提升用户体验,还能加强品牌识别度。本文将引导您了解如何从零开始设计和实现一个安卓应用,涵盖用户界面设计、功能开发和性能优化等关键环节。我们将以一个简单的记事本应用为例,展示如何通过Android Studio工具和Java语言实现基本功能,同时确保应用流畅运行。无论您是初学者还是希望提升现有技能的开发者,这篇文章都将为您提供宝贵的见解和实用的技巧。
|
27天前
|
搜索推荐 开发工具 Android开发
打造个性化Android应用:从设计到实现的旅程
【10月更文挑战第26天】在这个数字时代,拥有一个能够脱颖而出的移动应用是成功的关键。本文将引导您了解如何从概念化阶段出发,通过设计、开发直至发布,一步步构建一个既美观又实用的Android应用。我们将探讨用户体验(UX)设计的重要性,介绍Android开发的核心组件,并通过实际案例展示如何克服开发中的挑战。无论您是初学者还是有经验的开发者,这篇文章都将为您提供宝贵的见解和实用的技巧,帮助您在竞争激烈的应用市场中脱颖而出。
|
29天前
|
算法 Java 数据库
Android 应用的主线程在什么情况下会被阻塞?
【10月更文挑战第20天】为了避免主线程阻塞,我们需要合理地设计和优化应用的代码。将耗时操作移到后台线程执行,使用异步任务、线程池等技术来提高应用的并发处理能力。同时,要注意避免出现死循环、不合理的锁使用等问题。通过这些措施,可以确保主线程能够高效地运行,提供流畅的用户体验。
39 2
|
2月前
|
Java API Android开发
安卓应用程序开发的新手指南:从零开始构建你的第一个应用
【10月更文挑战第20天】在这个数字技术不断进步的时代,掌握移动应用开发技能无疑打开了一扇通往创新世界的大门。对于初学者来说,了解并学习如何从无到有构建一个安卓应用是至关重要的第一步。本文将为你提供一份详尽的入门指南,帮助你理解安卓开发的基础知识,并通过实际示例引导你完成第一个简单的应用项目。无论你是编程新手还是希望扩展你的技能集,这份指南都将是你宝贵的资源。
53 5
|
9天前
|
开发框架 前端开发 Android开发
安卓与iOS开发中的跨平台策略
在移动应用开发的战场上,安卓和iOS两大阵营各据一方。随着技术的演进,跨平台开发框架成为开发者的新宠,旨在实现一次编码、多平台部署的梦想。本文将探讨跨平台开发的优势与挑战,并分享实用的开发技巧,帮助开发者在安卓和iOS的世界中游刃有余。
|
16天前
|
Android开发 Swift iOS开发
探索安卓与iOS开发的差异和挑战
【10月更文挑战第37天】在移动应用开发的广阔舞台上,安卓和iOS这两大操作系统扮演着主角。它们各自拥有独特的特性、优势以及面临的开发挑战。本文将深入探讨这两个平台在开发过程中的主要差异,从编程语言到用户界面设计,再到市场分布的不同影响,旨在为开发者提供一个全面的视角,帮助他们更好地理解并应对在不同平台上进行应用开发时可能遇到的难题和机遇。
|
18天前
|
XML 存储 Java
探索安卓开发之旅:从新手到专家
【10月更文挑战第35天】在数字化时代,安卓应用的开发成为了一个热门话题。本文旨在通过浅显易懂的语言,带领初学者了解安卓开发的基础知识,同时为有一定经验的开发者提供进阶技巧。我们将一起探讨如何从零开始构建第一个安卓应用,并逐步深入到性能优化和高级功能的实现。无论你是编程新手还是希望提升技能的开发者,这篇文章都将为你提供有价值的指导和灵感。
|
16天前
|
存储 API 开发工具
探索安卓开发:从基础到进阶
【10月更文挑战第37天】在这篇文章中,我们将一起探索安卓开发的奥秘。无论你是初学者还是有经验的开发者,这篇文章都将为你提供有价值的信息和建议。我们将从安卓开发的基础开始,逐步深入到更复杂的主题,如自定义组件、性能优化等。最后,我们将通过一个代码示例来展示如何实现一个简单的安卓应用。让我们一起开始吧!