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

文章转载至CSDN社区罗升阳的安卓之旅，原文地址：http://blog.csdn.net/luoshengyang/article/details/7867340

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

当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. class SharedClient
2. {
3. public:
4. SharedClient();
5. ~SharedClient();
6. ......
7. private:
8. ......
9. SharedBufferStack surfaces[ SharedBufferStack::NUM_LAYERS_MAX ];
10. };

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

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

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

下面我们简要地对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、getCrop和getTransform这六个成员函数来访问。这六个成员函数的第一个参数均为一个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. sp<ISurfaceComposerClient> SurfaceFlinger::createClientConnection()
2. {
3. sp<ISurfaceComposerClient> bclient;
4. sp<UserClient> client(new UserClient(this));
5. status_t err = client->initCheck();
6. if (err == NO_ERROR) {
7. bclient = client;
8. }
9. return bclient;
10. }

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

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

Step 2. new UserClient

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

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. sp<IMemoryHeap> UserClient::getControlBlock() const {
2. return mCblkHeap;
3. }

从前面的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的过程，敬请期待！

老罗的新浪微博：http://weibo.com/shengyangluo，欢迎关注！