Android显示系统 SurfaceFlinger内部机制 1 AP如何获取SurfaceFlinger服务
韦东山 Android framework 笔记
1，显示系统框架
a,显示驱动framebuffer的原理和改进
b，多任务系统的显示：一定有一个显示管理者
c，android显示系统框架
4，SurfaceFlinger的内部机制
4.1 APP跟SurfaceFlinger之间的重要数据结构，
一个APP可以构造多个界面，
它一般只有一个Surface，也可以有多个Surface，
一个Surface可以有多个buffer，显示一个buffer，绘制另一个buffer
这些buffer需要向SurfaceFlinger来申请，
可以想象，SF里面一定有结构体表示这些AP，AP里的Surface，Surface里的buffer，
SF里，
用Client表示APP，
Client里面有Layer来表示AP的SurfaceControl，
Layer里面有buffer的，但是分成了生产者和消费者，
AP的Surface的mSlots对应SF的BufferQueueCore的mSlot，
mSlots的每个数组项含有一个mGraphicBuffer，表示buffer
看看SurfaceFlinger的Layer：
//frameworks/native/services/surfaceflinger/layer.h
namespace android{
class Layer:public SurfaceFlinger Consumer::ContentsChangedListenser{
private:
sp mSurfaceFlingerConsumer; //消费者
sp mProducer; //生产者
}
}
回顾一下生产者消费者问题，
生产者把数据放入data，消费者从同一个buffer取出数据，他们有同一个buffer，
所以SF里面的生产者消费者肯定也有同一个buffer，
Android里做了抽象，他们有同一个mCore，mCore是什么类型？
生产者和消费者拥有同一个mCore(bufferQueue)，它应该是一个数组
看看BufferQueueCore：
//framework/native/inclue/gui/BufferQueueCore.h
namespace android{
class BufferQueueCore:public virtual RefBase {
private:
BufferQueueDefs::SlotsType mSlots; //多个插槽，看看它的类型
}
}
//BufferQueueCore里面有mSlots，看看它的类型SlotsType:
//SlotsTYpe是一个BufferSlots数组
//framwork/native/include/gui/BufferQueueDef.h
namespace android{
class BufferQueueCore;
namespace BufferQueueDefs {
enum {NUM_BUFFER_SLOTS = 64};
typedef BufferSlot SlotsType[NUM_BUFFER_SLOTS]; //是一个BufferSlot数组，每个数组项表示一个buffer
}
}
//看看BufferSlots数据结构
//每个BufferSlot中有一个graphicBuffer
//native/include/gui/BufferSlot.h
namespace android{
class Fence;
//BufferState tracks the states in which a buffer slot can be
struct BufferState{
}
struct BufferSlot{
BufferSlot()
:mGraphicBuffer(nullptr),
.....{
}
//mGraphicBuffer points to the buffer allocated for this slot or is nULL
//if no buffer has been allocated.
sp mGraphicBuffer; //表示allocated buffer
}
}
这些数据结构是在SF进程里，用来表示APP的，
那么对于APP，它有哪些数据结构？
看看它的AP test code
搜索一下哪里用了sp
---- new SurfaceComposerClient Matches (20 in 17 files) ----
android::camera2::tests::CameraMultiStreamTest::CreateOnScreenSurface in CameraMultiStreamTests.cpp (E:\p4vcode\sw\s3gdrv\code\s3driverSDK\libhardware\tests\camera2) : mComposerClient = new SurfaceComposerClient;
android::GLHelper::createWindowSurface in GLHelper.cpp (E:\p4vcode\sw\s3gdrv\code\s3driverSDK\native\cmds\flatland) : mSurfaceComposerClient = new SurfaceComposerClient;
android::GLHelper::createWindowSurface in GLHelper.cpp (native\cmds\flatland) : mSurfaceComposerClient = new SurfaceComposerClient;
android::GLTest::SetUp in GLTest.cpp (E:\p4vcode\sw\s3gdrv\code\s3driverSDK\native\libs\gui\tests) : mComposerClient = new SurfaceComposerClient;
android::GLTest::SetUp in GLTest.cpp (native\libs\gui\tests) : mComposerClient = new SurfaceComposerClient;
Replayer::loadSurfaceComposerClient in Replayer.cpp (native\cmds\surfacereplayer\replayer) : mComposerClient = new SurfaceComposerClient;
DisplayTest::SetUp in SFFakeHwc_test.cpp (native\services\surfaceflinger\tests\fakehwc) : mComposerClient = new SurfaceComposerClient;
TransactionTest::SetUp in SFFakeHwc_test.cpp (native\services\surfaceflinger\tests\fakehwc) : mComposerClient = new SurfaceComposerClient;
android::SRGBTest::createDebugSurface in SRGB_test.cpp (E:\p4vcode\sw\s3gdrv\code\s3driverSDK\native\libs\gui\tests) : mComposerClient = new SurfaceComposerClient;
android::TEST::{lambda} in Stress_test.cpp (native\services\surfaceflinger\tests) : sp client = new SurfaceComposerClient;
android::SurfaceControl::readFromParcel in SurfaceControl.cpp (native\libs\gui) : return new SurfaceControl(new SurfaceComposerClient(
android::SurfaceInterceptorTest::SetUp in SurfaceInterceptor_test.cpp (native\services\surfaceflinger\tests) : mComposerClient = new SurfaceComposerClient;
android::SurfaceTest::SetUp in Surface_test.cpp (E:\p4vcode\sw\s3gdrv\code\s3driverSDK\native\libs\gui\tests) : mComposerClient = new SurfaceComposerClient;
android::SurfaceTest::SetUp in Surface_test.cpp (native\libs\gui\tests) : mComposerClient = new SurfaceComposerClient;
android::LayerUpdateTest::SetUp in Transaction_test.cpp (E:\p4vcode\sw\s3gdrv\code\s3driverSDK\native\services\surfaceflinger\tests) : mComposerClient = new SurfaceComposerClient;
LayerTransactionTest::SetUp in Transaction_test.cpp (native\services\surfaceflinger\tests) : mClient = new SurfaceComposerClient;
LayerUpdateTest::SetUp in Transaction_test.cpp (native\services\surfaceflinger\tests) : mComposerClient = new SurfaceComposerClient;
TEST_F in Transaction_test.cpp (native\services\surfaceflinger\tests) : sp mNewComposerClient = new SurfaceComposerClient;
WindowSurface::WindowSurface in WindowSurface.cpp (E:\p4vcode\sw\s3gdrv\code\s3driverSDK\native\opengl\tests\lib) : sp surfaceComposerClient = new SurfaceComposerClient;
WindowSurface::WindowSurface in WindowSurface.cpp (native\opengl\tests\lib) : sp surfaceComposerClient = new SurfaceComposerClient;
看看韦东山自己写的SurfaceTest.cpp
//app_0010_surfacetest/SurfaceTest.cpp
int main(int argc, char** argv)
{
//set up the thread-pool
//在慕课网 剖析framework 第三章讲过，这行是拿到当前的ProcessState，通过单例模式。
//然后open了Binder驱动，把fd mmap到了当前进程空间，
sp proc(ProcessSatet::self());
//这里，线程池只有一个线程，threadLoop里面有个IPCThreadState，它里面有mIn,mOut两个Parce
//想写到Binder就往mOut写，读Binder就从mIn读，然后通过cmd执行不同的操作。
ProcessState::self()->startThreadPool();
//create a client to surfaceflinger
//1，每个AP与SF都有一个连接，就是SurfaceComposerClient，看看它里面有什么数据结构
sp client = new SurfaceComposerClient();
//每个Surface里面对应一个SurfaceControl，
sp surfaceControl = client->createSurface(String8("resize"), 160, 240, PIXEL_FORMAT_RGB_565, 0);
//2,从SurfaceControl得到Surface，所以surface是用SurfaceControl管理的，看看Surface里面有什么东西
sp surface = surfaceControl->getSurface();
SurfaceComposerClient::openGlobalTransaction();
surfaceControl->setLayer(10000);l
SurfaceComposerClient::closeGlobalTransaction();
ANatviveWIndow_Buffer outBuffer;
Surface->lock(&outBuffer, NULL);
ssize_T bpr = outBuffer.stride * bytesPerPixel(outBuffer.format);
android_memset16((uint16_t*)outBuffer.bits, 0xF800, bpr*outBuffer.height);
surface->unlockAndPost();
}
/1，看看SurfaceComposerClient类
//所以，SF里用Client表示AP，同样，AP里用mClient指向sf里面的client，
//framework/native/include/gui/SurfaceComposerClient.h
class SurfaceComposerClient:public RefBase
{
friend classs Composer;
private:
mutable Mutex mLock;
sp mClient; //SurfaceComposerClient里面有一个mClient，
Composer& mComposer;
}
/2,看看Surface里面有什么
//有一个mSlots数组：BufferSlot mSlots[64]，对应SF端的mSlots数组
//framwork/native/include/gui/Surface.h
namespace android {
class Surface
: public ANativeObjectBase
{
struct BufferSlot {
sp buffer;
Region dirtyRegion;
}
sp mGrpahicBufferProducer;
BufferSlot mSlots[NUM_BUFFER_SLOTS];
}
}
SF里，
用Client表示APP，
Client里面有Layer来表示AP的SurfaceControl，
Layer里面有buffer的，但是分成了生产者和消费者，
AP的Surface的mSlots对应SF的BufferQueueCore的mSlot，
mSlots的每个数组项含有一个mGraphicBuffer，表示buffer，
可以推测，AP的buffer和SF的buffer，一定指向同一个物理内存
流程：
AP发出请求，
SF收到请求，使用gralloc从匿名共享内存中分配内存，记录在mGraphicBuffer里面，
信息返回给AP，AP构造出mGraphicBuffer
流程：
这里它弄了一个流程图，
中间是binder，左侧是AP，右侧是SF进程，他们通过binder通信，
AP向获得SF的服务，它需要先getSurface，
中间是binder，左侧是AP，右侧是SF进程，他们通过binder通信，
AP向获得SF的服务，它需要先getService("SurfaceFlinger". &mComposerSerivce)，
这步应该是在sp
//framwork/native/libs/gui/SurfaceComposerClient.cpp
SurfaceComposerClient::SurfaceComposerClient()
: mStatus(NO_INIT), mComposer(Composer::getInstance())
{
//构造函数什么都没做
}
看看第一次引用它做了什么，onFirstRef
void SurfaceComposerClient::onFitstRef() {
//这里会获得服务，拿到了SF的binder对象？下节详细分析
sp sm(ComposerService::getComposerSerivce());
if(sm != 0) {
sp conn = sm->ceateConnection();
if(conn != 0) {
mClient = conn;
mState = NO_ERROR;
}
}
}
getService获得服务后，通过createConnection创建client，用来表示与AP的连接，
Client派生于BnSurfaceComposerClient，AP端肯定有一个代理，就是BpSurfaceComposerClient，
当AP调用createSurface：sp
就会通过binder导致SF端的BnSurfaceComposerClient调用createSurface，进而创建出Layer，对应AP端的SurfaceControl，
Layer里面有一个生产者一个消费者，生成者嵌套很深，最终会创建出BufferQueueProducer，它是一个BnGraphicBufferProducer，n是native本地实现
AP端则对应一个代理，SurfaceControl里的mGraphicBufferProducer : sp
以后就可以通过这个Producer调用里面的DequeueBuffer等函数。在下图2,。
之前说，AP里面有Surface，Surface里面有buffer，buffer用BufferSlots记录，
如图，AP端的Surface里面有mSlot : BufferSlot[64]，对应SF端的Layer里面有Procuer和Comsumer，它最终指向同一个BufferQueueCore，
BufferQueueCore里面有一个mSlots[64]，生产者和消费者里面有一个mSlots:BufferSlots[64]& 引用，引用了BufferQueueCore里面的数组，
所以，
SF里面有个BufferQUeueCore，它里面有一个数组，跟AP端的Surface的mSLots对应了起来，
总结：
这里分析了数据结构，
SF端
用client表示AP，
client里有多个layer，表示AP使用的界面，
Layer有Producer和Comsumer，他们最终指向同一个BufferQueueCore，
BufferQueueCore里面有一个mSlots数组，表示AP的某个surface拥有的buffer。
AP端：
SurfaceComposerClient是SF的binder对象，表示与SF的连接，里面的mClient对应SF端的client，所以可以用它进行binder调用，在SF端创建Surface，得到SurfaceControl，
SurfaceControl里可以拿到Surface，Surface里有数组mSlots : BufferSlot[64]，表示Surface对应的buffer，
Surface里还有Producer，表示SF端的BufferQueueProducer，然后AP端就可以通过这个BufferQueueProducer的代理走binder调用SF的各种函数如DequeueBuffer，RequestBuffer.